Skip to main content

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

Yes

(Benjamin Kaduk)

No Objection

Erik Kline
Zaheduzzaman Sarker
(Alvaro Retana)
(Martin Duke)
(Martin Vigoureux)

Note: This ballot was opened for revision 16 and is now closed.

Francesca Palombini
Yes
Comment (2021-03-24 for -16) Sent
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).
Erik Kline
No Objection
Murray Kucherawy
No Objection
Comment (2021-03-24 for -16) Sent
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.
Roman Danyliw
(was Discuss) No Objection
Comment (2021-05-12 for -17) Sent for earlier
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.
Warren Kumari
No Objection
Comment (2021-03-24 for -16) Sent
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!
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2021-03-23 for -16) Sent
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?
Benjamin Kaduk Former IESG member
Yes
Yes (for -16) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (2021-03-24 for -16) Sent
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,
>               <https://www.rfc-editor.org/info/rfc8152>.

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, <https://www.rfc-editor.org/info/rfc5077>.

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,
>               <https://www.rfc-editor.org/info/rfc8613>.

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
+                                                 ++ ^
Martin Duke Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2021-03-25 for -16) Sent
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