draft-ietf-secevent-http-push-13.txt   draft-ietf-secevent-http-push-14.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: December 26, 2020 Microsoft Expires: December 28, 2020 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
June 24, 2020 June 26, 2020
Push-Based Security Event Token (SET) Delivery Using HTTP Push-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-push-13 draft-ietf-secevent-http-push-14
Abstract Abstract
This specification defines how a Security Event Token (SET) can be This specification defines how a Security Event Token (SET) can be
delivered to an intended recipient using HTTP POST over TLS. The SET delivered to an intended recipient using HTTP POST over TLS. The SET
is transmitted in the body of an HTTP POST request to an endpoint is 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 December 26, 2020. This Internet-Draft will expire on December 28, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 9 4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Authentication Using Signed SETs . . . . . . . . . . . . 10 5.1. Authentication Using Signed SETs . . . . . . . . . . . . 10
5.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 10 5.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 10
5.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 10 5.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 10
5.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 5.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 11
5.5. Authenticating Persisted SETs . . . . . . . . . . . . . . 11 5.5. Authenticating Persisted SETs . . . . . . . . . . . . . . 11
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. Security Event Token Delivery Error Codes . . . . . . . . 12 7.1. Security Event Token Delivery Error Codes . . . . . . . . 12
7.1.1. Registration Template . . . . . . . . . . . . . . . . 12 7.1.1. Registration Template . . . . . . . . . . . . . . . . 13
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Unencrypted Transport Considerations . . . . . . . . 16 Appendix A. Unencrypted Transport Considerations . . . . . . . . 16
Appendix B. Other Streaming Specifications . . . . . . . . . . . 16 Appendix B. Other Streaming Specifications . . . . . . . . . . . 17
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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] can deliver the SET to an Security Event Token (SET) [RFC8417] can deliver the SET to an
intended SET Recipient via HTTP POST [RFC7231] over TLS. This is an intended SET Recipient via HTTP POST [RFC7231] over TLS. This is an
alternative SET delivery method to the one defined in alternative SET delivery method to the one defined in
[I-D.ietf-secevent-http-poll]. [I-D.ietf-secevent-http-poll].
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 4, line 39 skipping to change at page 4, line 39
identification, and audience identification are defined in [RFC8417]. identification, and audience identification are defined in [RFC8417].
The mechanism for validating the authenticity of a SET is deployment The mechanism for validating the authenticity of a SET is deployment
specific, and may vary depending on the authentication mechanisms in specific, and may vary depending on the authentication mechanisms in
use, and whether the SET is signed and/or encrypted (See Section 3). use, and whether 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 error response such Recipient may accept or reject (i.e., return an error response such
as "access_denied") a SET at its own discretion. as "access_denied") a SET at its own discretion.
The SET Recipient persists the SET in a way that is sufficient to The SET Recipient persists the SET in a way that is sufficient to
meet the SET Recipient's own reliability requirements, and MUST NOT meet the SET Recipient's own reliability requirements. The level and
expect or depend on a SET Transmitter to re-transmit or otherwise method of retention of SETs by SET Recipients is out of scope of this
make available to the SET Recipient a SET once the SET Recipient specification. Once the SET has been validated and persisted, the
acknowledges that it was received successfully. The level and method SET Recipient SHOULD immediately return a response indicating that
of retention of SETs by SET Recipients is out of scope of this the SET was successfully delivered. The SET Recipient SHOULD NOT
specification. perform further processing of the SET beyond the required validation
steps prior to sending this response. Any additional steps SHOULD be
executed asynchronously from delivery to minimize the time the SET
Transmitter is waiting for a response.
Once the SET has been validated and persisted, the SET Recipient The SET Transmitter MAY transmit the same SET to the SET Recipient
SHOULD immediately return a response indicating that the SET was multiple times, regardless of the response from the SET Recipient.
successfully delivered. The SET Recipient SHOULD NOT perform further The SET Recipient MUST respond as it would if the SET had not been
processing of the SET beyond the required validation steps prior to previously received by the SET Recipient. The SET Recipient MUST NOT
sending this response. Any additional steps SHOULD be executed expect or depend on a SET Transmitter to re-transmit a SET or
asynchronously from delivery to minimize the time the SET Transmitter otherwise make a SET available to the SET Recipient once the SET
is waiting for a response. Recipient acknowledges that it was received successfully.
The SET Transmitter MAY re-transmit a SET if the responses from The SET Transmitter should not re-transmit a SET unless the SET
previous transmissions timed out or indicated potentially recoverable Transmitter suspects that previous transmissions may have failed due
errors (such as server unavailability that may be transient). In all to potentially recoverable errors (such as network outage or
other cases, the SET Transmitter SHOULD NOT re-transmit a SET. The temporary service interruption at either the SET Transmitter or SET
SET Transmitter SHOULD delay retransmission for an appropriate amount Recipient). In all other cases, the SET Transmitter SHOULD NOT re-
of time to avoid overwhelming the SET Recipient (see Section 4). transmit a SET. The SET Transmitter SHOULD delay 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 a TLS-enabled HTTP endpoint provided by the SET HTTP POST request to a TLS-enabled HTTP endpoint provided by the SET
Recipient. The "Content-Type" header field of this request MUST be Recipient. The "Content-Type" header field of this request MUST be
"application/secevent+jwt" as defined in Sections 2.3 and 7.2 of "application/secevent+jwt" as defined in Sections 2.3 and 7.2 of
[RFC8417], and the "Accept" header field MUST be "application/json". [RFC8417], and the "Accept" header field MUST be "application/json".
The request body MUST consist of the SET itself, represented as a JWT The request body MUST consist of the SET itself, represented as a JWT
[RFC7519]. [RFC7519].
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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 transmissions. However, it should be noted that for many types of
SET delivery errors, a retry is extremely unlikely to be successful. SET delivery errors, a retry is extremely unlikely to be successful.
For example, "invalid_request" indicates a structural error in the For 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.
The SET Transmitter may be unaware of whether or not a SET has been
delivered to a SET Recipient. For example, a network interruption
could prevent the SET Transmitter from receiving the success
response, or a service outage could prevent the SET Transmitter from
recording the fact that the SET was delivered. It is left to the
implementer to decide how to handle such cases, based on their
requirements. For example, it may be appropriate for the SET
Transmitter to re-transmit the SET to the SET Recipient, erring on
the side of guaranteeing delivery, or it may be appropriate to assume
delivery was successful, erring on the side of not spending resources
re-transmitting previously delivered SETs. Other options, such as
sending the SET to a "dead letter queue" for manual examination may
also be appropriate.
Implementers SHOULD evaluate the reliability requirements of their Implementers SHOULD evaluate the reliability requirements of their
use cases and the impact of various retry mechanisms on the use cases and the impact of various retry mechanisms and re-
performance of their systems to determine an appropriate strategy for transmission policies on the performance of their systems to
handling various error conditions. determine an appropriate strategy for handling various error
conditions.
5. Security Considerations 5. Security Considerations
5.1. Authentication Using Signed SETs 5.1. Authentication Using Signed SETs
JWS signed SETs can be used (see [RFC7515] and Section 5 of JWS signed SETs can be used (see [RFC7515] and Section 5 of
[RFC8417]) to enable the SET Recipient to validate that the SET [RFC8417]) to enable the SET Recipient to validate that the SET
Issuer is authorized to provide actionable SETs. Issuer is authorized to provide actionable SETs.
5.2. HTTP Considerations 5.2. HTTP Considerations
skipping to change at page 15, line 51 skipping to change at page 16, line 19
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-secevent-http-poll] [I-D.ietf-secevent-http-poll]
Backman, A., Jones, M., Scurtescu, M., Ansari, M., and A. Backman, A., Jones, M., Scurtescu, M., Ansari, M., and A.
Nadalin, "Poll-Based Security Event Token (SET) Delivery Nadalin, "Poll-Based Security Event Token (SET) Delivery
Using HTTP", draft-ietf-secevent-http-poll-11 (work in Using HTTP", draft-ietf-secevent-http-poll-12 (work in
progress), June 2020. progress), June 2020.
[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. Unencrypted Transport Considerations Appendix A. Unencrypted Transport Considerations
Earlier versions of this specification made the use of TLS optional Earlier versions of this specification made the use of TLS optional
skipping to change at page 23, line 37 skipping to change at page 23, line 49
Draft 12 - mbj Draft 12 - mbj
o Revised to unambiguously require the use of TLS, while preserving o Revised to unambiguously require the use of TLS, while preserving
descriptions of precautions needed for non-TLS use in an appendix. descriptions of precautions needed for non-TLS use in an appendix.
Draft 13 - mbj Draft 13 - mbj
o Addressed IESG comments. o Addressed IESG comments.
Draft 14 - AB
o Revised normative requirements for SET re-transmission to clarify
"at least once" delivery expectiations.
o Added non-normative text to Section 4 - Delivery Reliability
describing conditions where re-transmission of successfully
delivered SETs may occur.
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. 15 change blocks. 
32 lines changed or deleted 61 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/