draft-ietf-secevent-http-poll-05.txt   draft-ietf-secevent-http-poll-06.txt 
Network Working Group A. Backman, Ed. Network 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: May 21, 2020 Microsoft Expires: May 22, 2020 Microsoft
M. Scurtescu M. Scurtescu
Coinbase Coinbase
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
November 18, 2019 November 19, 2019
Poll-Based Security Event Token (SET) Delivery Using HTTP Poll-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-poll-05 draft-ietf-secevent-http-poll-06
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 May 21, 2020. This Internet-Draft will expire on May 22, 2020.
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 41 skipping to change at page 2, line 41
4.1. Authentication Using Signed SETs . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 16
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction and Overview 1. Introduction and Overview
This specification defines how a stream of Security Event Tokens This specification defines how a stream of Security Event Tokens
(SETs) [RFC8417] can be transmitted to an intended SET Recipient (SETs) [RFC8417] can be transmitted to an intended SET Recipient
using HTTP [RFC7231] over TLS. The specification defines a method to using HTTP [RFC7231] over TLS. The specification defines a method to
poll for SETs using HTTP POST. This is an alternative SET delivery poll for SETs using HTTP POST. This is an alternative SET delivery
method to the one defined in [I-D.ietf-secevent-http-push]. method to the one defined in [I-D.ietf-secevent-http-push].
A mechanism for exchanging configuration metadata such as endpoint A mechanism for exchanging configuration metadata such as endpoint
skipping to change at page 7, line 7 skipping to change at page 7, line 7
next group of SETs in the SET Transmitters response. next group of SETs in the SET Transmitters response.
2.4.1. Poll Only Request 2.4.1. Poll Only Request
In the case where no SETs were received in a previous poll (see In the case where no SETs were received in a previous poll (see
Figure 7), the SET Recipient simply polls without acknowledgement Figure 7), the SET Recipient simply polls without acknowledgement
parameters ("ack" and "setErrs"). parameters ("ack" and "setErrs").
The following is an example request made by a SET Recipient that has The following is an example request made by a SET Recipient that has
no outstanding SETs to acknowledge and is polling for available SETs no outstanding SETs to acknowledge and is polling for available SETs
at the endpoint "https://nofity.exampleidp.com/Events": at the endpoint "https://notify.idp.example.com/Events":
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.exampleidp.com Host: notify.idp.example.com
Content-Type: application/json Content-Type: application/json
{ {
"returnImmediately": true "returnImmediately": true
} }
Figure 1: Example Initial Poll Request Figure 1: Example Initial Poll Request
A SET Recipient can poll using default parameter values by passing an A SET Recipient can poll using default parameter values by passing an
empty JSON object. empty JSON object.
The following is a non-normative example default poll request to the The following is a non-normative example default poll request to the
endpoint "https://nofity.exampleidp.com/Events": endpoint "https://notify.idp.example.com/Events":
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.exampleidp.com Host: notify.idp.example.com
Content-Type: application/json Content-Type: application/json
{} {}
Figure 2: Example Default Poll Request Figure 2: Example Default Poll Request
2.4.2. Acknowledge Only Request 2.4.2. Acknowledge Only Request
In this variation, the SET Recipient acknowledges previously received In this variation, the SET Recipient acknowledges previously received
SETs and indicates it does not want to receive SETs in response by SETs and indicates it does not want to receive SETs in response by
setting the "maxEvents" value to "0". setting the "maxEvents" value to "0".
This variation might be used, for instance, when a SET Recipient This variation might be used, for instance, when a SET Recipient
needs to acknowledge received SETs independently (e.g., on separate needs to acknowledge received SETs independently (e.g., on separate
threads) from the process of receiving SETs. threads) from the process of receiving SETs.
The following is a non-normative example poll request with The following is a non-normative example poll request with
acknowledgement of SETs received (for example as shown in Figure 6): acknowledgement of SETs received (for example as shown in Figure 6):
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.exampleidp.com Host: notify.idp.example.com
Content-Type: application/json Content-Type: application/json
{ {
"ack": [ "ack": [
"4d3559ec67504aaba65d40b0363faad8", "4d3559ec67504aaba65d40b0363faad8",
"3d0c3cf797584bd193bd0fb1bd4e7d30" "3d0c3cf797584bd193bd0fb1bd4e7d30"
], ],
"maxEvents": 0, "maxEvents": 0,
"returnImmediately": true "returnImmediately": true
} }
skipping to change at page 8, line 33 skipping to change at page 8, line 33
2.4.3. Poll with Acknowledgement 2.4.3. Poll with Acknowledgement
This variation allows a recipient thread to simultaneously This variation allows a recipient thread to simultaneously
acknowledge previously received SETs and wait for the next group of acknowledge previously received SETs and wait for the next group of
SETs in a single request. SETs in a single request.
The following is a non-normative example poll with acknowledgement of The following is a non-normative example poll with acknowledgement of
the SETs received in Figure 6: the SETs received in Figure 6:
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.exampleidp.com Host: notify.idp.example.com
Content-Type: application/json Content-Type: application/json
{ {
"ack": [ "ack": [
"4d3559ec67504aaba65d40b0363faad8", "4d3559ec67504aaba65d40b0363faad8",
"3d0c3cf797584bd193bd0fb1bd4e7d30" "3d0c3cf797584bd193bd0fb1bd4e7d30"
], ],
"returnImmediately": false "returnImmediately": false
} }
skipping to change at page 9, line 16 skipping to change at page 9, line 16
In the case where errors were detected in previously delivered SETs, In the case where errors were detected in previously delivered SETs,
the SET Recipient MAY use the "setErrs" member to communicate the the SET Recipient MAY use the "setErrs" member to communicate the
errors in the following poll request. errors in the following poll request.
The following is a non-normative example of a response acknowledging The following is a non-normative example of a response acknowledging
one successfully received SET and one SET with an error from the two one successfully received SET and one SET with an error from the two
SETs received in Figure 6: SETs received in Figure 6:
POST /Events HTTP/1.1 POST /Events HTTP/1.1
Host: notify.exampleidp.com Host: notify.idp.example.com
Content-Language: en-US Content-Language: en-US
Content-Type: application/json Content-Type: application/json
{ {
"ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"], "ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"],
"setErrs": { "setErrs": {
"4d3559ec67504aaba65d40b0363faad8": { "4d3559ec67504aaba65d40b0363faad8": {
"err": "jwtAud", "err": "jwtAud",
"description": "The audience value was invalid." "description": "The audience value was invalid."
} }
skipping to change at page 15, line 10 skipping to change at page 15, line 10
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-07 (work in
progress), July 2019. progress), July 2019.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
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
skipping to change at page 15, line 40 skipping to change at page 15, line 35
<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)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[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>.
skipping to change at page 16, line 17 skipping to change at page 16, line 12
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <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>.
7.2. Informative References 7.2. Informative References
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
DOI 10.17487/RFC6202, April 2011, DOI 10.17487/RFC6202, April 2011,
<https://www.rfc-editor.org/info/rfc6202>. <https://www.rfc-editor.org/info/rfc6202>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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>.
skipping to change at page 19, line 5 skipping to change at page 18, line 35
o Minor editorial fixes. o Minor editorial fixes.
Draft 05 - AB + mbj Draft 05 - AB + mbj
o Added normative text defining how to respond to invalid poll o Added normative text defining how to respond to invalid poll
requests. requests.
o Addressed shepherd comments by Yaron Sheffer. o Addressed shepherd comments by Yaron Sheffer.
Draft 06 - mbj
o Addressed nits identified by the idnits tool.
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. 18 change blocks. 
31 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/