draft-ietf-secevent-http-poll-08.txt   draft-ietf-secevent-http-poll-09.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: August 10, 2020 Microsoft Expires: October 31, 2020 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
February 7, 2020 April 29, 2020
Poll-Based Security Event Token (SET) Delivery Using HTTP Poll-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-poll-08 draft-ietf-secevent-http-poll-09
Abstract Abstract
This specification defines how a series of Security Event Tokens This specification defines how a series of Security Event Tokens
(SETs) may be delivered to an intended recipient using HTTP POST over (SETs) may be delivered to an intended recipient using HTTP POST over
TLS initiated as a poll by the recipient. The specification also TLS initiated as a poll by the recipient. The specification also
defines how delivery can be assured, subject to the SET Recipient's defines how delivery can be assured, subject to the SET Recipient's
need for assurance. need for assurance.
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 August 10, 2020. This Internet-Draft will expire on October 31, 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 31 skipping to change at page 2, line 31
2.4. Poll Request . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Poll Request . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Poll Only Request . . . . . . . . . . . . . . . . . . 7 2.4.1. Poll Only Request . . . . . . . . . . . . . . . . . . 7
2.4.2. Acknowledge Only Request . . . . . . . . . . . . . . 7 2.4.2. Acknowledge Only Request . . . . . . . . . . . . . . 7
2.4.3. Poll with Acknowledgement . . . . . . . . . . . . . . 8 2.4.3. Poll with Acknowledgement . . . . . . . . . . . . . . 8
2.4.4. Poll with Acknowledgement and Errors . . . . . . . . 9 2.4.4. Poll with Acknowledgement and Errors . . . . . . . . 9
2.5. Poll Response . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Poll Response . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1. Poll Error Response . . . . . . . . . . . . . . . . . 11 2.5.1. Poll Error Response . . . . . . . . . . . . . . . . . 11
2.6. Error Response Handling . . . . . . . . . . . . . . . . . 11 2.6. Error Response Handling . . . . . . . . . . . . . . . . . 11
3. Authentication and Authorization . . . . . . . . . . . . . . 12 3. Authentication and Authorization . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1. Authentication Using Signed SETs . . . . . . . . . . . . 13 4.1. Authentication Using Signed SETs . . . . . . . . . . . . 12
4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 13 4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 13
4.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 13 4.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 13
4.4. Access Token Considerations . . . . . . . . . . . . . . . 13 4.4. Access Token Considerations . . . . . . . . . . . . . . . 13
4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 13 4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 13
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
skipping to change at page 12, line 41 skipping to change at page 12, line 41
HTTP and HTTP over TLS [RFC2818] and/or standard HTTP authentication HTTP and HTTP over TLS [RFC2818] and/or standard HTTP authentication
and authorization schemes, as per [RFC7235]. The TLS server and authorization schemes, as per [RFC7235]. The TLS server
certificate MUST be validated, per [RFC6125]. As per Section 4.1 of certificate MUST be validated, per [RFC6125]. As per Section 4.1 of
[RFC7235], a SET delivery endpoint SHALL indicate supported HTTP [RFC7235], a SET delivery endpoint SHALL indicate supported HTTP
authentication schemes via the "WWW-Authenticate" header when using authentication schemes via the "WWW-Authenticate" header when using
HTTP authentication. HTTP authentication.
Authorization for the eligibility to provide actionable SETs can be Authorization for the eligibility to provide actionable SETs can be
determined by using the identity of the SET Issuer, validating the determined by using the identity of the SET Issuer, validating the
polling endpoint URL, perhaps using TLS, or via other employed polling endpoint URL, perhaps using TLS, or via other employed
authentication methods. Among other benefits, authentication can authentication methods. Because SETs are not commands, SET
help prevent denial-of-service attacks. Because SETs are not Recipients are free to ignore SETs that are not of interest after
commands, SET Recipients are free to ignore SETs that are not of acknowledging their receipt.
interest after acknowledging their receipt.
4. Security Considerations 4. Security Considerations
4.1. Authentication Using Signed SETs 4.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 Section 5 of [RFC8417]). This enables the SET (see [RFC7515] and Section 5 of [RFC8417]). This enables the SET
Recipient to validate that the SET Issuer is authorized to provide Recipient to validate that the SET Issuer is authorized to provide
actionable SETs. actionable SETs.
4.2. HTTP Considerations 4.2. HTTP Considerations
skipping to change at page 13, line 34 skipping to change at page 13, line 29
SETs may contain sensitive information that is considered Personally SETs may contain sensitive information that is considered Personally
Identifiable Information (PII). In such cases, SET Transmitters and Identifiable Information (PII). In such cases, SET Transmitters and
SET Recipients MUST protect the confidentiality of the SET contents SET Recipients MUST protect the confidentiality of the SET contents
by encrypting the SET as described in JWE [RFC7516], using a by encrypting the SET as described in JWE [RFC7516], using a
transport-layer security mechanism such as TLS, or both. If an Event transport-layer security mechanism such as TLS, or both. If an Event
delivery endpoint supports TLS, it MUST support at least TLS version delivery endpoint supports TLS, it MUST support at least TLS version
1.2 [RFC5246] and SHOULD support the newest version of TLS that meets 1.2 [RFC5246] and SHOULD support the newest version of TLS that meets
its security requirements, which as of the time of this publication its security requirements, which as of the time of this publication
is TLS 1.3 [RFC8446]. When using TLS, the client MUST perform a TLS/ is TLS 1.3 [RFC8446]. When using TLS, the client MUST perform a TLS/
SSL server certificate check using DNS-ID [RFC6125]. Implementation SSL server certificate check using DNS-ID [RFC6125]. How a SET
security considerations for TLS can be found in "Recommendations for Recipient determines the expected service identity to match the SET
Secure Use of TLS and DTLS" [RFC7525]. Transmitter's server certificate against is out of scope for this
document. Implementation security considerations for TLS can be
found in "Recommendations for Secure Use of TLS and DTLS" [RFC7525].
4.4. Access Token Considerations 4.4. Access Token Considerations
If HTTP Authentication is performed using OAuth access tokens If HTTP Authentication is performed using OAuth access tokens
[RFC6749], implementers MUST take into account the threats and [RFC6749], implementers MUST take into account the threats and
countermeasures documented in Section 8 of [RFC7521]. countermeasures documented in Section 8 of [RFC7521].
4.4.1. Bearer Token Considerations 4.4.1. Bearer Token Considerations
Due to the possibility of interception, Bearer tokens [RFC6750] MUST Due to the possibility of interception, Bearer tokens [RFC6750] MUST
skipping to change at page 19, line 21 skipping to change at page 19, line 13
o Addressed nits identified by the idnits tool. o Addressed nits identified by the idnits tool.
Draft 07 - mbj Draft 07 - mbj
o Addressed area director review comments by Benjamin Kaduk. o Addressed area director review comments by Benjamin Kaduk.
Draft 08 - mbj + AB Draft 08 - mbj + AB
o Corrected editorial nits. o Corrected editorial nits.
Draft 09 - AB
o Addressed area director review comments by Benamin Kaduk:
* Added text clarifying that determining the SET Recipient's
service identity is out of scope.
* Removed unelaborated reference to use of authentication to
prevent DoS attacks.
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. 9 change blocks. 
12 lines changed or deleted 24 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/