draft-ietf-secevent-http-poll-07.txt   draft-ietf-secevent-http-poll-08.txt 
Security Events Working Group A. Backman, Ed. Security Events Working Group A. Backman, Ed.
Internet-Draft Amazon Internet-Draft Amazon
Intended status: Standards Track M. Jones, Ed. Intended status: Standards Track M. Jones, Ed.
Expires: August 8, 2020 Microsoft Expires: August 10, 2020 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
February 5, 2020 February 7, 2020
Poll-Based Security Event Token (SET) Delivery Using HTTP Poll-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-poll-07 draft-ietf-secevent-http-poll-08
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 8, 2020. This Internet-Draft will expire on August 10, 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 12, line 31 skipping to change at page 12, line 31
request to the SET Transmitter, it must also include in the request a request to the SET Transmitter, it must also include in the request a
"Content-Language" header whose value indicates the language of the "Content-Language" header whose value indicates the language of the
error descriptions included in the request. The method of language error descriptions included in the request. The method of language
selection in the case when the SET Recipient can provide error selection in the case when the SET Recipient can provide error
messages in multiple languages is out of scope for this messages in multiple languages is out of scope for this
specification. specification.
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 and HTTP over TLS [RFC2818] and/or standard HTTP HTTP and HTTP over TLS [RFC2818] and/or standard HTTP authentication
authentication and authorization schemes, as per [RFC7235]. The TLS and authorization schemes, as per [RFC7235]. The TLS server
server certificate MUST be validated, per [RFC6125]. As per certificate MUST be validated, per [RFC6125]. As per Section 4.1 of
Section 4.1 of [RFC7235], a SET delivery endpoint SHALL indicate [RFC7235], a SET delivery endpoint SHALL indicate supported HTTP
supported HTTP authentication schemes via the "WWW-Authenticate" authentication schemes via the "WWW-Authenticate" header when using
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. Among other benefits, authentication can
help prevent denial-of-service attacks. Because SETs are not help prevent denial-of-service attacks. Because SETs are not
commands, SET Recipients are free to ignore SETs that are not of commands, SET Recipients are free to ignore SETs that are not of
interest after acknowledging their receipt. interest after acknowledging their receipt.
4. Security Considerations 4. Security Considerations
skipping to change at page 14, line 37 skipping to change at page 14, line 37
agreements and user consent or terms of service in place. agreements and user consent or terms of service in place.
Furthermore, data that needs confidentiality protection MUST be Furthermore, data that needs confidentiality protection MUST be
encrypted, either via TLS or using JSON Web Encryption (JWE) encrypted, either via TLS or using JSON Web Encryption (JWE)
[RFC7516], or both. [RFC7516], or both.
In some cases, subject identifiers themselves may be considered In some cases, subject identifiers themselves may be considered
sensitive information, such that their inclusion within a SET may be sensitive information, such that their inclusion within a SET may be
considered a violation of privacy. SET Transmitters should consider considered a violation of privacy. SET Transmitters should consider
the ramifications of sharing a particular subject identifier with a the ramifications of sharing a particular subject identifier with a
SET Recipient (e.g., whether doing so could enable correlation and/or SET Recipient (e.g., whether doing so could enable correlation and/or
de-anonymization of data), and choose appropriate subject identifiers de-anonymization of data) and choose appropriate subject identifiers
for their use cases. for their use cases.
6. IANA Considerations 6. IANA Considerations
This specification requires no IANA actions. This specification requires no IANA actions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-secevent-http-push] [I-D.ietf-secevent-http-push]
Backman, A., Jones, M., Scurtescu, M., Ansari, M., and A. Backman, A., Jones, M., Scurtescu, M., Ansari, M., and A.
Nadalin, "Push-Based Security Event Token (SET) Delivery Nadalin, "Push-Based Security Event Token (SET) Delivery
Using HTTP", draft-ietf-secevent-http-push-07 (work in Using HTTP", draft-ietf-secevent-http-push-08 (work in
progress), July 2019. progress), February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
skipping to change at page 19, line 17 skipping to change at page 19, line 17
o Addressed shepherd comments by Yaron Sheffer. o Addressed shepherd comments by Yaron Sheffer.
Draft 06 - mbj Draft 06 - mbj
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
o Corrected editorial nits.
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. 8 change blocks. 
13 lines changed or deleted 17 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/