draft-ietf-secevent-token-09.txt   draft-ietf-secevent-token-10.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: October 19, 2018 Microsoft Expires: November 2, 2018 Microsoft
W. Denniss W. Denniss
Google Google
M. Ansari M. Ansari
Cisco Cisco
April 17, 2018 May 1, 2018
Security Event Token (SET) Security Event Token (SET)
draft-ietf-secevent-token-09 draft-ietf-secevent-token-10
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 October 19, 2018. This Internet-Draft will expire on November 2, 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 30 skipping to change at page 2, line 30
2. The Security Event Token (SET) . . . . . . . . . . . . . . . 5 2. The Security Event Token (SET) . . . . . . . . . . . . . . . 5
2.1. Illustrative Examples . . . . . . . . . . . . . . . . . . 6 2.1. Illustrative Examples . . . . . . . . . . . . . . . . . . 6
2.1.1. SCIM Example . . . . . . . . . . . . . . . . . . . . 6 2.1.1. SCIM Example . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Logout Example . . . . . . . . . . . . . . . . . . . 8 2.1.2. Logout Example . . . . . . . . . . . . . . . . . . . 8
2.1.3. Consent Example . . . . . . . . . . . . . . . . . . . 8 2.1.3. Consent Example . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . 13 2.4. Security Event Token Construction . . . . . . . . . . . . 13
3. Requirements for SET Profiles . . . . . . . . . . . . . . . . 14 3. Requirements for SET Profiles . . . . . . . . . . . . . . . . 14
4. Preventing Confusion between SETs and other JWTs . . . . . . 15 4. Preventing Confusion between SETs and other JWTs . . . . . . 16
4.1. Distinguishing SETs from ID Tokens . . . . . . . . . . . 16 4.1. Distinguishing SETs from ID Tokens . . . . . . . . . . . 16
4.2. Distinguishing SETs from Access Tokens . . . . . . . . . 16 4.2. Distinguishing SETs from Access Tokens . . . . . . . . . 16
4.3. Distinguishing SETs from other kinds of JWTs . . . . . . 17 4.3. Distinguishing SETs from other kinds of JWTs . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Confidentiality and Integrity . . . . . . . . . . . . . . 18 5.1. Confidentiality and Integrity . . . . . . . . . . . . . . 18
5.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Delivery . . . . . . . . . . . . . . . . . . . . . . . . 18
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. Media Type Registration . . . . . . . . . . . . . . . . . 20 7.2. Structured Syntax Suffix Registration . . . . . . . . . . 21
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 20 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Media Type Registration . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 14, line 46 skipping to change at page 14, line 46
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 of this specification define actual SETs to Profiling specifications of this specification define actual SETs to
be used in particular use cases. These profiling specifications be used in particular use cases. These profiling specifications
define the syntax and semantics of SETs conforming to that SET define the syntax and semantics of SETs conforming to that SET
profile and rules for validating those SETs. The syntax defined by profile and rules for validating those SETs. Profiling
profiling specifications includes what claims and event payload specifications SHOULD define syntax, semantics, subject
values are used by SETs utilizing the profile. identification, and validation.
Defining the semantics of the SET contents for SETs utilizing the Syntax
profile is equally important. Possibly most important is defining The syntax of the SETs defined, including:
the procedures used to validate the SET issuer and to obtain the keys
controlled by the issuer that were used for cryptographic operations
used in the JWT representing the SET. For instance, some profiles
may define an algorithm for retrieving the SET issuer's keys that
uses the "iss" claim value as its input. Likewise, if the profile
allows (or requires) that the JWT be unsecured, the means by which
the integrity of the JWT is ensured MUST be specified.
Profiling specifications MUST define how the event subject is Top-Level Claims
identified in the SET, as well as how to differentiate between the Claims and values placed at the JWT Claims Set. Examples are
event subject's issuer and the SET issuer, if applicable. It is NOT claims defined by the JWT specification (see [RFC7519]), the
RECOMMENDED for profiling specifications to use the "sub" claim in SET specification, and by the profiling specification.
cases in which the subject is not globally unique and has a different
issuer from the SET itself.
Among the syntax and semantics of SETs that a profiling specification Event Payload
may define is whether the value of the "events" claim may contain The JSON data structure contents and format, containing event-
multiple members, and what processing instructions are employed in specific information, if any (see Section 1.2).
the single- and multiple-valued cases for SETs conforming to that
profile. Many valid choices are possible. For instance, some
profiles might allow multiple event identifiers to be present and
specify that any that are not understood by recipients be ignored,
thus enabling extensibility. Other profiles might allow multiple
event identifiers to be present but require that all be understood if
the SET is to be accepted. Some profiles might require that only a
single value be present. All such choices are within the scope of
profiling specifications to define.
Profiling specifications MUST clearly specify the steps that a Semantics
recipient of a SET utilizing that profile MUST perform to validate Defining the semantics of the SET contents for SETs utilizing the
that the SET is both syntactically and semantically valid. profile is equally important. Possibly most important is defining
the procedures used to validate the SET issuer and to obtain the
keys controlled by the issuer that were used for cryptographic
operations used in the JWT representing the SET. For instance,
some profiles may define an algorithm for retrieving the SET
issuer's keys that uses the "iss" claim value as its input.
Likewise, if the profile allows (or requires) that the JWT be
unsecured, the means by which the integrity of the JWT is ensured
MUST be specified.
Subject Identification
Profiling specifications MUST define how the event subject is
identified in the SET, as well as how to differentiate between the
event subject's issuer and the SET issuer, if applicable. It is
NOT RECOMMENDED for profiling specifications to use the "sub"
claim in cases in which the subject is not globally unique and has
a different issuer from the SET itself.
Validation
Profiling specifications MUST clearly specify the steps that a
recipient of a SET utilizing that profile MUST perform to validate
that the SET is both syntactically and semantically valid.
Among the syntax and semantics of SETs that a profiling
specification may define is whether the value of the "events"
claim may contain multiple members, and what processing
instructions are employed in the single- and multiple-valued cases
for SETs conforming to that profile. Many valid choices are
possible. For instance, some profiles might allow multiple event
identifiers to be present and specify that any that are not
understood by recipients be ignored, thus enabling extensibility.
Other profiles might allow multiple event identifiers to be
present but require that all be understood if the SET is to be
accepted. Some profiles might require that only a single value be
present. All such choices are within the scope of profiling
specifications to define.
4. Preventing Confusion between SETs and other JWTs 4. Preventing Confusion between SETs and other JWTs
Because [RFC7519] states that "all claims that are not understood by Because [RFC7519] states that "all claims that are not understood by
implementations MUST be ignored", there is a consideration that a SET implementations MUST be ignored", there is a consideration that a SET
might be confused with another kind of JWT from the same issuer. might be confused with another kind of JWT from the same issuer.
Unless this confusion is prevented, this might enable an attacker who Unless this confusion is prevented, this might enable an attacker who
possesses a SET to use it in a context in which another kind of JWT possesses a SET to use it in a context in which another kind of JWT
is expected, or vice-versa. This section presents concrete is expected, or vice-versa. This section presents concrete
techniques for preventing confusion between SETs and several other techniques for preventing confusion between SETs and several other
skipping to change at page 20, line 43 skipping to change at page 21, line 5
o Claim Name: "toe" o Claim Name: "toe"
o Claim Description: Time of Event o Claim Description: Time of Event
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this specification ]] o Specification Document(s): Section 2.2 of [[ this specification ]]
o Claim Name: "txn" o Claim Name: "txn"
o Claim Description: Transaction Identifier o Claim Description: Transaction Identifier
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this specification ]] o Specification Document(s): Section 2.2 of [[ this specification ]]
7.2. Media Type Registration 7.2. Structured Syntax Suffix Registration
This section registers the "+jwt" structured syntax suffix [RFC6838]
in the "Structured Syntax Suffix" registry [IANA.StructuredSuffix] in
the manner described in [RFC6838], which can be used to indicate that
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 +suffix: +jwt
o References: [RFC7519]
o Encoding considerations: 8bit; JWT values are encoded as a series
of base64url-encoded values (some of which may be the empty
string) separated by period ('.') characters.
o Interoperability considerations: n/a
o Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for
+jwt SHOULD be as specified for "application/jwt". (At
publication of this document, there is no fragment identification
syntax defined for "application/jwt".)
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+jwt" SHOULD be processed as follows:
For cases defined in +jwt, where the fragment identifier resolves
per the +jwt rules, then process as specified in +jwt.
For cases defined in +jwt, where the fragment identifier does not
resolve per the +jwt rules, then process as specified in "xxx/
yyy+jwt".
For cases not defined in +jwt, then process as specified in "xxx/
yyy+jwt".
o Security considerations: See the Security Considerations section
of [RFC7519].
o Contact:
Michael B. Jones, mbj@microsoft.com
o Author/Change controller:
Security Events Working Group.
The IESG has change control over this registration.
7.3. Media Type Registration
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
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: 8bit; A SET is a JWT; JWT values are
skipping to change at page 21, line 42 skipping to change at page 23, line 5
8.1. Normative References 8.1. Normative References
[IANA.JWT.Claims] [IANA.JWT.Claims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<http://www.iana.org/assignments/jwt>. <http://www.iana.org/assignments/jwt>.
[IANA.MediaTypes] [IANA.MediaTypes]
IANA, "Media Types", IANA, "Media Types",
<http://www.iana.org/assignments/media-types>. <http://www.iana.org/assignments/media-types>.
[IANA.StructuredSuffix]
IANA, "Structured Syntax Suffix",
<https://www.iana.org/assignments/
media-type-structured-suffix/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 28, line 27 skipping to change at page 29, line 40
Draft 08 - mbj - Changes were as follows: Draft 08 - mbj - Changes were as follows:
o Incorporated wording improvements resulting from Russ Housley's o Incorporated wording improvements resulting from Russ Housley's
SecDir comments. SecDir comments.
o Acknowledged individuals who made significant contributions. o Acknowledged individuals who made significant contributions.
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:
o Incorporated wording improvements resulting from Russ Housley's
additional SecDir comments.
o Registered +jwt structured syntax suffix.
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. 17 change blocks. 
49 lines changed or deleted 120 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/