draft-ietf-secevent-token-10.txt   draft-ietf-secevent-token-11.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: November 2, 2018 Microsoft Expires: November 8, 2018 Microsoft
W. Denniss W. Denniss
Google Google
M. Ansari M. Ansari
Cisco Cisco
May 1, 2018 May 7, 2018
Security Event Token (SET) Security Event Token (SET)
draft-ietf-secevent-token-10 draft-ietf-secevent-token-11
Abstract Abstract
This specification defines the Security Event Token (SET) data This specification defines the Security Event Token (SET) data
structure. A SET describes statements of fact from the perspective structure. A SET describes statements of fact from the perspective
of an issuer about a subject. These statements of fact represent an of an issuer about a subject. These statements of fact represent an
event that occurred directly to or about a security subject, for event that occurred directly to or about a security subject, for
example, a statement about the issuance or revocation of a token on example, a statement about the issuance or revocation of a token on
behalf of a subject. This specification is intended to enable behalf of a subject. This specification is intended to enable
representing security- and identity-related events. A SET is a JSON representing security- and identity-related events. A SET is a JSON
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 November 2, 2018. This Internet-Draft will expire on November 8, 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 47 skipping to change at page 2, line 47
5.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Sequencing . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Preventing Confusion . . . . . . . . . . . . . . . . . . 19 5.5. Preventing Confusion . . . . . . . . . . . . . . . . . . 19
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. JSON Web Token Claims Registration . . . . . . . . . . . 20 7.1. JSON Web Token Claims Registration . . . . . . . . . . . 20
7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 20
7.2. Structured Syntax Suffix Registration . . . . . . . . . . 21 7.2. Structured Syntax Suffix Registration . . . . . . . . . . 21
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21
7.3. Media Type Registration . . . . . . . . . . . . . . . . . 21 7.3. Media Type Registration . . . . . . . . . . . . . . . . . 21
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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].
skipping to change at page 10, line 43 skipping to change at page 10, line 43
subject of the event is identified using the "subject" payload value, subject of the event is identified using the "subject" payload value,
which itself is a JSON object. which itself is a JSON object.
2.2. Core SET Claims 2.2. Core SET Claims
The following claims from [RFC7519] are profiled for use in SETs: The following claims from [RFC7519] are profiled for use in SETs:
"iss" (Issuer) Claim "iss" (Issuer) Claim
As defined by Section 4.1.1 of [RFC7519], this claim contains a As defined by Section 4.1.1 of [RFC7519], this claim contains a
string identifying the service provider publishing the SET (the string identifying the service provider publishing the SET (the
issuer). In some cases, the SET issuer is not the issuer of the issuer). In some cases, the issuer of the SET will not be the
security subject. Therefore, implementers cannot assume that the issuer associated with the security subject of the SET.
issuers are the same unless the profiling specification specifies Therefore, implementers cannot assume that the issuers are the
that they are for SETs conforming to that profile. This claim is same unless the profiling specification specifies that they are
REQUIRED. for SETs conforming to that profile. This claim is REQUIRED.
"iat" (Issued At) Claim "iat" (Issued At) Claim
As defined by Section 4.1.6 of [RFC7519], this claim contains a As defined by Section 4.1.6 of [RFC7519], this claim contains a
value representing when the SET was issued. This claim is value representing when the SET was issued. This claim is
REQUIRED. REQUIRED.
"jti" (JWT ID) Claim "jti" (JWT ID) Claim
As defined by Section 4.1.7 of [RFC7519], this claim contains a As defined by Section 4.1.7 of [RFC7519], this claim contains a
unique identifier for the SET. The identifier MUST be unique unique identifier for the SET. The identifier MUST be unique
within a particular event feed and MAY be used by clients to track within a particular event feed and MAY be used by clients to track
skipping to change at page 11, line 32 skipping to change at page 11, line 32
StringOrURI value representing the principal that is the subject StringOrURI value representing the principal that is the subject
of the SET. This is usually the entity whose "state" was changed. of the SET. This is usually the entity whose "state" was changed.
For example: For example:
* an IP Address was added to a black list; * an IP Address was added to a black list;
* a URI representing a user resource that was modified; or, * a URI representing a user resource that was modified; or,
* a token identifier (e.g. "jti") for a revoked token. * a token identifier (e.g. "jti") for a revoked token.
If used, the profiling specification SHOULD define the content and If used, the profiling specification MUST define the content and
format semantics for the value. This claim is OPTIONAL, as the format semantics for the value. This claim is OPTIONAL, as the
principal for any given profile may already be identified without principal for any given profile may already be identified without
the inclusion of a subject claim. Note that some SET profiles MAY the inclusion of a subject claim. Note that some SET profiles MAY
choose to convey event subject information in the event payload choose to convey event subject information in the event payload
(either using the "sub" member name or another name), particularly (either using the "sub" member name or another name), particularly
if the subject information is relative to issuer information that if the subject information is relative to issuer information that
is also conveyed in the event payload, which may be the case for is also conveyed in the event payload, which may be the case for
some identity SET profiles. some identity SET profiles.
"exp" (Expiration Time) Claim "exp" (Expiration Time) Claim
skipping to change at page 17, line 44 skipping to change at page 17, line 44
The most direct way to prevent confusion is to employ explicit The most direct way to prevent confusion is to employ explicit
typing, as described in Section 2.3, and modify applicable token typing, as described in Section 2.3, and modify applicable token
validation systems to use the "typ" header parameter value. This validation systems to use the "typ" header parameter value. This
approach can be employed for new systems but may not be applicable to approach can be employed for new systems but may not be applicable to
existing systems. existing systems.
Another way to ensure that a SET is not confused with another kind of Another way to ensure that a SET is not confused with another kind of
JWT is to have the JWT validation logic reject JWTs containing an JWT is to have the JWT validation logic reject JWTs containing an
"events" claim unless the JWT is intended to be a SET. This approach "events" claim unless the JWT is intended to be a SET. This approach
can be employed for new systems but may not be applicable to existing can be employed for new systems but may not be applicable to existing
systems. systems. Validating that the JWT has an "events" claim will be
effective in preventing attackers from passing other kinds of JWTs
off as SETs.
For many use cases, the simplest way to prevent substitution is For many use cases, the simplest way to prevent substitution is
requiring that the SET not include claims that are required for the requiring that the SET not include claims that are required for the
kind of JWT that might be the target of an attack. For example, for kind of JWT that might be the target of an attack. For example, for
[RFC8055], the "sip_callid" claim could be omitted and for [RFC8225], [RFC8055], the "sip_callid" claim could be omitted and for [RFC8225],
the "orig" claim could be omitted. the "orig" claim could be omitted.
In many contexts, simple measures such as these will accomplish the In many contexts, simple measures such as these will accomplish the
task, should confusion otherwise even be possible. Note that this task, should confusion otherwise even be possible. Note that this
topic is being explored in a more general fashion in JSON Web Token topic is being explored in a more general fashion in JSON Web Token
skipping to change at page 18, line 30 skipping to change at page 18, line 30
transport-layer mechanisms meeting its security requirements. When transport-layer mechanisms meeting its security requirements. When
using TLS, the client MUST perform a TLS server certificate check, using TLS, the client MUST perform a TLS server certificate check,
per [RFC6125]. Implementation security considerations for TLS can be per [RFC6125]. Implementation security considerations for TLS can be
found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525].
Security events distributed through third parties or that carry Security events distributed through third parties or that carry
personally identifiable information SHOULD be encrypted using JWE personally identifiable information SHOULD be encrypted using JWE
[RFC7516] or secured for confidentiality by other means. [RFC7516] or secured for confidentiality by other means.
Unless integrity of the JWT is ensured by other means, it MUST be Unless integrity of the JWT is ensured by other means, it MUST be
signed using JWS [RFC7515] so that the SET can be authenticated and signed using JWS [RFC7515] by an issuer that is trusted to do so for
validated by the SET recipient. the use case so that the SET can be authenticated and validated by
the SET recipient.
5.2. Delivery 5.2. Delivery
This specification does not define a delivery mechanism for SETs. In This specification does not define a delivery mechanism for SETs. In
addition to confidentiality and integrity (discussed above), addition to confidentiality and integrity (discussed above),
implementers and profiling specifications MUST consider the implementers and profiling specifications MUST consider the
consequences of delivery mechanisms that are not secure and/or not consequences of delivery mechanisms that are not secure and/or not
assured. For example, while a SET may be end-to-end secured using assured. For example, while a SET may be end-to-end secured using
JWE encrypted SETs, without (mutual) TLS, there is no assurance that JWE encrypted SETs, without (mutual) TLS, there is no assurance that
the correct endpoint received the SET and that it could be the correct endpoint received the SET and that it could be
skipping to change at page 19, line 25 skipping to change at page 19, line 25
issuer includes, although just as for timestamps, ensuring such issuer includes, although just as for timestamps, ensuring such
ordering can be difficult in distributed systems. ordering can be difficult in distributed systems.
5.4. Timing Issues 5.4. Timing Issues
When SETs are delivered asynchronously and/or out-of-band with When SETs are delivered asynchronously and/or out-of-band with
respect to the original action that incurred the security event, it respect to the original action that incurred the security event, it
is important to consider that a SET might be delivered to a SET is important to consider that a SET might be delivered to a SET
recipient in advance of or behind the process that caused the event. recipient in advance of or behind the process that caused the event.
For example, a user having been required to log out and then log back For example, a user having been required to log out and then log back
in again, may cause a token revoked SET to be issued, typically in again, may cause a "token revoked" SET to be issued, typically
causing the receiver to reset all active sessions at the receiver causing the receiver to reset all active sessions at the receiver
that are related to that user. If revocation SET arrives at the same that are related to that user. If revocation SET arrives at the same
time as the user agent re-logs in, timing could cause problems by time as the user agent re-logs in, timing could cause problems by
erroneously treating the new user session as logged out. Profiling erroneously treating the new user session as logged out. Profiling
specifications SHOULD be careful to consider both SET expression and specifications SHOULD be careful to consider both SET expression and
timing issues. For example, it might be more appropriate to revoke a timing issues. For example, it might be more appropriate to revoke a
specific session or identity token rather than a general logout specific session or identity token rather than a general logout
statement about a "user". Alternatively, profiling specifications statement about a "user". Alternatively, profiling specifications
could use timestamps that allow new sessions to be started could use timestamps that allow new sessions to be started
immediately after a stated logout event time. immediately after a stated logout event time.
skipping to change at page 21, line 16 skipping to change at page 21, line 16
This section registers the "+jwt" structured syntax suffix [RFC6838] This section registers the "+jwt" structured syntax suffix [RFC6838]
in the "Structured Syntax Suffix" registry [IANA.StructuredSuffix] in in the "Structured Syntax Suffix" registry [IANA.StructuredSuffix] in
the manner described in [RFC6838], which can be used to indicate that the manner described in [RFC6838], which can be used to indicate that
the media type is encoded as a JWT. the media type is encoded as a JWT.
7.2.1. Registry Contents 7.2.1. Registry Contents
o Name: JSON Web Token (JWT) o Name: JSON Web Token (JWT)
o +suffix: +jwt o +suffix: +jwt
o References: [RFC7519] o References: Section 3 of [RFC7519]
o Encoding considerations: 8bit; JWT values are encoded as a series o Encoding considerations: binary; JWT values are encoded as a
of base64url-encoded values (some of which may be the empty series of base64url-encoded values (some of which may be the empty
string) separated by period ('.') characters. string) separated by period ('.') characters.
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Fragment identifier considerations: o Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for The syntax and semantics of fragment identifiers specified for
+jwt SHOULD be as specified for "application/jwt". (At +jwt SHOULD be as specified for "application/jwt". (At
publication of this document, there is no fragment identification publication of this document, there is no fragment identification
syntax defined for "application/jwt".) syntax defined for "application/jwt".)
The syntax and semantics for fragment identifiers for a specific The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+jwt" SHOULD be processed as follows: "xxx/yyy+jwt" SHOULD be processed as follows:
For cases defined in +jwt, where the fragment identifier resolves For cases defined in +jwt, where the fragment identifier resolves
per the +jwt rules, then process as specified in +jwt. per the +jwt rules, then process as specified in +jwt.
For cases defined in +jwt, where the fragment identifier does not For cases defined in +jwt, where the fragment identifier does not
resolve per the +jwt rules, then process as specified in "xxx/ resolve per the +jwt rules, then process as specified in "xxx/
yyy+jwt". yyy+jwt".
For cases not defined in +jwt, then process as specified in "xxx/ For cases not defined in +jwt, then process as specified in "xxx/
yyy+jwt". yyy+jwt".
o Security considerations: See the Security Considerations section o Security considerations: See Section 11 of [RFC7519].
of [RFC7519].
o Contact: o Contact:
Michael B. Jones, mbj@microsoft.com Michael B. Jones, mbj@microsoft.com
o Author/Change controller: o Author/Change controller:
Security Events Working Group. Security Events Working Group.
The IESG has change control over this registration. The IESG has change control over this registration.
7.3. Media Type Registration 7.3. Media Type Registration
7.3.1. Registry Contents 7.3.1. Registry Contents
This section registers the "application/secevent+jwt" media type This section registers the "application/secevent+jwt" media type
[RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
manner described in [RFC6838], which can be used to indicate that the manner described in [RFC6838], which can be used to indicate that the
content is a SET. content is a SET.
o Type name: application o Type name: application
o Subtype name: secevent+jwt o Subtype name: secevent+jwt
o Required parameters: n/a o Required parameters: n/a
skipping to change at page 22, line 15 skipping to change at page 22, line 11
This section registers the "application/secevent+jwt" media type This section registers the "application/secevent+jwt" media type
[RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the
manner described in [RFC6838], which can be used to indicate that the manner described in [RFC6838], which can be used to indicate that the
content is a SET. content is a SET.
o Type name: application o Type name: application
o Subtype name: secevent+jwt o Subtype name: secevent+jwt
o Required parameters: n/a o Required parameters: n/a
o Optional parameters: n/a o Optional parameters: n/a
o Encoding considerations: 8bit; A SET is a JWT; JWT values are o Encoding considerations: binary; A SET is a JWT; JWT values are
encoded as a series of base64url-encoded values (some of which may encoded as a series of base64url-encoded values (some of which may
be the empty string) separated by period ('.') characters. be the empty string) separated by period ('.') characters.
o Security considerations: See the Security Considerations section o Security considerations: See Section 5 of [[ this specification ]]
of [[ this specification ]]
o Interoperability considerations: n/a o Interoperability considerations: n/a
o Published specification: Section 2.3 of [[ this specification ]] o Published specification: Section 2.3 of [[ this specification ]]
o Applications that use this media type: TBD o Applications that use this media type: Applications that exchange
SETs
o Fragment identifier considerations: n/a o Fragment identifier considerations: n/a
o Additional information: o Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): n/a File extension(s): n/a
Macintosh file type code(s): n/a Macintosh file type code(s): n/a
o Person & email address to contact for further information: o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON o Intended usage: COMMON
skipping to change at page 25, line 27 skipping to change at page 25, line 22
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. The editors would like to thank 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 participants in the IETF id-event mailing list, the Security
Events working group, and related working groups for their Events working group, and related working groups for their
contributions to this specification. The specification incorporates contributions to this specification. The specification incorporates
suggestions made by many people, including Annabelle Backman, John suggestions made by many people, including Annabelle Backman, John
Bradley, Dick Hardt, Russ Housley, Benjamin Kaduk, Mark Lizar, Andrew Bradley, Ned Freed, Dick Hardt, Russ Housley, Benjamin Kaduk, Mark
Nash, Justin Richer, Nat Sakimura, Marius Scurtescu, and Yaron Lizar, Andrew Nash, Eric Rescorla, Justin Richer, Nat Sakimura,
Sheffer. 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 29, line 47 skipping to change at page 29, line 40
Draft 09 - pjh/mbj - Changes addressing AD review comments by Draft 09 - pjh/mbj - Changes addressing AD review comments by
Benjamin Kaduk Benjamin Kaduk
Draft 10 - pjh/mbj - Changes were as follows: Draft 10 - pjh/mbj - Changes were as follows:
o Incorporated wording improvements resulting from Russ Housley's o Incorporated wording improvements resulting from Russ Housley's
additional SecDir comments. additional SecDir comments.
o Registered +jwt structured syntax suffix. o Registered +jwt structured syntax suffix.
Draft 11 - pjh/mbj - Incorporated feedback from Security Area
Director Eric Rescorla and IANA Designated Expert Ned Freed.
o Clarified "iss" claim language about the SET issuer versus the
security subject issuer.
o Changed a "SHOULD" to a "MUST" in the "sub" claim description to
be consistent with the Requirements for SET Profiles section.
o Described the use of the "events" claim to prevent attackers from
passing off other kinds of JWTs as SETs.
o Stated that SETs are to be signed by an issuer that is trusted to
do so for the use case.
o Added quotes in the phrase '"token revoked" SET to be issued' in
the Timing Issues section.
o Added section number references to the media type and media type
suffix registrations.
o Changed the encodings of the media type and media type suffix
registrations to binary (since no line breaks are allowed).
o Replaced a "TBD" in the media type registration with descriptive
text.
o Acknowledged Eric Rescorla and Ned Freed.
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
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
William Denniss William Denniss
Google Google
Email: wdenniss@google.com Email: wdenniss@google.com
 End of changes. 21 change blocks. 
29 lines changed or deleted 62 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/