Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
draft-ietf-ace-dtls-authorize-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-04-20
|
18 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-03-29
|
Tina Dang | Posted related IPR disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ace-dtls-authorize | |
2022-03-25
|
Jenny Bui | Posted related IPR disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ace-dtls-authorize | |
2022-03-01
|
18 | (System) | RFC Editor state changed to AUTH48 |
2021-11-29
|
18 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2021-09-15
|
18 | (System) | RFC Editor state changed to REF from IANA |
2021-09-02
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-09-02
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-09-02
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-09-01
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-09-01
|
18 | (System) | IANA Action state changed to In Progress from On Hold |
2021-08-31
|
18 | (System) | RFC Editor state changed to IANA from REF |
2021-08-31
|
18 | (System) | RFC Editor state changed to REF from EDIT |
2021-08-03
|
18 | (System) | RFC Editor state changed to EDIT from IESG |
2021-07-28
|
18 | (System) | IANA Action state changed to On Hold from Waiting on Authors |
2021-07-27
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-07-27
|
18 | (System) | RFC Editor state changed to IESG from EDIT |
2021-07-23
|
18 | (System) | RFC Editor state changed to EDIT |
2021-07-23
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-07-23
|
18 | (System) | Announcement was received by RFC Editor |
2021-07-23
|
18 | (System) | IANA Action state changed to In Progress |
2021-07-22
|
18 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-07-22
|
18 | Cindy Morgan | IESG has approved the document |
2021-07-22
|
18 | Cindy Morgan | Closed "Approve" ballot |
2021-07-22
|
18 | Cindy Morgan | Ballot approval text was generated |
2021-07-22
|
18 | (System) | Removed all action holders (IESG state changed) |
2021-07-22
|
18 | Benjamin Kaduk | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-06-04
|
18 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-18.txt |
2021-06-04
|
18 | (System) | New version approved |
2021-06-04
|
18 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Goeran Selander , Ludwig Seitz , Olaf Bergmann , Stefanie Gerdes |
2021-06-04
|
18 | Olaf Bergmann | Uploaded new revision |
2021-05-12
|
17 | Roman Danyliw | [Ballot comment] Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. Thanks for addressing my … [Ballot comment] Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. Thanks for addressing my DISCUSS and COMMENT feedback. |
2021-05-12
|
17 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2021-05-11
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-05-11
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-05-11
|
17 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-17.txt |
2021-05-11
|
17 | (System) | New version approved |
2021-05-11
|
17 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Goeran Selander , Ludwig Seitz , Olaf Bergmann , Stefanie Gerdes , ace-chairs@ietf.org |
2021-05-11
|
17 | Olaf Bergmann | Uploaded new revision |
2021-03-25
|
16 | (System) | Changed action holders to Carsten Bormann, Ludwig Seitz, Olaf Bergmann, Benjamin Kaduk, Göran Selander, Stefanie Gerdes (IESG state changed) |
2021-03-25
|
16 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-03-25
|
16 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-03-25
|
16 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2021-03-25
|
16 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. Like Eric V, I was slightly surprised to see this defined to use DTLS 1.2 when DTLS 1.3 … [Ballot comment] Hi, Thanks for this document. Like Eric V, I was slightly surprised to see this defined to use DTLS 1.2 when DTLS 1.3 is on the same telechat, which is obsoleting the DTLS 1.2 RFC. But what is not obvious to me is whether the protocol is allowed to use a later version of DTLS, or whether it is strictly tied to DTLS 1.2 and an updated RFC would be required to use a newer version of DTLS. Either way, possibly a few words to clarify this may be beneficial to readers, but I'll leave it to the author's discretion. Thanks, Rob |
2021-03-25
|
16 | Robert Wilton | Ballot comment text updated for Robert Wilton |
2021-03-25
|
16 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. Like Eric V, I was slightly surprised to see this defined to use DTLS 1.2 when DTLS 1.3 … [Ballot comment] Hi, Thanks for this document. Like Eric V, I was slightly surprised to see this defined to use DTLS 1.2 when DTLS 1.3 is on the same telechat, which is obsoleting the DTLS 1.2 RFC. But what is not obvious to me is whether the protocol is allowed to use a later version of DTLS, or whether it is strictly tied to DTLS 1.2 and an updated RFC would be required to use a newer version of DTLS. Either way, possibly a few words to clarify this may be beneficial to readers. Thanks, Rob |
2021-03-25
|
16 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-03-24
|
16 | Murray Kucherawy | [Ballot comment] In Section 3.2.2, first paragraph, why is that only a SHOULD? What's a situation in which I might do something else? Same for … [Ballot comment] In Section 3.2.2, first paragraph, why is that only a SHOULD? What's a situation in which I might do something else? Same for the one in the second paragraph of Section 3.4. In the last paragraph of Section 3.3.1, "additionally" doesn't need to appear twice. |
2021-03-24
|
16 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-03-24
|
16 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-03-24
|
16 | Warren Kumari | [Ballot comment] Thanks to Joel for the OpsDir review. I was initially apprehensive about reviewing this document, but found it a really easy and understandable … [Ballot comment] Thanks to Joel for the OpsDir review. I was initially apprehensive about reviewing this document, but found it a really easy and understandable doc; thanks! |
2021-03-24
|
16 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-03-24
|
16 | Lars Eggert | [Ballot comment] Section 3.4, paragraph 4, comment: > The resource server MUST only accept an incoming CoAP request as > authorized if the … [Ballot comment] Section 3.4, paragraph 4, comment: > The resource server MUST only accept an incoming CoAP request as > authorized if the following holds: "MUST only" is odd, suggest to rephrase. (See below.) ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 11.1, paragraph 12, nit: > [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", > RFC 8152, DOI 10.17487/RFC8152, July 2017, > . Unused Reference: 'RFC8152' is defined on line 1144, but no explicit reference was found in the text Section 11.1, paragraph 16, nit: > [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, > "Transport Layer Security (TLS) Session Resumption without > Server-Side State", RFC 5077, DOI 10.17487/RFC5077, > January 2008, . Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Section 11.1, paragraph 22, nit: > [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, > "Object Security for Constrained RESTful Environments > (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, > . Unused Reference: 'RFC8613' is defined on line 1208, but no explicit reference was found in the text Section 3.2.2, paragraph 3, nit: - To be consistent with [RFC7252] which allows for shortened MAC tags + To be consistent with [RFC7252], which allows for shortened MAC tags + + Section 3.3.2, paragraph 3, nit: - be consistent with the recommendations in [RFC7252] a client is + be consistent with the recommendations in [RFC7252], a client is + + Section 3.4, paragraph 4, nit: - The resource server MUST only accept an incoming CoAP request as - ^^^^ - authorized if the following holds: - ^^ -- + The resource server MUST NOT accept an incoming CoAP request as + ^^^ + authorized if any of the following fail: + +++++++ ^^^ Section 7.1, paragraph 3, nit: - [RFC7925] requires clients to decline any renogiation attempt. A - ^ + [RFC7925] requires clients to decline any renegotiation attempt. A + ++ ^ |
2021-03-24
|
16 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-03-24
|
16 | Francesca Palombini | [Ballot comment] Thank you for this document. Some minor comments below. Francesca 1. ----- The response MAY contain a "profile" parameter with the value … [Ballot comment] Thank you for this document. Some minor comments below. Francesca 1. ----- The response MAY contain a "profile" parameter with the value authorizes the client, it returns an AS-to-Client response. If the profile parameter is present, it is set to "coap_dtls". The profile : coap_dtls, FP: s/profile/ace_profile 2. ----- [RFC8747]. A resource server MUST have the capacity to store one access token for every proof-of-possession key of every authorized client. FP: I am not sure this BCP 14 MUST is correct here. 3. ------ raw public keys, it needs to determine which key to use. The authorization server can help with this decision by including a "cnf" parameter in the access token that is associated with this communication. In this case, the resource server MUST use the FP: The example in Figure 4 show how the whole RPK of the client can be included in the access_token, so maybe this paragraph should cover that case, or the example changed. 4. ----- token carries a symmetric key, the access token MUST be encrypted using a "COSE_Encrypt0" structure. The authorization server MUST use FP: Since only CWT is allowed in this profile, it might be good to reference section 7.1 of RFC 8392. 5. ----- the "psk_identity" field. If key derivation is used, the resource server uses the "COSE_KDF_Context" information as described above. FP: "COSE_KDF_Context" appears here for the first time, so this might need to be rephrased. 6. ----- As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this specification uses CBOR web tokens to convey claims within an access token issued by the server. While other formats could be used as FP: I think this warrants for RFC 8392 to be moved to normative reference (but can be convinced of the contrary). |
2021-03-24
|
16 | Francesca Palombini | [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini |
2021-03-23
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-03-23
|
16 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Is there any reason to use DTLS 1.2 while the document DTLS 1.3 is on the same IESG telechat ? I understand that they are from different WG but this may not be the most efficient to specify a protocol using DTLS. -- Section 3.1 -- Has the "resource owner (RO)" been defined earlier ? -- Section 3.2.2 -- The wrong selection of RPK recovery is unclear to me. What happens if the client does not have the right public key ? == NITS == Sometimes it is "Raw Public Keys", or "RPK" or "RawPublicKey"... Is it on purpose to use 3 different writings for possibly the same concept? |
2021-03-23
|
16 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-03-23
|
16 | Russ Mundy | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Russ Mundy. Sent review to list. |
2021-03-22
|
16 | Roman Danyliw | [Ballot comment] Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. ** Does this profile … [Ballot comment] Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. ** Does this profile only cover part of the oauth-authz framework? Section 3.3 explicitly says “the use of introspection is out of scope for this specification.” It might be helpful to note in the introduction that this profile only covers C-to-AS and C-to-RS communication. ** Section 3.2.1 Figure 3, uses the “req_aud” parameter, but this was renamed to “audience” in -20 of draft-ietf-ace-oauth-authz ** Section 3.2.1. Per ‘The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server’, this is true (see the DISCUSS above though). However, it might be worthwhile to point out that per Section 5.8.2 of draft-ietf-ace-oauth-authz-38, this “MAY” is actually a MUST if the request has an empty “ace_profile” parameter. ** Section 3.2.2. Per “This specification therefore mandates implementation support for curve25519 ...”, perhaps RFC2119 language should be used here ** Section 3.3.1. Per all of the text after “The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application-specific; the remainder of this section provides one example”, consider removing all of the RFC2119 language is this text as its an example. ** Section 3.3.2. Per “When the resource server receives an access token, it MUST check if the access token is still valid ...”, a reference to Section 5.10.1.1 of [I-D.ietf-ace-oauth-authz] for additional verification procedures might be helpful ** Section 3.2.2. and 7: (a) Section 3.2.2. To be consistent with [RFC7252] which allows for shortened MAC tags in constrained environments, an implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. (b) As this specification aims at constrained devices and uses CoAP [RFC7252] as transfer protocol, at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported The text in (b) is weaker on the mandatory required of the ciphersuite. In (b), likely s/should be supported/must be supported/. ** Section 7. Per “For longer-lived access tokens, DHE ciphersuites should be used”, perhaps add a parenthetical at the end of this sentence of “(i.e., ciphersuites of the form TLS_DHE_PSK_*)”. ** Section 7.1. Session resumption is noted to be NOT RECOMMENDED. Is there a reason this can’t be stronger (MUST NOT)? ** Section 7.2. No issues with the guidance here. Is there anything DTLS specific that suggests that developers "SHOULD" avoid multiple access tokens per client? That guidance isn’t in the core framework. I made the comment on the core framework that perhaps this text should be there (too?). ** Please reviews all of the reference numbers to [I-D.ietf-ace-oauth-authz] as a number of them seem to be incorrect (likely due to renumbering). For example: -- Section 2. Per “the client MUST upload the access token to the authz-info resource, i.e. the authz-info endpoint, on the resource server before starting the DTLS handshake, as described in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]”, Section 5.8.1 is not the right reference. It’s likely 5.10.1. -- Section 3.4. Per “The authorization server may, e.g., specify a "cti" claim for the access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz]) to employ a strict order”, Section 5.8.3 is the wrong section in [I-D.ietf-ace-oauth-authz]. -- Section 3.4. Per “The response SHOULD include AS Request Creation Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz].”, there is no Section 5.1.1. The appropriate section is either 5.2 to reference this behavior or 5.3 for the details of the hints. -- Section 3.4. Per “Incoming CoAP requests received on a secure DTLS channel that are not thus authorized MUST be rejected according to Section 5.8.2 of [I-D.ietf-ace-oauth-authz]”, Section 5.8.2 is not the right reference here. ** idnits returned the following: == Unused Reference: 'RFC8152' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC8613' is defined on line 1212, but no explicit reference was found in the text ** Nits -- Section 7.1. Typo. s/renogiation/renegotiation/ |
2021-03-22
|
16 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2021-03-22
|
16 | Roman Danyliw | [Ballot discuss] (A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], the name of the parameter in the C-to-AS communication is “ace_profile” (not … [Ballot discuss] (A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], the name of the parameter in the C-to-AS communication is “ace_profile” (not “profile”). The “ace_profile” parameter is mistakenly referenced as “profile” in the following places: -- Section 3.2.1: The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server. -- Section 3.3.1: If the profile parameter is present, it is set to "coap_dtls". |
2021-03-22
|
16 | Roman Danyliw | [Ballot comment] Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. ** What is the … [Ballot comment] Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. ** What is the motivation for specifying this profile around DTLS 1.2 instead of 1.3?? ** Does this profile only cover part of the oauth-authz framework? Section 3.3 explicitly says “the use of introspection is out of scope for this specification.” It might be helpful to note in the introduction that this profile only covers C-to-AS and C-to-RS communication. ** Section 3.2.1 Figure 3, uses the “req_aud” parameter, but this was renamed to “audience” in -20 of draft-ietf-ace-oauth-authz ** Section 3.2.1. Per ‘The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server’, this is true (see the DISCUSS above though). However, it might be worthwhile to point out that per Section 5.8.2 of draft-ietf-ace-oauth-authz-38, this “MAY” is actually a MUST if the request has an empty “ace_profile” parameter. ** Section 3.2.2. Per “This specification therefore mandates implementation support for curve25519 ...”, perhaps RFC2119 language should be used here ** Section 3.3.1. Per all of the text after “The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application-specific; the remainder of this section provides one example”, consider removing all of the RFC2119 language is this text as its an example. ** Section 3.3.2. Per “When the resource server receives an access token, it MUST check if the access token is still valid ...”, a reference to Section 5.10.1.1 of [I-D.ietf-ace-oauth-authz] for additional verification procedures might be helpful ** Section 3.2.2. and 7: (a) Section 3.2.2. To be consistent with [RFC7252] which allows for shortened MAC tags in constrained environments, an implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. (b) As this specification aims at constrained devices and uses CoAP [RFC7252] as transfer protocol, at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported The text in (b) is weaker on the mandatory required of the ciphersuite. In (b), likely s/should be supported/must be supported/. ** Section 7. Per “For longer-lived access tokens, DHE ciphersuites should be used”, perhaps add a parenthetical at the end of this sentence of “(i.e., ciphersuites of the form TLS_DHE_PSK_*)”. ** Section 7.1. Session resumption is noted to be NOT RECOMMENDED. Is there a reason this can’t be stronger (MUST NOT)? ** Section 7.2. No issues with the guidance here. Is there anything DTLS specific that suggests that developers "SHOULD" avoid multiple access tokens per client? That guidance isn’t in the core framework. I made the comment on the core framework that perhaps this text should be there (too?). ** Please reviews all of the reference numbers to [I-D.ietf-ace-oauth-authz] as a number of them seem to be incorrect (likely due to renumbering). For example: -- Section 2. Per “the client MUST upload the access token to the authz-info resource, i.e. the authz-info endpoint, on the resource server before starting the DTLS handshake, as described in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]”, Section 5.8.1 is not the right reference. It’s likely 5.10.1. -- Section 3.4. Per “The authorization server may, e.g., specify a "cti" claim for the access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz]) to employ a strict order”, Section 5.8.3 is the wrong section in [I-D.ietf-ace-oauth-authz]. -- Section 3.4. Per “The response SHOULD include AS Request Creation Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz].”, there is no Section 5.1.1. The appropriate section is either 5.2 to reference this behavior or 5.3 for the details of the hints. -- Section 3.4. Per “Incoming CoAP requests received on a secure DTLS channel that are not thus authorized MUST be rejected according to Section 5.8.2 of [I-D.ietf-ace-oauth-authz]”, Section 5.8.2 is not the right reference here. ** idnits returned the following: == Unused Reference: 'RFC8152' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'RFC8613' is defined on line 1212, but no explicit reference was found in the text ** Nits -- Section 7.1. Typo. s/renogiation/renegotiation/ |
2021-03-22
|
16 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2021-03-22
|
16 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-03-22
|
16 | Amy Vezza | Notification list changed to none from Jim Schaad <ietf@augustcellars.com> |
2021-03-22
|
16 | Amy Vezza | Document shepherd changed to (None) |
2021-03-19
|
16 | Paul Kyzivat | Request for Telechat review by GENART Completed: Ready. Reviewer: Paul Kyzivat. |
2021-03-16
|
16 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-03-12
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2021-03-12
|
16 | Jean Mahoney | Request for Telechat review by GENART is assigned to Paul Kyzivat |
2021-03-11
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Mundy |
2021-03-11
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Mundy |
2021-03-08
|
16 | Amy Vezza | Placed on agenda for telechat - 2021-03-25 |
2021-03-08
|
16 | Benjamin Kaduk | Ballot has been issued |
2021-03-08
|
16 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2021-03-08
|
16 | Benjamin Kaduk | Created "Approve" ballot |
2021-03-08
|
16 | (System) | Changed action holders to Benjamin Kaduk (IESG state changed) |
2021-03-08
|
16 | Benjamin Kaduk | IESG state changed to IESG Evaluation from Waiting for Writeup::External Party |
2021-03-08
|
16 | Benjamin Kaduk | Ballot writeup was changed |
2021-03-08
|
16 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-16.txt |
2021-03-08
|
16 | (System) | New version approved |
2021-03-08
|
16 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Goeran Selander , Ludwig Seitz , Olaf Bergmann , Stefanie Gerdes |
2021-03-08
|
16 | Olaf Bergmann | Uploaded new revision |
2021-01-24
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Russ Mundy. Submission of review completed at an earlier date. |
2021-01-20
|
15 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-15.txt |
2021-01-20
|
15 | (System) | New version approved |
2021-01-20
|
15 | (System) | Request for posting confirmation emailed to previous authors: Carsten Bormann , Goeran Selander , Ludwig Seitz , Olaf Bergmann , Stefanie Gerdes |
2021-01-20
|
15 | Olaf Bergmann | Uploaded new revision |
2021-01-18
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Russ Mundy. |
2020-10-29
|
14 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-14.txt |
2020-10-29
|
14 | (System) | New version approved |
2020-10-29
|
14 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Goeran Selander , Stefanie Gerdes , Olaf Bergmann , Carsten Bormann |
2020-10-29
|
14 | Olaf Bergmann | Uploaded new revision |
2020-10-26
|
13 | Benjamin Kaduk | Putting in ::External Party while I check on the OSCORE profile and think about whether we want to wait for it and move the whole … Putting in ::External Party while I check on the OSCORE profile and think about whether we want to wait for it and move the whole cluster into IESG evaluation together. |
2020-10-26
|
13 | Benjamin Kaduk | IESG state changed to Waiting for Writeup::External Party from Waiting for Writeup::AD Followup |
2020-09-08
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-08
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-09-08
|
13 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-13.txt |
2020-09-08
|
13 | (System) | New version approved |
2020-09-08
|
13 | (System) | Request for posting confirmation emailed to previous authors: Goeran Selander , Stefanie Gerdes , Carsten Bormann , Ludwig Seitz , Olaf Bergmann |
2020-09-08
|
13 | Olaf Bergmann | Uploaded new revision |
2020-07-28
|
12 | Joel Jaeggli | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joel Jaeggli. Sent review to list. |
2020-07-27
|
12 | Benjamin Kaduk | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2020-07-20
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-07-19
|
12 | Paul Kyzivat | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat. |
2020-07-17
|
12 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-07-17
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ace-dtls-authorize-12. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ace-dtls-authorize-12. If any part of this review is inaccurate, please let us know. IANA understands that the action requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: draft-ietf-ace-oauth-authz-35. Section 8.8 of that document creates a new registry with the following fields: Name The name of the profile, to be used as value of the profile attribute. Description Text giving an overview of the profile and the context it is developed for. CBOR Value CBOR abbreviation for this profile name. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as Private Use. Reference This contains a pointer to the public specification of the profile abbreviation, if one exists. The current document requests the following registration: Profile name: coap_dtls Profile Description: Profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. Profile ID: TBD (suggested: 1) Change Controller: IESG Reference: [ RFC-to-be ] Upon approval of draft-ietf-ace-oauth-authz IANA understands that a single, new registration will be made in the ACE Profile registry as follows: Name: coap_dtls Description: Profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. CBOR Value: [ TBD-at-Registration ] Reference: [ RFC-to-be ] IANA understands that the authors have suggested a value of 1 for the CBOR Value. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-07-16
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2020-07-16
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2020-07-10
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2020-07-10
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Mundy |
2020-07-09
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2020-07-09
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Paul Kyzivat |
2020-07-06
|
12 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-07-06
|
12 | Amy Vezza | last-call@ietf.org Sender: Subject: Last Call: (Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)) to Proposed Standard The IESG has … last-call@ietf.org Sender: Subject: Last Call: (Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)) to Proposed Standard The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3112/ |
2020-07-06
|
12 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-07-06
|
12 | Amy Vezza | Last call announcement was generated |
2020-07-06
|
12 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-12.txt |
2020-07-06
|
12 | (System) | New version approved |
2020-07-06
|
12 | (System) | Request for posting confirmation emailed to previous authors: Goeran Selander , Carsten Bormann , Stefanie Gerdes , Olaf Bergmann , Ludwig Seitz |
2020-07-06
|
12 | Olaf Bergmann | Uploaded new revision |
2020-07-04
|
11 | Benjamin Kaduk | Last call was requested |
2020-07-04
|
11 | Benjamin Kaduk | Last call announcement was generated |
2020-07-04
|
11 | Benjamin Kaduk | Ballot approval text was generated |
2020-07-04
|
11 | Benjamin Kaduk | Ballot writeup was generated |
2020-07-04
|
11 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation::External Party |
2020-06-29
|
11 | Benjamin Kaduk | May want to hold this for a little bit so that the IETF LC for the two profiles go out together. |
2020-06-29
|
11 | Benjamin Kaduk | IESG state changed to AD Evaluation::External Party from AD Evaluation::AD Followup |
2020-06-18
|
11 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-11.txt |
2020-06-18
|
11 | (System) | New version approved |
2020-06-18
|
11 | (System) | Request for posting confirmation emailed to previous authors: Stefanie Gerdes , Carsten Bormann , Olaf Bergmann , Goeran Selander , Ludwig Seitz |
2020-06-18
|
11 | Olaf Bergmann | Uploaded new revision |
2020-05-13
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-05-13
|
10 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-10.txt |
2020-05-13
|
10 | (System) | New version approved |
2020-05-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Stefanie Gerdes , Goeran Selander , Carsten Bormann , Olaf Bergmann , Ludwig Seitz |
2020-05-13
|
10 | Olaf Bergmann | Uploaded new revision |
2020-01-02
|
09 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-01-01
|
09 | Jim Schaad | (1) This document is labeled to be a Proposed Standard. This is what the the track of the document should be. (2) The IESG approval … (1) This document is labeled to be a Proposed Standard. This is what the the track of the document should be. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The ACE WG has created a framework for constrained servers to do authentication and authorization using OAuth. This document provides the details for how to use DTLS as the security for protecting and authentication the messages defined in the framework as well as the final client to resource server messages. Working Group Summary The document did not raise any issues during development. Most of the issues were focused on the framework document. Document Quality At least two implementations of prior versions of this document exist. The process of doing these implementations and making sure that they were interoperable was influential in some of the content in the document. Personnel Jim Schaad is the Document Shepherd. Benjamin Kaduk is the Responsible Area Director. (3) In addition to validating my implementation of the specification I checked the IANA considerations to make sure that they were complete, checked all of the nits and did a read through to make sure all WGLC comments were addressed. (4) All of my concerns have been addressed during the WGLC process. (5) Looking at the mechanism that is defined for resource server key generation should be checked against the security considerations and any problems. (6) I have no specific concerns with this document. (7) All authors have confirmed that all appropriate IPR disclosures have been made ** Stefanie ** YES * 5/2/19 ** Olaf ** YES * 4/30/19 ** Carsten ** YES * 4/29/19 ** Goeran ** YES * 5/7/19 ** Ludwig ** YES * 4/29/19 (8) An IPR disclosure has been filed on this by Ericsson. This was initially disclosed in a F2F meeting. No WG discussion has occurred on this disclosure. (9) Most of the input and discussions on this draft has come from the authors and the shepherd rather than the WG as a whole. (10) There has been no serious dissension on this draft. (11) No known ID nits exist. (12) No formal review is required. (13) All references are appropriately identified (14) All normative references are either in the same state as this document or already finished. (15) There are no downward normative references. (16) This document indirectly updates draft-ace-oauth-authz as it describes and defines a profile for use with that document. (17) Read the document looking for any and all new things defined by the text of he document checking against the text of the IANA considerations section. Only the one item to be registered needs to be done. The majority of all registrations are in the ACE OAuth Framework document. (18) No new registries are created. (19) There are no sections of the document that need automated validation. |
2019-12-31
|
09 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
2019-12-18
|
09 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-09.txt |
2019-12-18
|
09 | (System) | New version approved |
2019-12-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: ace-chairs@ietf.org, Ludwig Seitz , Carsten Bormann , Goeran Selander , Olaf Bergmann , Stefanie Gerdes |
2019-12-18
|
09 | Olaf Bergmann | Uploaded new revision |
2019-05-07
|
08 | Jim Schaad | (1) This document is labeled to be a Proposed Standard. This is what the the track of the document should be. (2) The IESG approval … (1) This document is labeled to be a Proposed Standard. This is what the the track of the document should be. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The ACE WG has crated a framework for constrained servers to do authentication and authroization using OAuth. This document provides the details for how to use DTLS as the security for protecting and authentication the messages defined in the framework as well as the final client to resource server messages. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality At least two implementations of prior versions of this document exist. The process of doing these implementations and making sure that they were interpretable was influential in some of the content in the document. Personnel Jim Schaad is the Document Shepherd. Benjamin Kaduk is the Responsible Area Director. (3) In addition to validating my implementation of the specification I checked the IANA considerations to make sure that they were complete, checked all of the nits and did a read through to make sure all WGLC comments were addressed. (4) All of my concerns have been addressed during the WGLC process. (5) Looking at the mechanism that is defined for resource server key generation should be checked against the security considerations and any problems. (6) I have no specific concerns with this document. (7) All authors have confirmed that all appropriate IPR discloures have been made ** Stefanie ** YES * 5/2/19 ** Olaf ** YES * 4/30/19 ** Carsten ** YES * 4/29/19 ** Goeran ** YES * 5/7/19 ** Ludwig ** YES * 4/29/19 (8) An IPR disclosure has been filed on this by Ericsson. This was initially disclosed in a F2F meeting. No WG discussion has occurred on this disclosure. (9) Most of the input and discussions on this draft has come from the authors and the shepherd rather than the WG as a whole. (10) There has been no serious dissension on this draft. (11) No known ID nits exist. (12) No formal review is required. (13) All references are appropriately identified (14) All normative references are either in the same state as this document or already finished. (15) There are no downward normative references. (16) This document indirectly updates draft-ace-oauth-authz as it describes and defines a profile for use with that document. (17) Read the document looking for any and all new things defined by the text of he document checking against the text of the IANA considerations section. Only the one item to be registered needs to be done. The majority of all registrations are in the ACE OAuth Framework document. (18) No new registries are created. (19) There are no sections of the document that need automated validation. |
2019-05-07
|
08 | Jim Schaad | Responsible AD changed to Benjamin Kaduk |
2019-05-07
|
08 | Jim Schaad | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2019-05-07
|
08 | Jim Schaad | IESG state changed to Publication Requested from I-D Exists |
2019-05-07
|
08 | Jim Schaad | IESG process started in state Publication Requested |
2019-05-07
|
08 | Jim Schaad | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2019-05-07
|
08 | Jim Schaad | Changed consensus to Yes from Unknown |
2019-05-07
|
08 | Jim Schaad | Intended Status changed to Proposed Standard from None |
2019-05-07
|
08 | Jim Schaad | (1) This document is labeled to be a Proposed Standard. This is what the the track of the document should be. (2) The IESG approval … (1) This document is labeled to be a Proposed Standard. This is what the the track of the document should be. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The ACE WG has crated a framework for constrained servers to do authentication and authroization using OAuth. This document provides the details for how to use DTLS as the security for protecting and authentication the messages defined in the framework as well as the final client to resource server messages. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality At least two implementations of prior versions of this document exist. The process of doing these implementations and making sure that they were interpretable was influential in some of the content in the document. Personnel Jim Schaad is the Document Shepherd. Benjamin Kaduk is the Responsible Area Director. (3) In addition to validating my implementation of the specification I checked the IANA considerations to make sure that they were complete, checked all of the nits and did a read through to make sure all WGLC comments were addressed. (4) All of my concerns have been addressed during the WGLC process. (5) Looking at the mechanism that is defined for resource server key generation should be checked against the security considerations and any problems. (6) I have no specific concerns with this document. (7) All authors have confirmed that all appropriate IPR discloures have been made ** Stefanie ** YES * 5/2/19 ** Olaf ** YES * 4/30/19 ** Carsten ** YES * 4/29/19 ** Goeran ** YES * 5/7/19 ** Ludwig ** YES * 4/29/19 (8) An IPR disclosure has been filed on this by Ericsson. This was initially disclosed in a F2F meeting. No WG discussion has occurred on this disclosure. (9) Most of the input and discussions on this draft has come from the authors and the shepherd rather than the WG as a whole. (10) There has been no serious dissension on this draft. (11) No known ID nits exist. (12) No formal review is required. (13) All references are appropriately identified (14) All normative references are either in the same state as this document or already finished. (15) There are no downward normative references. (16) This document indirectly updates draft-ace-oauth-authz as it describes and defines a profile for use with that document. (17) Read the document looking for any and all new things defined by the text of he document checking against the text of the IANA considerations section. Only the one item to be registered needs to be done. The majority of all registrations are in the ACE OAuth Framework document. (18) No new registries are created. (19) There are no sections of the document that need automated validation. |
2019-04-12
|
08 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-08.txt |
2019-04-12
|
08 | (System) | New version approved |
2019-04-12
|
08 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2019-04-12
|
08 | Olaf Bergmann | Uploaded new revision |
2019-03-11
|
07 | Göran Selander | New version available: draft-ietf-ace-dtls-authorize-07.txt |
2019-03-11
|
07 | (System) | New version approved |
2019-03-11
|
07 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2019-03-11
|
07 | Göran Selander | Uploaded new revision |
2019-02-28
|
06 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-06.txt |
2019-02-28
|
06 | (System) | New version approved |
2019-02-28
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2019-02-28
|
06 | Olaf Bergmann | Uploaded new revision |
2019-01-28
|
05 | Jim Schaad | Notification list changed to Jim Schaad <ietf@augustcellars.com> |
2019-01-28
|
05 | Jim Schaad | Document shepherd changed to Jim Schaad |
2018-11-04
|
05 | Jim Schaad | Tag Revised I-D Needed - Issue raised by WGLC set. |
2018-10-22
|
05 | Jim Schaad | Added to session: IETF-103: ace Thu-1610 |
2018-10-08
|
05 | Jim Schaad | IETF WG state changed to In WG Last Call from WG Document |
2018-10-08
|
05 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-05.txt |
2018-10-08
|
05 | (System) | New version approved |
2018-10-08
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2018-10-08
|
05 | Olaf Bergmann | Uploaded new revision |
2018-09-06
|
04 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-04.txt |
2018-09-06
|
04 | (System) | New version approved |
2018-09-06
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2018-09-06
|
04 | Olaf Bergmann | Uploaded new revision |
2018-09-06
|
03 | (System) | Document has expired |
2018-07-14
|
03 | Roman Danyliw | Added to session: IETF-102: ace Mon-0930 |
2018-03-13
|
03 | Jim Schaad | Added to session: IETF-101: ace Mon-0930 |
2018-03-05
|
03 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-03.txt |
2018-03-05
|
03 | (System) | New version approved |
2018-03-05
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2018-03-05
|
03 | Olaf Bergmann | Uploaded new revision |
2017-11-20
|
Jasmine Magallanes | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ace-dtls-authorize | |
2017-11-08
|
02 | Jim Schaad | Added to session: IETF-100: ace Tue-0930 |
2017-10-30
|
02 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-02.txt |
2017-10-30
|
02 | (System) | New version approved |
2017-10-30
|
02 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2017-10-30
|
02 | Olaf Bergmann | Uploaded new revision |
2017-07-16
|
01 | Kepeng Li | Added to session: IETF-99: ace Mon-0930 |
2017-07-03
|
01 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-01.txt |
2017-07-03
|
01 | (System) | New version approved |
2017-07-03
|
01 | (System) | Request for posting confirmation emailed to previous authors: Ludwig Seitz , Carsten Bormann , Olaf Bergmann , Stefanie Gerdes , Goeran Selander |
2017-07-03
|
01 | Olaf Bergmann | Uploaded new revision |
2017-06-08
|
00 | Kepeng Li | This document now replaces draft-gerdes-ace-dtls-authorize instead of None |
2017-06-08
|
00 | Olaf Bergmann | New version available: draft-ietf-ace-dtls-authorize-00.txt |
2017-06-08
|
00 | (System) | WG -00 approved |
2017-06-08
|
00 | Olaf Bergmann | Set submitter to "Olaf Bergmann ", replaces to draft-gerdes-ace-dtls-authorize and sent approval email to group chairs: ace-chairs@ietf.org |
2017-06-08
|
00 | Olaf Bergmann | Uploaded new revision |