draft-ietf-secevent-http-push-07.txt   draft-ietf-secevent-http-push-08.txt 
Security Events Working Group A. Backman, Ed. Security Events Working Group A. Backman, Ed.
Internet-Draft Amazon Internet-Draft Amazon
Intended status: Standards Track M. Jones, Ed. Intended status: Standards Track M. Jones, Ed.
Expires: January 9, 2020 Microsoft Expires: August 8, 2020 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
July 8, 2019 February 5, 2020
Push-Based Security Event Token (SET) Delivery Using HTTP Push-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-push-07 draft-ietf-secevent-http-push-08
Abstract Abstract
This specification defines how a Security Event Token (SET) may be This specification defines how a Security Event Token (SET) may be
delivered to an intended recipient using HTTP POST. The SET is delivered to an intended recipient using HTTP POST. The SET is
transmitted in the body of an HTTP POST request to an endpoint transmitted in the body of an HTTP POST request to an endpoint
operated by the recipient, and the recipient indicates successful or operated by the recipient, and the recipient indicates successful or
failed transmission via the HTTP response. failed transmission via the HTTP response.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 9, 2020. This Internet-Draft will expire on August 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 5 2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 5
2.2. Success Response . . . . . . . . . . . . . . . . . . . . 6 2.2. Success Response . . . . . . . . . . . . . . . . . . . . 5
2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6 2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6
2.4. Security Event Token Delivery Error Codes . . . . . . . . 8 2.4. Security Event Token Delivery Error Codes . . . . . . . . 7
3. Authentication and Authorization . . . . . . . . . . . . . . 8 3. Authentication and Authorization . . . . . . . . . . . . . . 8
4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 9 4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Authentication Using Signed SETs . . . . . . . . . . . . 9 5.1. Authentication Using Signed SETs . . . . . . . . . . . . 9
5.2. Confidentiality of SETs . . . . . . . . . . . . . . . . . 9 5.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 9
5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 5.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 9
5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 10 5.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 10
5.5. Authenticating Persisted SETs . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Security Event Token Delivery Error Codes . . . . . . . . 10 7.1. Security Event Token Delivery Error Codes . . . . . . . . 11
7.1.1. Registration Template . . . . . . . . . . . . . . . . 11 7.1.1. Registration Template . . . . . . . . . . . . . . . . 11
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 11 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Other Streaming Specifications . . . . . . . . . . . 14 Appendix A. Other Streaming Specifications . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Overview 1. Introduction and Overview
This specification defines a mechanism by which a transmitter of a This specification defines a mechanism by which a transmitter of a
Security Event Token (SET) [RFC8417] may deliver the SET to an Security Event Token (SET) [RFC8417] may deliver the SET to an
intended recipient via HTTP POST [RFC7231]. intended recipient via HTTP POST [RFC7231].
Push-Based SET Delivery over HTTP POST is intended for scenarios Push-Based SET Delivery over HTTP POST is intended for scenarios
skipping to change at page 3, line 14 skipping to change at page 3, line 14
o The transmitter of the SET is capable of making outbound HTTP o The transmitter of the SET is capable of making outbound HTTP
requests. requests.
o The recipient is capable of hosting an HTTP endpoint that is o The recipient is capable of hosting an HTTP endpoint that is
accessible to the transmitter. accessible to the transmitter.
o The transmitter and recipient are known to one another. o The transmitter and recipient are known to one another.
A mechanism for exchanging configuration metadata such as endpoint A mechanism for exchanging configuration metadata such as endpoint
URLs and cryptographic key parameters between the transmitter and URLs and cryptographic keys between the transmitter and recipient is
recipient is out of scope for this specification. out of scope for this specification.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Throughout this document, all figures may contain spaces and extra Throughout this document, all figures may contain spaces and extra
line-wrapping for readability and due to space limitations. line wrapping for readability and due to space limitations.
1.2. Definitions 1.2. Definitions
This specification utilizes the following terms defined in [RFC8417]: This specification utilizes the following terms defined in [RFC8417]:
"Security Event Token (SET)", "SET Issuer", "SET Recipient", and "Security Event Token (SET)", "SET Issuer", "SET Recipient", and
"Event Payload". "Event Payload".
This specification utilizes terminology defined in [RFC8417], as well This specification utilizes terminology defined in [RFC8417], as well
as the terms defined below: as the terms defined below:
skipping to change at page 4, line 6 skipping to change at page 4, line 6
request with a response either acknowledging successful transmission request with a response either acknowledging successful transmission
of the SET or indicating that an error occurred while receiving, of the SET or indicating that an error occurred while receiving,
parsing, and/or validating the SET. parsing, and/or validating the SET.
Upon receipt of a SET, the SET Recipient SHALL validate that all of Upon receipt of a SET, the SET Recipient SHALL validate that all of
the following are true: the following are true:
o The SET Recipient can parse the SET. o The SET Recipient can parse the SET.
o The SET is authentic (i.e., it was issued by the issuer specified o The SET is authentic (i.e., it was issued by the issuer specified
within the SET). within the SET, and if signed, was signed by a key belonging to
the issuer).
o The SET Recipient is identified as an intended audience of the o The SET Recipient is identified as an intended audience of the
SET. SET.
o The SET Issuer is recognized as an issuer that the SET Recipient o The SET Issuer is recognized as an issuer that the SET Recipient
is willing to receive SETs from (e.g., the issuer is whitelisted is willing to receive SETs from (e.g., the issuer is whitelisted
by the SET Recipient). by the SET Recipient).
o The SET Recipient is willing to accept the SET when transmitted by o The SET Recipient is willing to accept the SET when transmitted by
the SET Transmitter (e.g., the SET Transmitter is expected to send the SET Transmitter (e.g., the SET Transmitter is expected to send
skipping to change at page 5, line 10 skipping to change at page 5, line 10
error (such as server unavailability that may be transient). In all error (such as server unavailability that may be transient). In all
other cases, the SET Transmitter SHOULD NOT re-transmit a SET. The other cases, the SET Transmitter SHOULD NOT re-transmit a SET. The
SET Transmitter SHOULD delay retransmission for an appropriate amount SET Transmitter SHOULD delay retransmission for an appropriate amount
of time to avoid overwhelming the SET Recipient (see Section 4). of time to avoid overwhelming the SET Recipient (see Section 4).
2.1. Transmitting a SET 2.1. Transmitting a SET
To transmit a SET to a SET Recipient, the SET Transmitter makes an To transmit a SET to a SET Recipient, the SET Transmitter makes an
HTTP POST request to an HTTP endpoint provided by the SET Recipient. HTTP POST request to an HTTP endpoint provided by the SET Recipient.
The "Content-Type" header of this request MUST be "application/ The "Content-Type" header of this request MUST be "application/
secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and secevent+jwt" as defined in Sections 2.3 and 7.2 of [RFC8417], and
the "Accept" header MUST be "application/json". The request body the "Accept" header MUST be "application/json". The request body
MUST consist of the SET itself, represented as a JWT [RFC7519]. MUST consist of the SET itself, represented as a JWT [RFC7519].
The SET Transmitter MAY include in the request an "Accept-Language" The SET Transmitter MAY include in the request an "Accept-Language"
header to indicate to the SET Recipient the preferred language(s) in header to indicate to the SET Recipient the preferred language(s) in
which to receive error messages. which to receive error messages.
The mechanisms by which the SET Transmitter determines the HTTP The mechanisms by which the SET Transmitter determines the HTTP
endpoint to use when transmitting a SET to a given SET Recipient are endpoint to use when transmitting a SET to a given SET Recipient are
not defined by this specification and are deployment specific. not defined by this specification and are deployment specific.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
request: request:
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.rp.example.com Host: notify.rp.example.com
Accept: application/json Accept: application/json
Accept-Language: en-US, en;q=0.5 Accept-Language: en-US, en;q=0.5
Content-Type: application/secevent+jwt Content-Type: application/secevent+jwt
eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg
. .
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iLCJqdGkiOiI3NTZFNjk
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj 3MTc1NjUyMDY5NjQ2NTZFNzQ2OTY2Njk2NTcyIiwiaWF0IjoxNTA4MTg0ODQ1LC
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ JhdWQiOiI2MzZDNjk2NTZFNzQ1RjY5NjQiLCJldmVudHMiOnsiaHR0cHM6Ly9zY
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ bnQtZGlzYWJsZWQiOnsic3ViamVjdCI6eyJzdWJqZWN0X3R5cGUiOiJpc3Mtc3V
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG iIiwiaXNzIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiwic3ViIjoiNzM3NT
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX YyNkE2NTYzNzQifSwicmVhc29uIjoiaGlqYWNraW5nIn19fQ
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQo
. .
Y4rXxMD406P2edv00cr9Wf3/XwNtLjB9n+jTqN1/lLc Y4rXxMD406P2edv00cr9Wf3_XwNtLjB9n-jTqN1_lLc
Figure 1: Example SET Transmission Request Figure 1: Example SET Transmission Request
2.2. Success Response 2.2. Success Response
If the SET is determined to be valid, the SET Recipient SHALL If the SET is determined to be valid, the SET Recipient SHALL
acknowledge successful transmission by responding with HTTP Response acknowledge successful transmission by responding with HTTP Response
Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). The Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). The
body of the response MUST be empty. body of the response MUST be empty.
skipping to change at page 8, line 30 skipping to change at page 8, line 24
| invalid_request | The request body cannot be parsed as a | | invalid_request | The request body cannot be parsed as a |
| | SET, or the Event Payload within the SET | | | SET, or the Event Payload within the SET |
| | does not conform to the event's | | | does not conform to the event's |
| | definition. | | | definition. |
| invalid_key | One or more keys used to encrypt or sign | | invalid_key | One or more keys used to encrypt or sign |
| | the SET is invalid or otherwise | | | the SET is invalid or otherwise |
| | unacceptable to the SET Recipient. (e.g., | | | unacceptable to the SET Recipient. (e.g., |
| | expired, revoked, failed certificate | | | expired, revoked, failed certificate |
| | validation, etc.) | | | validation, etc.) |
| authentication_failed | The SET Recipient could not authenticate | | authentication_failed | The SET Recipient could not authenticate |
| | the SET Transmitter from the contents of | | | the SET Transmitter. |
| | the request. |
| access_denied | The SET Transmitter is not authorized to | | access_denied | The SET Transmitter is not authorized to |
| | transmit the provided SET to the SET | | | transmit the SET to the SET Recipient. |
| | Recipient. |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 1: SET Delivery Error Codes Table 1: SET Delivery Error Codes
Implementations SHOULD expect that other Error Codes MAY also be
received, as the set of Error Codes is extensible via the IANA
"Security Event Token Delivery Error Codes" registry established in
Section 7.1.
3. Authentication and Authorization 3. Authentication and Authorization
The SET delivery method described in this specification is based upon The SET delivery method described in this specification is based upon
HTTP and depends on the use of TLS and/or standard HTTP HTTP and and HTTP over TLS [RFC2818] and/or standard HTTP
authentication and authorization schemes, as per [RFC7235]. authentication and authorization schemes, as per [RFC7235]. The TLS
server certificate MUST be validated, per [RFC6125].
Because SET Delivery describes a simple function, authorization for Authorization for the eligibility to provide actionable SETs can be
the ability to pick-up or deliver SETs can be derived by considering determined by using the identity of the SET Issuer, the identity of
the identity of the SET Issuer, or via other employed authentication the SET Transmitter, perhaps using mutual TLS, or via other employed
methods. Because SETs are not commands, SET Recipients are free to authentication methods. Because SETs are not commands, SET
ignore SETs that are not of interest. Recipients are free to ignore SETs that are not of interest.
4. Delivery Reliability 4. Delivery Reliability
Delivery reliability requirements may vary from implementation to Delivery reliability requirements may vary depending upon the use
implementation. This specification defines the response from the SET cases. This specification defines the response from the SET
Recipient in such a way as to provide the SET Transmitter with the Recipient in such a way as to provide the SET Transmitter with the
information necessary to determine what further action is required, information necessary to determine what further action is required,
if any, in order to meet their requirements. SET Transmitters with if any, in order to meet their requirements. SET Transmitters with
high reliability requirements may be tempted to always retry failed high reliability requirements may be tempted to always retry failed
transmissions, however it should be noted that for many types of SET transmissions, however, it should be noted that for many types of SET
delivery errors, a retry is extremely unlikely to be successful. For delivery errors, a retry is extremely unlikely to be successful. For
example, "invalid_request" indicates a structural error in the example, "invalid_request" indicates a structural error in the
content of the request body that is likely to remain when re- content of the request body that is likely to remain when re-
transmitting the same SET. Others such as "access_denied" may be transmitting the same SET. Others such as "access_denied" may be
transient, for example if the SET Transmitter refreshes expired transient, for example if the SET Transmitter refreshes expired
credentials prior to re-transmission. credentials prior to re-transmission.
Implementers SHOULD evaluate their reliability requirements and the Implementers SHOULD evaluate the reliability requirements of their
impact of various retry mechanisms on the performance of their use cases and the impact of various retry mechanisms on the
systems to determine the correct strategy for various error performance of their systems to determine an appropriate strategy for
conditions. handling various error conditions.
5. Security Considerations 5. Security Considerations
5.1. Authentication Using Signed SETs 5.1. Authentication Using Signed SETs
In scenarios where HTTP authorization or TLS mutual authentication In scenarios where HTTP authorization or TLS mutual authentication
are not used or are considered weak, JWS signed SETs SHOULD be used are not used or are considered weak, JWS signed SETs SHOULD be used
(see [RFC7515] and Security Considerations [RFC8417]). This enables (see [RFC7515] and Section 5 of [RFC8417]). This enables the SET
the SET Recipient to validate that the SET Transmitter is authorized Recipient to validate that the SET Transmitter is authorized to
to deliver the SET. deliver the SET.
5.2. Confidentiality of SETs 5.2. HTTP Considerations
SET delivery depends on the use of Hypertext Transfer Protocol and is
thus subject to the security considerations of HTTP Section 9 of
[RFC7230] and its related specifications.
As stated in Section 2.7.1 of [RFC7230], an HTTP requestor MUST NOT
generate the "userinfo" (i.e., username and password) component (and
its "@" delimiter) when an "http" URI reference is generated with a
message, as they are now disallowed in HTTP.
5.3. Confidentiality of SETs
SETs may contain sensitive information that is considered Personally SETs may contain sensitive information that is considered Personally
Identifiable Information (e.g., subject claims). In such cases, SET Identifiable Information (e.g., subject claims). In such cases, SET
Transmitters and SET Recipients MUST protect the confidentiality of Transmitters and SET Recipients MUST protect the confidentiality of
the SET contents by encrypting the SET as described in JWE [RFC7516], the SET contents by encrypting the SET as described in JWE [RFC7516],
using a transport-layer security mechanism such as TLS, or both. If using a transport-layer security mechanism such as TLS, or both. If
an Event delivery endpoint supports TLS, it MUST support at least TLS an Event delivery endpoint supports TLS, it MUST support at least TLS
version 1.2 [RFC5246] and SHOULD support the newest version of TLS version 1.2 [RFC5246] and SHOULD support the newest version of TLS
that meets its security requirements. When using TLS, the client that meets its security requirements, which as of the time of this
MUST perform a TLS/SSL server certificate check, per [RFC6125]. publication is TLS 1.3 [RFC8446]. When using TLS, the client MUST
perform a TLS/SSL server certificate check using DNS-ID [RFC6125].
Implementation security considerations for TLS can be found in Implementation security considerations for TLS can be found in
"Recommendations for Secure Use of TLS and DTLS" [RFC7525]. "Recommendations for Secure Use of TLS and DTLS" [RFC7525].
5.3. Denial of Service 5.4. Denial of Service
The SET Recipient may be vulnerable to a denial-of-service attack The SET Recipient may be vulnerable to a denial-of-service attack
where a malicious party makes a high volume of requests containing where a malicious party makes a high volume of requests containing
invalid SETs, causing the endpoint to expend significant resources on invalid SETs, causing the endpoint to expend significant resources on
cryptographic operations that are bound to fail. This may be cryptographic operations that are bound to fail. This may be
mitigated by authenticating SET Transmitters with a mechanism with mitigated by authenticating SET Transmitters with a mechanism with
low runtime overhead, such as mutual TLS. low runtime overhead, such as mutual TLS.
5.4. Authenticating Persisted SETs 5.5. Authenticating Persisted SETs
At the time of receipt, the SET Recipient can rely upon transport At the time of receipt, the SET Recipient can rely upon transport
layer mechanisms, HTTP authentication methods, and/or other context layer mechanisms, HTTP authentication methods, and/or other context
from the transmission request to authenticate the SET Transmitter and from the transmission request to authenticate the SET Transmitter and
validate the authenticity of the SET. However, this context is validate the authenticity of the SET. However, this context is
typically unavailable to systems that the SET Recipient forwards the typically unavailable to systems that the SET Recipient forwards the
SET onto, or to systems that retrieve the SET from storage. If the SET onto, or to systems that retrieve the SET from storage. If the
SET Recipient requires the ability to validate SET authenticity SET Recipient requires the ability to validate SET authenticity
outside of the context of the transmission request, then the SET outside of the context of the transmission request, then the SET
Recipient SHOULD ensure that such SETs have been signed in accordance Recipient SHOULD ensure that such SETs have been signed in accordance
with [RFC7515]. with [RFC7515].
6. Privacy Considerations 6. Privacy Considerations
If a SET needs to be retained for audit purposes, a JWS signature MAY
be used to provide verification of its authenticity.
When sharing personally identifiable information or information that When sharing personally identifiable information or information that
is otherwise considered confidential to affected users, SET is otherwise considered confidential to affected users, SET
Transmitters and Recipients MUST have the appropriate legal Transmitters and Recipients MUST have the appropriate legal
agreements and user consent or terms of service in place. agreements and user consent or terms of service in place.
Furthermore, data that needs confidentiality protection MUST be
encrypted, either via TLS or using JSON Web Encryption (JWE)
[RFC7516], or both.
In some cases subject identifiers themselves may be considered In some cases, subject identifiers themselves may be considered
sensitive information, such that its inclusion within a SET may be sensitive information, such that their inclusion within a SET may be
considered a violation of privacy. SET Transmitters should consider considered a violation of privacy. SET Transmitters should consider
the ramifications of sharing a particular subject identifier with a the ramifications of sharing a particular subject identifier with a
SET Recipient (e.g., whether doing so could enable correlation and/or SET Recipient (e.g., whether doing so could enable correlation and/or
de-anonymization of data), and choose appropriate subject identifiers de-anonymization of data), and choose appropriate subject identifiers
for their use case. for their use cases.
7. IANA Considerations 7. IANA Considerations
7.1. Security Event Token Delivery Error Codes 7.1. Security Event Token Delivery Error Codes
This document defines Security Event Token Delivery Error Codes, for This document defines Security Event Token Delivery Error Codes, for
which IANA is asked to create and maintain a new registry titled which IANA is asked to create and maintain a new registry titled
"Security Event Token Delivery Error Codes". Initial values for the "Security Event Token Delivery Error Codes". Initial values for the
Security Event Token Delivery Error Codes registry are given in Security Event Token Delivery Error Codes registry are defined in
Table 1. Future assignments are to be made through the First Come Table 1 and registered below. Future assignments are to be made
First Served registration policy ([RFC8126]) and shall follow the through the Specification Required registration policy ([RFC8126])
template presented in Section 7.1.1. and shall follow the template presented in Section 7.1.1.
Error Codes are intended to be interpreted by automated systems, and Error Codes are intended to be interpreted by automated systems, and
therefore SHOULD identify classes of errors to which an automated therefore SHOULD identify classes of errors to which an automated
system could respond in a meaningfully distinct way (e.g., by system could respond in a meaningfully distinct way (e.g., by
refreshing authentication credentials and retrying the request). refreshing authentication credentials and retrying the request).
7.1.1. Registration Template 7.1.1. Registration Template
Error Code Error Code
The name of the Security Event Token Delivery Error Code, as The name of the Security Event Token Delivery Error Code, as
skipping to change at page 11, line 46 skipping to change at page 12, line 11
name and description of the error code, and explain under what name and description of the error code, and explain under what
circumstances the error code may be used. URIs that can be used circumstances the error code may be used. URIs that can be used
to retrieve copies of each document at no cost SHOULD be included. to retrieve copies of each document at no cost SHOULD be included.
7.1.2. Initial Registry Contents 7.1.2. Initial Registry Contents
Error Code: invalid_request Error Code: invalid_request
Description: The request body cannot be parsed as a SET or the Description: The request body cannot be parsed as a SET or the
event payload within the SET does not conform to the event's event payload within the SET does not conform to the event's
definition. definition.
Change Controller: IETF Secevent Working Group Change Controller: IETF
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of [[ this specification ]]
Error Code: invalid_key Error Code: invalid_key
Description: One or more keys used to encrypt or sign the SET is Description: One or more keys used to encrypt or sign the SET is
invalid or otherwise unacceptable to the SET Recipient. (e.g., invalid or otherwise unacceptable to the SET Recipient. (e.g.,
expired, revoked, failed certificate validation, etc.) expired, revoked, failed certificate validation, etc.)
Change Controller: IETF Secevent Working Group Change Controller: IETF
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of [[ this specification ]]
Error Code: authentication_failed Error Code: authentication_failed
Description: The SET Recipient could not authenticate the SET Description: The SET Recipient could not authenticate the SET
Transmitter from the contents of the request. Transmitter.
Change Controller: IETF Secevent Working Group Change Controller: IETF
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of [[ this specification ]]
Error Code: access_denied Error Code: access_denied
Description: The SET Transmitter is not authorized to transmit the Description: The SET Transmitter is not authorized to transmit the
SET to the SET Recipient. SET to the SET Recipient.
Change Controller: IETF Secevent Working Group Change Controller: IETF
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of [[ this specification ]]
8. References 8. References
8.1. Normative References 8.1. Normative References
[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>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
January 1998, <https://www.rfc-editor.org/info/rfc2277>. January 1998, <https://www.rfc-editor.org/info/rfc2277>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
skipping to change at page 13, line 42 skipping to change at page 14, line 15
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari,
"Security Event Token (SET)", RFC 8417, "Security Event Token (SET)", RFC 8417,
DOI 10.17487/RFC8417, July 2018, DOI 10.17487/RFC8417, July 2018,
<https://www.rfc-editor.org/info/rfc8417>. <https://www.rfc-editor.org/info/rfc8417>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References 8.2. Informative References
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
Appendix A. Other Streaming Specifications Appendix A. Other Streaming Specifications
[[EDITORS NOTE: This section to be removed prior to publication]] [[ NOTE TO THE RFC EDITOR: This section to be removed prior to
publication ]]
The following pub/sub, queuing, streaming systems were reviewed as The following pub/sub, queuing, streaming systems were reviewed as
possible solutions or as input to the current draft: possible solutions or as input to the current draft:
Poll-Based Security Event Token (SET) Delivery Using HTTP Poll-Based Security Event Token (SET) Delivery Using HTTP
In addition to this specification, the WG is defining a polling-based In addition to this specification, the WG is defining a polling-based
SET delivery protocol. That protocol's draft (draft-ietf-secevent- SET delivery protocol. That protocol's draft (draft-ietf-secevent-
http-poll) describes it as: http-poll) describes it as:
skipping to change at page 16, line 7 skipping to change at page 16, line 23
draft-hunt-scim-notify-00 in 2015. draft-hunt-scim-notify-00 in 2015.
The editors would like to thank Phil Hunt and the other authors of The editors would like to thank Phil Hunt and the other authors of
draft-ietf-secevent-delivery-02, on which this draft is based. draft-ietf-secevent-delivery-02, on which this draft is based.
The editors would like to thank the participants in the the SecEvents The editors would like to thank the participants in the the SecEvents
working group for their contributions to this specification. working group for their contributions to this specification.
Appendix C. Change Log Appendix C. Change Log
[[ NOTE TO THE RFC EDITOR: This section to be removed prior to
publication ]]
Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the
following changes: following changes:
o Renamed to "Push-Based SET Token Delivery Using HTTP" o Renamed to "Push-Based SET Token Delivery Using HTTP"
o Removed references to the HTTP Polling delivery method. o Removed references to the HTTP Polling delivery method.
o Removed informative reference to RFC6202. o Removed informative reference to RFC6202.
Draft 01 - AB: Draft 01 - AB:
skipping to change at page 20, line 10 skipping to change at page 20, line 31
o Fixed error code format definition to match error codes defined in o Fixed error code format definition to match error codes defined in
doc. doc.
Draft 07 - AB: Draft 07 - AB:
o Made minor editorial corrections. o Made minor editorial corrections.
o Removed "SET Recipient" definition and added explicit list of o Removed "SET Recipient" definition and added explicit list of
terms used from RFC8417. terms used from RFC8417.
Draft 08 - mbj
o Addressed area director review comments by Benjamin Kaduk.
Authors' Addresses Authors' Addresses
Annabelle Backman (editor) Annabelle Backman (editor)
Amazon Amazon
Email: richanna@amazon.com Email: richanna@amazon.com
Michael B. Jones (editor) Michael B. Jones (editor)
Microsoft Microsoft
 End of changes. 46 change blocks. 
78 lines changed or deleted 113 lines changed or added

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