Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
draft-ietf-ace-dtls-authorize-18

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)

[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.

[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

[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

[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.

[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!

[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
+                                                ++ ^

[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).

[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?

[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/

[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".

[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/

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.

(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

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/

(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.

(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.

(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.