draft-ietf-secevent-token-07.txt   draft-ietf-secevent-token-08.txt 
Security Events Working Group P. Hunt, Ed. Security Events Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track M. Jones Intended status: Standards Track M. Jones
Expires: September 5, 2018 Microsoft Expires: October 6, 2018 Microsoft
W. Denniss W. Denniss
Google Google
M. Ansari M. Ansari
Cisco Cisco
March 4, 2018 April 4, 2018
Security Event Token (SET) Security Event Token (SET)
draft-ietf-secevent-token-07 draft-ietf-secevent-token-08
Abstract Abstract
This specification defines the Security Event Token (SET) data This specification defines the Security Event Token (SET) data
structure. A SET describes a statement of fact from the perspective structure. A SET describes a statement of fact from the perspective
of an issuer about the state of a security subject, which is intended of an issuer about the state of a security subject, which is intended
to be shared with one or more recipients. This statement of fact to be shared with one or more recipients. This statement of fact
represents an event that occurred to the security subject. In some represents an event that occurred to the security subject. This
use cases, the security subject may be a digitial identity, but SETs specification is intended to enable representing security- and
are also applicable to non-identity use cases. A SET is a JSON Web identity-related events. A SET is a JSON Web Token (JWT), which can
Token (JWT), which can be optionally signed and/or encrypted. SETs be optionally signed and/or encrypted. SETs can be distributed via
can be distributed via protocols such as HTTP. protocols such as HTTP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2018. This Internet-Draft will expire on October 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
2.1.4. RISC Example . . . . . . . . . . . . . . . . . . . . 9 2.1.4. RISC Example . . . . . . . . . . . . . . . . . . . . 9
2.2. Core SET Claims . . . . . . . . . . . . . . . . . . . . . 10 2.2. Core SET Claims . . . . . . . . . . . . . . . . . . . . . 10
2.3. Explicit Typing of SETs . . . . . . . . . . . . . . . . . 12 2.3. Explicit Typing of SETs . . . . . . . . . . . . . . . . . 12
2.4. Security Event Token Construction . . . . . . . . . . . . 12 2.4. Security Event Token Construction . . . . . . . . . . . . 12
3. Requirements for SET Profiles . . . . . . . . . . . . . . . . 14 3. Requirements for SET Profiles . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1. Confidentiality and Integrity . . . . . . . . . . . . . . 15 4.1. Confidentiality and Integrity . . . . . . . . . . . . . . 15
4.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Distinguishing SETs from ID Tokens . . . . . . . . . . . 16 4.5. Distinguishing SETs from ID Tokens . . . . . . . . . . . 17
4.6. Distinguishing SETs from Access Tokens . . . . . . . . . 17 4.6. Distinguishing SETs from Access Tokens . . . . . . . . . 17
4.7. Distinguishing SETs from other kinds of JWTs . . . . . . 18 4.7. Distinguishing SETs from other kinds of JWTs . . . . . . 18
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.1. JSON Web Token Claims Registration . . . . . . . . . . . 19 6.1. JSON Web Token Claims Registration . . . . . . . . . . . 19
6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 19 6.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 19
6.2. Media Type Registration . . . . . . . . . . . . . . . . . 20 6.2. Media Type Registration . . . . . . . . . . . . . . . . . 20
6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 6.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction and Overview 1. Introduction and Overview
This specification defines an extensible Security Event Token (SET) This specification defines an extensible Security Event Token (SET)
data structure, which can be exchanged using protocols such as HTTP. data structure, which can be exchanged using protocols such as HTTP.
The specification builds on the JSON Web Token (JWT) format [RFC7519] The specification builds on the JSON Web Token (JWT) format [RFC7519]
in order to provide a self-contained token that can be optionally in order to provide a self-contained token that can be optionally
signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted signed using JSON Web Signature (JWS) [RFC7515] and/or encrypted
using JSON Web Encryption (JWE) [RFC7516]. using JSON Web Encryption (JWE) [RFC7516].
This specification profiles the use of JWT for the purpose of issuing This specification profiles the use of JWT for the purpose of issuing
Security Event Tokens (SETs). This specification defines a base Security Event Tokens (SETs). This specification defines a base
format used by profiling specifications to define actual events and format used by profiling specifications to define actual events and
their meanings. This specification uses non-normative example events their meanings. This specification uses non-normative example events
to demonstrate how events can be constructed. to demonstrate how events can be constructed.
This specification is scoped to security and identity related events. This specification is scoped to security- and identity-related
While Security Event Tokens may be used for other purposes, the events. While Security Event Tokens may be used for other purposes,
specification only considers security and privacy concerns relevant the specification only considers security and privacy concerns
to identity and personal information. relevant to identity and personal information.
Security events are not commands issued between parties. A security Security events are not commands issued between parties. A security
event is a statement of fact from the perspective of an issuer about event is a statement of fact from the perspective of an issuer about
the state of a security subject (e.g., a web resource, token, IP the state of a security subject (e.g., a web resource, token, IP
address, the issuer itself) that the issuer controls or is aware of, address, the issuer itself) that the issuer controls or is aware of,
that has changed in some way (explicitly or implicitly). A security that has changed in some way (explicitly or implicitly). A security
subject may be permanent (e.g., a user account) or temporary (e.g., subject may be permanent (e.g., a user account) or temporary (e.g.,
an HTTP session) in nature. A state change could describe a direct an HTTP session) in nature. A state change could describe a direct
change of entity state, an implicit change of state, or other higher- change of entity state, an implicit change of state, or other higher-
level security statements such as: level security statements such as:
skipping to change at page 5, line 41 skipping to change at page 5, line 41
will be specific to particular SET profiles or profile families. will be specific to particular SET profiles or profile families.
Claims in the envelope SHOULD be registered in the "JSON Web Token Claims in the envelope SHOULD be registered in the "JSON Web Token
Claims" registry [IANA.JWT.Claims] or be Public Claims or Private Claims" registry [IANA.JWT.Claims] or be Public Claims or Private
Claims, as defined in [RFC7519]. Claims, as defined in [RFC7519].
o Envelope claims that are profiled and defined in this o Envelope claims that are profiled and defined in this
specification are used to validate the SET and provide information specification are used to validate the SET and provide information
about the event data included in the SET. The claim "events" about the event data included in the SET. The claim "events"
contains the event identifiers and event-specific data expressed contains the event identifiers and event-specific data expressed
about the security subject. The envelope MAY include event- about the security subject. The envelope MAY include event-
specific or profile-specific data. specific or profile-specific data. The "events" claim value MUST
be a JSON object that contains at least one member.
o Each member of the "events" JSON object is a name/value pair. The o Each member of the "events" JSON object is a name/value pair. The
JSON member name is a URI string value, which is the event JSON member name is a URI string value, which is the event
identifier, and the corresponding value is a JSON object known as identifier, and the corresponding value is a JSON object known as
the event "payload". The payload JSON object contains claims that the event "payload". The payload JSON object contains claims that
pertain to that event identifier and need not be registered as JWT pertain to that event identifier and need not be registered as JWT
claims. These claims are defined by the profiling specification claims. These claims are defined by the profiling specification
that defines the event. An event with no payload claims SHALL be that defines the event. An event with no payload claims SHALL be
represented as the empty JSON object ("{}"). represented as the empty JSON object ("{}").
skipping to change at page 6, line 28 skipping to change at page 6, line 28
* Additions to existing event representations. * Additions to existing event representations.
* Values used to link potential series of events. * Values used to link potential series of events.
* Specific-purpose event URIs used between particular SET issuers * Specific-purpose event URIs used between particular SET issuers
and SET recipients. and SET recipients.
2.1. Illustrative Examples 2.1. Illustrative Examples
This section illustrates several possible uses of SETs through non-
normative examples.
2.1.1. SCIM Example 2.1.1. SCIM Example
The following is a non-normative example showing the JWT Claims Set The following example shows the JWT Claims Set for a hypothetical
for a hypothetical SCIM [RFC7644] password reset SET. This example SCIM [RFC7644] password reset SET. This example uses a second
uses a second "events" value ("https://example.com/scim/event/ "events" value ("https://example.com/scim/event/passwordResetExt") to
passwordResetExt") to convey additional information about the state convey additional information about the state change -- in this case,
change -- in this case, the current count of reset attempts: the current count of reset attempts:
{ {
"iss": "https://scim.example.com", "iss": "https://scim.example.com",
"iat": 1458496025, "iat": 1458496025,
"jti": "3d0c3cf797584bd193bd0fb1bd4e7d30", "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
"aud": [ "aud": [
"https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754", "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
"https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7" "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
], ],
"sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9", "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
skipping to change at page 14, line 32 skipping to change at page 14, line 32
confidentiality, and issuer authenticity, as needed by the confidentiality, and issuer authenticity, as needed by the
application. application.
When validation (i.e., auditing), or additional transmission security When validation (i.e., auditing), or additional transmission security
is required, JWS signing and/or JWE encryption MAY be used. To is required, JWS signing and/or JWE encryption MAY be used. To
create and or validate a signed and/or encrypted SET, follow the create and or validate a signed and/or encrypted SET, follow the
instructions in Section 7 of [RFC7519]. instructions in Section 7 of [RFC7519].
3. Requirements for SET Profiles 3. Requirements for SET Profiles
Profiling specifications for SETs define the syntax and semantics of Profiling specifications of this specification define actual SETs to
SETs conforming to that SET profile and rules for validating those be used in particular use cases. These profiling specifications
SETs. The syntax defined by profiling specifications includes what define the syntax and semantics of SETs conforming to that SET
claims and event payload values are used by SETs utilizing the profile and rules for validating those SETs. The syntax defined by
profile. profiling specifications includes what claims and event payload
values are used by SETs utilizing the profile.
Defining the semantics of the SET contents for SETs utilizing the Defining the semantics of the SET contents for SETs utilizing the
profile is equally important. Possibly most important is defining profile is equally important. Possibly most important is defining
the procedures used to validate the SET issuer and to obtain the keys the procedures used to validate the SET issuer and to obtain the keys
controlled by the issuer that were used for cryptographic operations controlled by the issuer that were used for cryptographic operations
used in the JWT representing the SET. For instance, some profiles used in the JWT representing the SET. For instance, some profiles
may define an algorithm for retrieving the SET issuer's keys that may define an algorithm for retrieving the SET issuer's keys that
uses the "iss" claim value as its input. Likewise, if the profile uses the "iss" claim value as its input. Likewise, if the profile
allows (or requires) that the JWT be unsecured, the means by which allows (or requires) that the JWT be unsecured, the means by which
the integrity of the JWT is ensured MUST be specified. the integrity of the JWT is ensured MUST be specified.
skipping to change at page 23, line 13 skipping to change at page 23, line 18
<https://www.rfc-editor.org/info/rfc8055>. <https://www.rfc-editor.org/info/rfc8055>.
[RISC] OpenID Foundation, "OpenID Risk and Incident Sharing and [RISC] OpenID Foundation, "OpenID Risk and Incident Sharing and
Coordination (RISC) Working Group", Coordination (RISC) Working Group",
<http://openid.net/wg/risc/>. <http://openid.net/wg/risc/>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The editors would like to thank the members of the IETF SCIM working The editors would like to thank the members of the IETF SCIM working
group, which began discussions of provisioning events starting with group, which began discussions of provisioning events starting with
draft-hunt-scim-notify-00 in 2015. draft-hunt-scim-notify-00 in 2015. The editors would like to thank
the participants in the IETF id-event mailing list, the Security
The editors would like to thank the participants in the IETF id-event Events working group, and related working groups for their
mailing list, the Security Events working group, and related working contributions to this specification. The specification incorporates
groups for their contributions to this specification. suggestions made by many people, including Annabelle Backman, John
Bradley, Dick Hardt, Russ Housley, Benjamin Kaduk, Mark Lizar, Andrew
Nash, Justin Richer, Nat Sakimura, Marius Scurtescu, and Yaron
Sheffer.
Appendix B. Change Log Appendix B. Change Log
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
From the original draft-hunt-idevent-token: From the original draft-hunt-idevent-token:
Draft 01 - PH - Renamed eventUris to events Draft 01 - PH - Renamed eventUris to events
Draft 00 - PH - First Draft Draft 00 - PH - First Draft
skipping to change at page 27, line 17 skipping to change at page 27, line 25
o Changed "when the event was issued" to "when the SET was issued" o Changed "when the event was issued" to "when the SET was issued"
in the "iat" description, as suggested by Annabelle Backman. in the "iat" description, as suggested by Annabelle Backman.
o Applied editorial improvements that improve the consistency of the o Applied editorial improvements that improve the consistency of the
specification that were suggested by Annabelle Backman, Marius specification that were suggested by Annabelle Backman, Marius
Scurtescu, and Yaron Sheffer. Scurtescu, and Yaron Sheffer.
Draft 07 - PH - Text refinement to Section 3 proposed by Annabelle Draft 07 - PH - Text refinement to Section 3 proposed by Annabelle
Backman post WGLC Backman post WGLC
Draft 08 - mbj - Changes were as follows:
o Incorporated wording improvements resulting from Russ Housley's
SecDir comments.
o Acknowledged individuals who made significant contributions.
Authors' Addresses Authors' Addresses
Phil Hunt (editor) Phil Hunt (editor)
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
Michael B. Jones Michael B. Jones
Microsoft Microsoft
 End of changes. 14 change blocks. 
31 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/