< draft-ietf-secevent-http-push-04.txt   draft-ietf-secevent-http-push-05.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: July 27, 2019 Microsoft Expires: September 12, 2019 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
January 23, 2019 March 11, 2019
Push-Based Security Event Token (SET) Delivery Using HTTP Push-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-push-04 draft-ietf-secevent-http-push-05
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 July 27, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . 4 2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 5
2.2. Success Response . . . . . . . . . . . . . . . . . . . . 5 2.2. Success Response . . . . . . . . . . . . . . . . . . . . 6
2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6 2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6
2.4. Security Event Token Delivery Error Codes . . . . . . . . 7 2.4. Security Event Token Delivery Error Codes . . . . . . . . 8
3. Authentication and Authorization . . . . . . . . . . . . . . 8 3. Authentication and Authorization . . . . . . . . . . . . . . 8
4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 8 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. TLS Support Considerations . . . . . . . . . . . . . . . 9 5.2. Confidentiality of SETs . . . . . . . . . . . . . . . . . 9
5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 10
5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 10 5.4. Authenticating Persisted SETs . . . . . . . . . . . . . . 10
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Security Event Token Delivery Error Codes . . . . . . . . 10 7.1. Security Event Token Delivery Error Codes . . . . . . . . 10
7.1.1. Registration Template . . . . . . . . . . . . . . . . 10 7.1.1. Registration Template . . . . . . . . . . . . . . . . 11
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 11 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . 13
Appendix A. Other Streaming Specifications . . . . . . . . . . . 13 Appendix A. Other Streaming Specifications . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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
where all of the following apply: where all of the following apply:
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 key parameters between the transmitter and
receipt is out of scope for this specifications. recipient is out of scope for this specifications.
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 documents all figures may contain spaces and extra Throughout this documents 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 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:
SET Transmitter SET Transmitter
An entity that delivers SETs in its possession to one or more SET An entity that delivers SETs in its possession to one or more SET
Recipients, as defined in [RFC8417]. Recipients.
SET Recipient SET Recipient
An entity that receives SETs through some distribution method, as An entity that receives SETs through some distribution method.
defined in [RFC8417].
2. SET Delivery 2. SET Delivery
To deliver a SET to a given SET Recipient, the SET Transmitter makes To deliver a SET to a given SET Recipient, the SET Transmitter makes
a SET Transmission Request to the SET Recipient, with the SET itself a SET transmission request to the SET Recipient, with the SET itself
contained within the request. The SET Recipient replies to this contained within the request. The SET Recipient replies to this
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).
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
the SET Transmitter (e.g., the SET Transmitter is expected to send
SETs with the subject of the SET in question).
The mechanisms by which the SET Recipient performs this validation The mechanisms by which the SET Recipient performs this validation
are out of scope for this document. SET parsing and issuer and are out of scope for this document. SET parsing and issuer and
audience identification are defined in [RFC8417]. The mechanism for audience identification are defined in [RFC8417]. The mechanism for
validating the authenticity of a SET is implementation specific, and validating the authenticity of a SET is deployment specific, and may
may vary depending on the authentication mechanisms in use, and vary depending on the authentication mechanisms in use, and whether
whether the SET is signed and/or encrypted (See Section 3). the SET is signed and/or encrypted (See Section 3).
SET Transmitters MAY transmit SETs issued by another entity. The SET
Recipient may accept or reject (i.e., return an "access_denied" error
response) at its own discretion.
The SET Recipient SHOULD ensure that the SET is persisted in a way The SET Recipient SHOULD ensure that the SET is persisted in a way
that is sufficient to meet the SET Recipient's own reliability that is sufficient to meet the SET Recipient's own reliability
requirements, and MUST NOT expect or depend on a SET Transmitter to requirements, and MUST NOT expect or depend on a SET Transmitter to
re-transmit or otherwise make available to the SET Recipient a SET re-transmit or otherwise make available to the SET Recipient a SET
once the SET Recipient acknowledges that it was received once the SET Recipient acknowledges that it was received
successfully. successfully.
Once the SET has been validated and persisted, the SET Recipient Once the SET has been validated and persisted, the SET Recipient
SHOULD immediately return a response indicating that the SET was SHOULD immediately return a response indicating that the SET was
successfully delivered. The SET Recipient SHOULD NOT perform successfully delivered. The SET Recipient SHOULD NOT perform
extensive business logic that processes the event expressed by the extensive business logic that processes the event expressed by the
SET prior to sending this response. Such logic SHOULD be executed SET prior to sending this response. Such logic SHOULD be executed
asynchronously from delivery, in order to minimize the expense and asynchronously from delivery, in order to minimize the expense and
impact of SET delivery on the SET Transmitter. impact of SET delivery on the SET Transmitter.
The SET Transmitter MAY re-transmit a SET if the responses from The SET Transmitter MAY re-transmit a SET if the responses from
previous transmissions timed out or indicated potentially recoverable previous transmissions timed out or indicated potentially recoverable
error (such as server unavailability that may be transient, or a error (such as server unavailability that may be transient). In all
decryption failure that may be due to misconfigured keys on the SET other cases, the SET Transmitter SHOULD NOT re-transmit a SET. The
Recipient's side). In all other cases, the SET Transmitter SHOULD SET Transmitter SHOULD delay retransmission for an appropriate amount
NOT re-transmit a SET. The SET Transmitter SHOULD delay of time to avoid overwhelming the SET Recipient (see Section 4).
retransmission for an appropriate amount 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.2 and 6.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 may be implementation-specific. not defined by this specification and are deployment specific.
The following is a non-normative example of a SET transmission The following is a non-normative example of a SET transmission
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
eyJhbGciOiJub25lIn0 eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg
. .
eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV eyJwdWJsaXNoZXJVcmkiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20iLCJmZWV
kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj kVXJpcyI6WyJodHRwczovL2podWIuZXhhbXBsZS5jb20vRmVlZHMvOThkNTI0Nj
FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ FmYTViYmM4Nzk1OTNiNzc1NCIsImh0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZ
WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6 WVkcy81ZDc2MDQ1MTZiMWQwODY0MWQ3Njc2ZWU3Il0sInJlc291cmNlVXJpcyI6
WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ WyJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcnMvNDRmNjE0MmRmOTZiZDZ
hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG hYjYxZTc1MjFkOSJdLCJldmVudFR5cGVzIjpbIkNSRUFURSJdLCJhdHRyaWJ1dG
VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX VzIjpbImlkIiwibmFtZSIsInVzZXJOYW1lIiwicGFzc3dvcmQiLCJlbWFpbHMiX
SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk SwidmFsdWVzIjp7ImVtYWlscyI6W3sidHlwZSI6IndvcmsiLCJ2YWx1ZSI6Impk
b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF b2VAZXhhbXBsZS5jb20ifV0sInBhc3N3b3JkIjoibm90NHUybm8iLCJ1c2VyTmF
tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW tZSI6Impkb2UiLCJpZCI6IjQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJuYW
1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQ 1lIjp7ImdpdmVuTmFtZSI6IkpvaG4iLCJmYW1pbHlOYW1lIjoiRG9lIn19fQo
. .
c2lnbmF0dXJl 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 acknowledge successful transmission by responding with HTTP Response
Response Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). The
The body of the response MUST be empty. body of the response MUST be empty.
The following is a non-normative example of a successful receipt of a The following is a non-normative example of a successful receipt of a
SET. SET.
HTTP/1.1 202 Accepted HTTP/1.1 202 Accepted
Figure 2: Example Successful Delivery Response Figure 2: Example Successful Delivery Response
Note that the purpose of the "acknowledgement" response is to let the Note that the purpose of the acknowledgement response is to let the
SET Transmitter know that a SET has been delivered and the SET Transmitter know that a SET has been delivered and the
information no longer needs to be retained by the SET Transmitter. information no longer needs to be retained by the SET Transmitter.
Before acknowledgement, SET Recipients SHOULD ensure they have Before acknowledgement, SET Recipients SHOULD ensure they have
validated received SETs and retained them in a manner appropriate to validated received SETs and retained them in a manner appropriate to
information retention requirements appropriate to the SET event types information retention requirements appropriate to the SET event types
signaled. The level and method of retention of SETs by SET signaled. The level and method of retention of SETs by SET
Recipients is out of scope of this specification. Recipients is out of scope of this specification.
2.3. Failure Response 2.3. Failure Response
In the event of a general HTTP error condition, the SET Recipient MAY In the event of a general HTTP error condition, the SET Recipient
respond with an appropriate HTTP Status Code as defined in Section 6 SHOULD respond with an appropriate HTTP Status Code as defined in
of [RFC7231]. Section 6 of [RFC7231].
When the SET Recipient detects an error parsing or validating a SET When the SET Recipient detects an error parsing or validating a SET
transmitted in a SET Transmission Request, the SET Recipient SHALL transmitted in a SET Transmission Request, the SET Recipient SHALL
respond with an HTTP Response Status Code of 400 (Bad Request). The respond with an HTTP Response Status Code of 400 (Bad Request). The
"Content-Type" header of this response MUST be "application/json", "Content-Type" header of this response MUST be "application/json",
and the body MUST be a UTF-8 encoded JSON [RFC7159] object containing and the body MUST be a UTF-8 encoded JSON [RFC7159] object containing
the following name/value pairs: the following name/value pairs:
err A Security Event Token Error Code (see Section 2.4). err A Security Event Token Error Code (see Section 2.4).
skipping to change at page 7, line 34 skipping to change at page 7, line 39
Content-Type: application/json Content-Type: application/json
{ {
"err": "authentication_failed", "err": "authentication_failed",
"description": "Access token is expired." "description": "Access token is expired."
} }
Figure 4: Example Error Response (authentication_failed) Figure 4: Example Error Response (authentication_failed)
The following is an example non-normative error response indicating The following is an example non-normative error response indicating
that the SET Transmitter is not permitted to transmit SETs issued by that the SET Receiver is not willing to accept SETs issued by the
the issuer specified in the SET. specified issuer from this particular SET Transmitter.
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Language: en-US Content-Language: en-US
Content-Type: application/json Content-Type: application/json
{ {
"err": "access_denied", "err": "access_denied",
"description": "Not authorized for issuer http://iss.example.com/." "description": "Not authorized for issuer http://iss.example.com/."
} }
skipping to change at page 8, line 37 skipping to change at page 8, line 43
| | transmit the provided SET to the SET | | | transmit the provided SET to the SET |
| | Recipient. | | | Recipient. |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 1: SET Delivery Error Codes Table 1: SET Delivery Error Codes
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 depends on the use of TLS and/or standard HTTP
authentication and authorization schemes as per [RFC7235]. authentication and authorization schemes, as per [RFC7235].
Because SET Delivery describes a simple function, authorization for Because SET Delivery describes a simple function, authorization for
the ability to pick-up or deliver SETs can be derived by considering the ability to pick-up or deliver SETs can be derived by considering
the identity of the SET issuer, or via other employed authentication the identity of the SET Issuer, or via other employed authentication
methods. Because SETs are not commands, SET Recipients are free to methods. Because SETs are not commands, SET Recipients are free to
ignore SETs that are not of interest. 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 from implementation to
implementation. This specification defines the response from the SET implementation. 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
skipping to change at page 9, line 25 skipping to change at page 9, line 33
systems to determine the correct strategy for various error systems to determine the correct strategy for various error
conditions. 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 Security Considerations [RFC8417]). This enables
the SET Recipient to validate that the SET issuer is authorized to the SET Recipient to validate that the SET Issuer is authorized to
deliver the SET. deliver the SET.
5.2. TLS Support Considerations 5.2. Confidentiality of SETs
SETs may contain sensitive information that is considered PII (e.g., SETs may contain sensitive information that is considered PII (e.g.,
subject claims). In such cases, SET Transmitters and SET Recipients subject claims). In such cases, SET Transmitters and SET Recipients
MUST require the use of a transport-layer security mechanism. Event MUST protect the confidentiality of the SET contents by encrypting
delivery endpoints MUST support TLS 1.2 [RFC5246] and MAY support the SET as described in JWE [RFC7516], using a transport-layer
additional transport-layer mechanisms meeting its security security mechanism such as TLS, or both. If an Event delivery
requirements. When using TLS, the client MUST perform a TLS/SSL endpoint supports TLS, it MUST support at least TLS version 1.2
server certificate check, per [RFC6125]. Implementation security [RFC5246] and SHOULD support the newest version of TLS that meets its
considerations for TLS can be found in "Recommendations for Secure security requirements. When using TLS, the client MUST perform a
Use of TLS and DTLS" [RFC7525]. TLS/SSL server certificate check, per [RFC6125]. Implementation
security considerations for TLS can be found in "Recommendations for
Secure Use of TLS and DTLS" [RFC7525].
5.3. Denial of Service 5.3. 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.4. 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
Transmitter SHOULD sign the SET in accordance with [RFC7515] and Transmitter SHOULD sign the SET in accordance with [RFC7515] and/or
optionally also encrypt it in accordance with [RFC7516]. encrypt it using authenticated encryption in accordance with
[RFC7516].
6. Privacy Considerations 6. Privacy Considerations
If a SET needs to be retained for audit purposes, a JWS signature MAY If a SET needs to be retained for audit purposes, a JWS signature MAY
be used to provide verification of its authenticity. 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.
The propagation of subject identifiers can be perceived as personally In some cases subject identifiers themselves may be considered
identifiable information. Where possible, SET Transmitters and sensitive information, such that its inclusion within a SET may be
Recipients SHOULD devise approaches that prevent propagation -- for considered a violation of privacy. SET Transmitters should consider
example, the passing of a hash value that requires the subscriber to the ramifications of sharing a particular subject identifier with a
already know the subject. SET Recipient (e.g., whether doing so could enable correlation and/or
de-anonymization of data), and choose appropriate subject identifiers
for their use case.
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 given in
Table 1. Future assignments are to be made through the Expert Review Table 1. Future assignments are to be made through the First Come
registration policy ([RFC8126]) and shall follow the template First Served registration policy ([RFC8126]) and shall follow the
presented in Section 7.1.1. template presented in Section 7.1.1.
Error Codes are intended to be interpreted by automated systems, and
therefore SHOULD identify classes of errors to which an automated
system could respond in a meaningfully distinct way (e.g., by
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
described in Section 2.4. The name MUST be a case-sensitive ASCII described in Section 2.4. The name MUST be a case-sensitive ASCII
string consisting only of upper-case letters ("A" - "Z"), lower- string consisting only of characters whose codes fall within the
case letters ("a" - "z"), and digits ("0" - "9"). inclusive ranges 0x20-23, 0x25-5B, and 0x5D-7E.
Description Description
A brief human-readable description of the Security Event Token A brief human-readable description of the Security Event Token
Delivery Error Code. Delivery Error Code.
Change Controller Change Controller
For error codes registered by the IETF or its working groups, list For error codes registered by the IETF or its working groups, list
"IETF Secevent Working Group". For all other error codes, list "IETF SecEvent Working Group". For all other error codes, list
the name of the party responsible for the registration. Contact the name of the party responsible for the registration. Contact
information such as mailing address, email address, or phone information such as mailing address, email address, or phone
number may also be provided. number may also be provided.
Defining Document(s) Defining Document(s)
A reference to the document or documents that define the Security A reference to the document or documents that define the Security
Event Token Delivery Error Code. The definition MUST specify the Event Token Delivery Error Code. The definition MUST specify the
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 Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
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 Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
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 from the contents of the request.
Change Controller: IETF Secevent Working Group Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
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
provided SET to the SET Recipient. SET to the SET Recipient.
Change Controller: IETF Secevent Working Group Change Controller: IETF Secevent Working Group
Defining Document(s): Section 2.4 of this document Defining Document(s): Section 2.4 of this document
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,
skipping to change at page 13, line 39 skipping to change at page 14, line 12
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]] [[EDITORS NOTE: 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
In addition to this specification, the WG is defining a polling-based
SET delivery protocol. That protocol's draft (draft-ietf-secevent-
http-poll) describes it as:
This specification defines how a series of Security Event Tokens
(SETs) may be delivered to an intended recipient using HTTP POST over
TLS initiated as a poll by the recipient. The specification also
defines how delivery can be assured, subject to the SET Recipient's
need for assurance.
XMPP Events XMPP Events
The WG considered the XMPP events ands its ability to provide a The WG considered the XMPP events ands its ability to provide a
single messaging solution without the need for both polling and push single messaging solution without the need for both polling and push
modes. The feeling was the size and methodology of XMPP was to far modes. The feeling was the size and methodology of XMPP was to far
apart from the current capabilities of the SECEVENTs community which apart from the current capabilities of the SECEVENTs community which
focuses in on HTTP based service delivery and authorization. focuses in on HTTP based service delivery and authorization.
Amazon Simple Notification Service Amazon Simple Notification Service
skipping to change at page 15, line 8 skipping to change at page 15, line 40
o Cloud Overview - https://cloud.google.com/pubsub/ o Cloud Overview - https://cloud.google.com/pubsub/
o Subscriber Overview - https://cloud.google.com/pubsub/docs/ o Subscriber Overview - https://cloud.google.com/pubsub/docs/
subscriber subscriber
o Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/pull o Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/pull
Appendix B. Acknowledgments Appendix B. Acknowledgments
The editors would like to thank the members of the SCIM working The editors would like to thank the members of the 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 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
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.
skipping to change at page 18, line 5 skipping to change at page 18, line 35
o Added "recognized issuer" validation requirement in section 2. o Added "recognized issuer" validation requirement in section 2.
o Added time outs as an acceptable reason to resend a SET in section o Added time outs as an acceptable reason to resend a SET in section
2. 2.
o Edited text in section 1 to clarify that configuration is out of o Edited text in section 1 to clarify that configuration is out of
scope. scope.
o Made minor editorial corrections. o Made minor editorial corrections.
Draft 05 - AB:
o Made minor editorial corrections.
o Updated example request with a correct SET header and signature.
o Revised TLS guidance to allow implementers to provide
confidentiality protection via JWE.
o Revised TLS guidance to require *at least* TLS 1.2.
o Revised TLS guidance to recommend supporting the newest version of
TLS that meets security requirements.
o Revised SET Delivery Error Code format to allow the same set of
characters as is allowed in error codes in RFC6749.
o Added mention of HTTP Poll spec to list of other streaming specs
in appendix.
o Added validation step requiring SET Recipient to verify that the
SET is one which the SET Transmitter is expected to send to the
SET Recipient.
o Changed responding to errors with an appropriate HTTP status code
from optional to recommended.
o Changed Error Codes registry change policy from Expert Review to
First Come First Served; added guidance that error codes are meant
to be consumed by automated systems.
o Added text making clear that it is up to SET Recipients whether or
not they will accept SETs where the SET Issuer is different from
the SET Transmitter.
o Reworded guidance around signing and/or encrypting SETs for
integrity protection.
o Renamed TLS "Support Considerations" section to "Confidentiality
of SETs".
o Reworded guidance around subject identifier selection and privacy
concerns.
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. 45 change blocks. 
72 lines changed or deleted 143 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/