draft-ietf-secevent-http-push-05.txt   draft-ietf-secevent-http-push-06.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: September 12, 2019 Microsoft Expires: November 10, 2019 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
March 11, 2019 May 9, 2019
Push-Based Security Event Token (SET) Delivery Using HTTP Push-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-push-05 draft-ietf-secevent-http-push-06
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 September 12, 2019. This Internet-Draft will expire on November 10, 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 3, line 25 skipping to change at page 3, line 25
recipient 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 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 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. Recipients.
skipping to change at page 4, line 27 skipping to change at page 4, line 27
SETs with the subject of the SET in question). 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 deployment specific, and may validating the authenticity of a SET is deployment specific, and may
vary depending on the authentication mechanisms in use, and whether vary depending on the authentication mechanisms in use, and 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 SET Transmitters MAY transmit SETs issued by another entity. The SET
Recipient may accept or reject (i.e., return an "access_denied" error Recipient may accept or reject (i.e., return an error response such
response) at its own discretion. as "access_denied") a SET 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
skipping to change at page 6, line 34 skipping to change at page 6, line 34
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 In the event of a general HTTP error condition, the SET Recipient
SHOULD respond with an appropriate HTTP Status Code as defined in SHOULD respond with an appropriate HTTP Status Code as defined in
Section 6 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, validating or
transmitted in a SET Transmission Request, the SET Recipient SHALL authenticating a SET transmitted in a SET Transmission Request, the
respond with an HTTP Response Status Code of 400 (Bad Request). The SET Recipient SHALL respond with an HTTP Response Status Code of 400
"Content-Type" header of this response MUST be "application/json", (Bad Request). The "Content-Type" header of this response MUST be
and the body MUST be a UTF-8 encoded JSON [RFC7159] object containing "application/json", and the body MUST be a UTF-8 encoded JSON
the following name/value pairs: [RFC8259] object containing 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).
description A UTF-8 string containing a human-readable description description A UTF-8 string containing a human-readable description
of the error that MAY provide additional diagnostic information. of the error that MAY provide additional diagnostic information.
The exact content of this field is implementation-specific. The exact content of this field is implementation-specific.
The response MUST include a "Content-Language" header, whose value The response MUST include a "Content-Language" header, whose value
indicates the language of the error descriptions included in the indicates the language of the error descriptions included in the
response body. If the SET Recipient can provide error descriptions response body. If the SET Recipient can provide error descriptions
skipping to change at page 9, line 33 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 Transmitter is authorized
deliver the SET. to deliver the SET.
5.2. Confidentiality of SETs 5.2. Confidentiality of SETs
SETs may contain sensitive information that is considered PII (e.g., SETs may contain sensitive information that is considered Personally
subject claims). In such cases, SET Transmitters and SET Recipients Identifiable Information (e.g., subject claims). In such cases, SET
MUST protect the confidentiality of the SET contents by encrypting Transmitters and SET Recipients MUST protect the confidentiality of
the SET as described in JWE [RFC7516], using a transport-layer the SET contents by encrypting the SET as described in JWE [RFC7516],
security mechanism such as TLS, or both. If an Event delivery using a transport-layer security mechanism such as TLS, or both. If
endpoint supports TLS, it MUST support at least TLS version 1.2 an Event delivery endpoint supports TLS, it MUST support at least TLS
[RFC5246] and SHOULD support the newest version of TLS that meets its version 1.2 [RFC5246] and SHOULD support the newest version of TLS
security requirements. When using TLS, the client MUST perform a that meets its security requirements. When using TLS, the client
TLS/SSL server certificate check, per [RFC6125]. Implementation MUST perform a TLS/SSL server certificate check, per [RFC6125].
security considerations for TLS can be found in "Recommendations for Implementation security considerations for TLS can be found in
Secure Use of TLS and DTLS" [RFC7525]. "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/or Recipient SHOULD ensure that such SETs have been signed in accordance
encrypt it using authenticated encryption in accordance with with [RFC7515].
[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.
skipping to change at page 11, line 19 skipping to change at page 11, line 18
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
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 characters whose codes fall within the string consisting only of letters, digits and underscore, these
inclusive ranges 0x20-23, 0x25-5B, and 0x5D-7E. are the characters whose codes fall within the inclusive ranges
0x30-39, 0x41-5A, 0x5F and 0x61-7A.
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
skipping to change at page 12, line 47 skipping to change at page 12, line 47
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>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[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 37 skipping to change at page 13, line 32
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<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>.
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,
 End of changes. 13 change blocks. 
35 lines changed or deleted 36 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/