Skip to main content

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-08-31
18 (System)
Received changes through RFC Editor sync (created alias RFC 9202, changed abstract to 'This specification defines a profile of the Authentication and Authorization for …
Received changes through RFC Editor sync (created alias RFC 9202, changed abstract to 'This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization.  The protocol relies on DTLS version 1.2 or later 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.', changed pages to 23, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-08-31, changed IESG state to RFC Published)
2022-08-31
18 (System) RFC published
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
The following Last Call announcement was sent out (ends 2020-07-20):

From: The IESG
To: IETF-Announce
CC: Jim Schaad , ace-chairs@ietf.org, kaduk@mit.edu, ietf@augustcellars.com, …
The following Last Call announcement was sent out (ends 2020-07-20):

From: The IESG
To: IETF-Announce
CC: Jim Schaad , ace-chairs@ietf.org, kaduk@mit.edu, ietf@augustcellars.com, ace@ietf.org, draft-ietf-ace-dtls-authorize@ietf.org
Reply-To: 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