[Lake] Review of draft-ietf-lake-authz-01

[Marco Tiloca <[e-mail]>]

Hi all,

Please see below my comments on this document. I hope it helps!

Best,
/Marco


[Abstract]

* The title and Section 1 say that the document is first of all about 
authorization, which, as a particular case considered in the document, 
can be used for device enrollment. Consistently, you can consider the 
following rephrasing in the abstract:

    - s/for authorizing enrollment of new devices/for authorizing new 
devices

    - s/applicable to zero-touch onboarding of new/applicable to 
zero-touch enrollment of new

    (unlike "enrollment", "onboarding" is used only once, in the abstract)


[Section 1.1]

* In the list of expected understanding of the second paragraph, it's 
better to add also CDDL (RFC 8610).


[Section 2]

* Based on the content of this section, the title "Objective" feels more 
appropriate.


[Section 3.1]

* "an X.509 certificate"

    Add a reference to RFC 5280

* "CRED_U may, for example, be carried in ID_CRED_I of EDHOC message_3 
or be provisioned to V over a non-constrained network, see bottom of 
Figure 3."

    I guess you mean:

    "CRED_U may, for example, be carried by value in ID_CRED_I of EDHOC 
message_3 or be provisioned to V over a non-constrained network, 
leveraging a credential identifier in ID_CRED_I (see bottom of Figure 3)."


[Section 3.2]

* "To authenticate to U, the domain authenticator (V) runs EDHOC in the 
role of Responder with an authentication credential CRED_V, which is a 
CWT Claims Set [RFC8392] containing a public key of V, see Section 4.5.2.1."

    Why does CRED_V have to be exactly a CWT Claims Set? (the same is 
consistently said later on in Section 4.4.2 and in Section 4.5.2.1)

    This would also prevent V and W to use TLS with CRED_V and Client 
Authentication, which, as mentioned in Section 3.2, would require to use 
an X.509 certificate as CRED_V.

* "W needs access the same credential CRED_V as V used with U"

    Minor rephrasing: "W needs to access the same credential CRED_V that 
V uses with U"

* "However, note that CRED_V may not be a valid credential to use with 
TLS 1.3, e.g., when U and V run EDHOC with method 1 or 3, where the 
public key of CRED_V is a static Diffie-Hellman key."

    Considering the authentication credential types that are possible to 
use in EDHOC, isn't this generally an issue if CRED_V is not an X.509 
certificate? (or a C509 certificate, pending the registration in Section 
9.18 of draft-ietf-cose-cbor-encoded-cert-09)

* "V may run EDHOC with W using"

    This can be: "V may run EDHOC in the role of initiator with W, using"


[Section 3.3]

* "W MUST verify that CRED_V is bound to the secure connection between W 
and V"

    How does this happen in case the secure connection establishment 
does not use client authentication, or in case the authentication 
credential that V uses for that is not associated with the same public 
key of CRED_V that V uses with U in EDHOC?


[Section 4.1]

* "An outline of EDHOC is given in Section 3 of [I-D.ietf-lake-edhoc]."

    This has become Section 2.

* In Figure 3, in the top part of the diagram between V and W

       s/w.r.t. CRED/w.r.t. CRED_V


[Section 4.2]

* s/EDHOC-Extract/EDHOC_Extract

* s/EDHOC-Expand/EDHOC_Expand

* "The output keying material OKM is derived from PRK using 
EDHOC-Expand(), which is defined in terms of the EDHOC hash algorithm of 
the selected cipher suite, see Section 4.2 of [I-D.ietf-lake-edhoc]:"

    The reference should be to Section 4.1.2.


[Section 4.3]

* "This state typically contains U's IP address and port number, together"

    I think this can be more general, and consider IP only as an 
example. Then it can become:

    "This state typically contains addressing information of U (e.g., 
U's IP address and port number), together"

* "For example, V may use the existing CBOR and COSE libraries."

    Why not simply "For example, V may use CBOR and COSE." ?

* "in the form of a Voucher Request."

    Please include a forward reference to Section 4.6.2.


[Section 4.4.1]

* It kind of follows from Section 4.2, but it's better to state 
explicitly that the encryption is done by using the EDHOC AEAD algorithm.

* s/EDHOC-Expand/EDHOC_Expand  (2 instances)

* s/length of key of the/length of the key for the

* s/length of nonce of the/length of the nonce for the

* The plaintext is defined as

    > plaintext = (
    >     ID_U:            bstr,
    >     ?OPAQUE_INFO:    bstr,
    > )

    Thinking of the later definition in Appendix B.2, the value of the 
CBOR byte string OPAQUE_INFO is the byte serialization of u_hint, right?


[Section 4.4.2]

* "H(message_1) is the hash of EDHOC message_1, calculated from the 
associated voucher request, see Section 4.6.1."

    It's better to clarify here that the hash is computed by using the 
EDHOC hash algorithm of the selected cipher suite specified in SUITE_I 
of EDHOC message_1.

    The same clarification is useful also when referring to the EDHOC 
AEAD Algorithm in Sections 4.4.1 and 4.4.2.

* "CRED_V is the CWT Claims Set"

    If this is such a hard requirement (see above, does it have to be?), 
then it might not be possible to use TLS with Client authentication 
between V and W, as mentioned in Section 3.2.

* s/EDHOC-Expand/EDHOC_Expand  (2 instances)


[Section 4.5.1.1]

* "with respect to the Diffie Hellman key agreement algorithm used"

    Per the EDHOC terminology, this should be "EDHOC key exchange algorithm"


[Section 4.5.2.1]

* "CRED_V is a CWT Claims Set [RFC8392] containing the public 
authentication key of V encoded as a COSE_Key in the 'cnf' claim, see 
Section 3.5.2 of [I-D.ietf-lake-edhoc]."

    See also other comments above. Why does CRED_V have to be exactly a 
CWT Claims Set?

* "COSE header_map, see Section 9.6"

    This has become Section 10.6.


[Section 4.5.2.2]

* "U receives EDHOC message_2 from V and processes it as specified in 
Section 5.3.2 of [I-D.ietf-lake-edhoc]"

    That should be Section 5.3.3


[Section 4.5.3.1]

* s/OSCORE request/OSCORE-protected application request


[Section 4.6]

* "It is assumed that V and W have set up a secure connection"

    When? I suppose that's actually required when V is about to send the 
Voucher Request to W, but not necessarily before then.

* "W has accessed the authentication credential CRED_V to be used in the 
EDHOC session between V and with U"

    If the secure connection establishment between V and W happened 
without Client authentication or by using a V's authentication 
credential different than CRED_V, then V can still include CRED_V within 
'opaque_state' (together with a proof-of-possession of the private key 
corresponding to CRED_V, if W hasn't already achieved that 
proof-of-possession).


[Section 4.6.1.1]

* "message_1 is the EDHOC message_1 as it was received from U."

    I think this should be "message_1 is a CBOR byte string with value 
the byte serialization of EDHOC message_1 as it was received from U."


[Section 4.6.1.2]

* s/the encryption of the device identifier/the result of the encryption of

* "If H(message_1) is not unique among session identifiers associated to 
this device identifier of U, the EDHOC session SHALL be aborted."

    Which EDHOC session? If the intention is to abort the ongoing EDHOC 
session between U and V, then W can still simply reply with an 
error/negative response to V, which would in turn abort the EDHOC 
session with U.

* "W uses ID_U to look up the associated authorization policies for U 
and enforces them."

    Enforcing them means understanding whether to issue the Voucher or 
not, right?

* "If H(message_1) is not unique among session identifiers associated 
with this device identifier of U, the EDHOC session SHALL be aborted."

    The EDHOC session in question should be that between U and V, but 
this text describes processing at W. Do you mean that a "Voucher Error" 
must be returned to V, which in turn aborts the EDHOC session with U?


[Section 4.6.2.1]

* "message_1 is the EDHOC message_1 as it was received from V."

    I think this should be "message_1 is a CBOR byte string with value 
the byte serialization of EDHOC message_1 as it was received from V."


[Section 4.6.2.2]

* "If that verification fails then EDHOC is aborted."

    This should be: "If that verification fails, then the EDHOC session 
with U is aborted."


[Section 4.7.2]

* "The encryption of REJECT_INFO follows a procedure analogous to the 
one defined in Section 4.4.2, with the following differences"

    I think that one detail is missing, i.e., REJECT_INFO is the 
'ciphertext' field of a COSE_Encrypt0 object.

    This can be mentioned in the bullet list after the CDDL definitions 
(i.e., as another difference from Section 4.4.2, the goal here is to 
produce 'REJECT_INFO' instead of 'Voucher').

* The plaintext is defined as

    > plaintext = (
    >     OPAQUE_INFO:     bstr,
    > )

    Thinking of the later definition in Appendix B.1, the value of the 
CBOR byte string OPAQUE_INFO is the byte serialization of v_hint, right?


[Section 5]

* You may want to add a new subsection "Schemes "coaps+tcp" and 
"coaps+ws"". It should be like for Section 5.1 "Scheme "https", with the 
difference that HTTP is replaced by CoAP.

* The title and first sentence of Section 5.3 "Scheme "coap"" can be 
extended to mention also the schemes "coap+tcp" and "coap+ws".

    The reference to Appendix A of draft-ietf-lake-edhoc remains 
relevant only when the "coap" scheme is used.


[Section 5.1]

- "In case the scheme indicates "https", V MUST perform a TLS handshake 
with W and use HTTP."

    Consistent with the text in Sections 5.2 and 5.3, this should say:

    "In case the scheme indicates "https", V MUST perform a TLS 
handshake with W and access the resources defined in Section 5.4 using 
HTTP."


[Section 5.1]

* "If the authentication credential CRED_V cannot be used in a TLS 
handshake, e.g. if the public key is a static Diffie-Hellman key, then V 
SHOULD first perform a TLS handshake with W using available compatible 
keys. V MUST then perform an EDHOC session over the TLS connection 
proving to W the possession of the private key corresponding to CRED_V. 
Performing the EDHOC session is only necessary if V did not authenticate 
with CRED_V in the TLS handshake with W."

    This answers to the previous comments on this topic. Maybe it's good 
to have this explanation earlier in the document and/or to forward-point 
to this section.

    Clearly, this option requires W to support EDHOC, which would 
otherwise not be necessary on that side.

    An alternative option is for V to provide W with its own 
authentication credential CRED_V over their secure connection, together 
with a proof-of-possession of the corresponding private key if W hasn't 
achieved it before. This information can be part of the Voucher Request.


[Section 5.2]

* Considering that, at the very least, V has to authenticate W through 
DTLS, this excludes the possibility of having a CoAP proxy between V and 
W, right?


[Section 5.4.1]

* "W MUST issue a 200 OK response"

    That's in case HTTP is used. If CoAP is used, that's a 2.04 
(Changed) response.

* Does the successful response have unspecified Content-Format 
(Content-Type)?


[Section 5.4.2]

* "W MUST issue 200 OK response"

    That's in case HTTP is used. If CoAP is used, that's a 2.04 
(Changed) response.

* Do the request and the successful response have unspecified 
Content-Format (Content-Type)?


[Section 6]

* "As noted in Section 8.2 of [I-D.ietf-lake-edhoc] an ephemeral key ..."

    This is now Section 9.2.

* "device with input of public key of W (G_W) and device identifier of U 
(ID_U), and produce"

    Proposed rephrasing: "device, so that EDHOC can import the public 
key of W (G_W) and the device identifier of U (ID_U), and then produce"


[Section 7.4.1]

* s/Encoding considerations: binary/Encoding considerations: binary (CBOR)

* I think that the "Additional information" field and its subfields can 
be removed.

* The value of the field "Person & email address to contact for further 
information" should be:

    LAKE WG mailing list ([e-mail]) or IETF Applications and 
Real-Time Area ([e-mail])

* "Author: See "Authors' Addresses" section."

    should instead be

    "Author/Change controller: IETF"

    then "Change Controller: IESG" can be removed

* You need to add the field "Provisional registration: no"


[Section 7.5]

* IANA has added the media type 
"application/lake-authz-voucherrequest+cbor" to the "CoAP 
Content-Formats" registry under the registry group "Constrained RESTful 
Environments (CoRE) Parameters".

    This should be

    IANA has added the following Content-Format number in the "CoAP 
Content-Formats" registry under the registry group "Constrained RESTful 
Environments (CoRE) Parameters".

* The columns of the registry have changed, see 
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats

    s/Media Type/Content Type

    s/Encoding/Content Coding


[Appendix A.2.1]

* The Uri-Path option is set to ".well-known/edhoc".

    That target URI path is expressed by two occurrences of the Uri-Path 
options, i.e., one option for each URI path segment. You can better say 
either

    > The Uri-Path options are set to ".well-known" and "edhoc".

    or (probably clearer)

    > By means of Uri-Path options, the Uri-Path is set to 
".well-known/edhoc".


[Appendix A.2.3]

* "The Uri-Path option is set to ".well-known/edhoc"."

    Actually, no. Since the combined EDHOC + OSCORE request is used, the 
sent request targets the resource at V (the JRC) that would have 
normally be targeted by a normal OSCORE-protected request, like in the 
case where an OSCORE request is sent after completing EDHOC without this 
optimization.

* To complement the last paragraph, I guess that the ID Context of the 
OSCORE Security Context is left unset.


[Appendix B.1]

* The text says:

    > It consists of a list of application-defined identifiers of V 
(e.g. MAC addresses, SSIDs, PAN IDs, etc.), as defined below:
    >
    > v_hint = [ 1* bstr ]

    Do you actually mean a CBOR array, or instead a CBOR sequence? In 
the latter case, you can use either of the two notations in 
https://datatracker.ietf.org/doc/html/rfc8742#section-4.1


[Appendix B.2]

* The text says:

    > The hint itself is application dependent, and can contain ... . It 
is defined as follows:
    >
    > u_hint: [ 1* bstr ]

    Do you actually mean a CBOR array, or instead a CBOR sequence? In 
the latter case, you can use either of the two notations in 
https://datatracker.ietf.org/doc/html/rfc8742#section-4.1


[Appendix C.2]

* "the plaintext of REJECT_INFO contains"

    I think you mean:

    "the plaintext OPAQUE_INFO used to compute the encrypted REJECT_INFO 
specifies"


[Nits]

Section 1
- s/significant which/significant, which
- s/server which provides/server that provides
- s/similiar/similar
- s/this document we/this document, we
- s/sequence which is/sequence, which is
- s/EDHOC leading/EDHOC, leading

Section 2
- s/e.g./e.g.,
- s/device (the voucher)/device (conveyed in the voucher)
- s/protocol which is lightweight/protocol that is lightweight
- s/constrained link by/constrained link, by
- s/authenticator needs/domain authenticator needs
- s/Overview of message flow/Overview of the message flow

Section 3
- s/relation, this protocol /relation. This protocol
- s/depending on type of/depending on the type of

Section 3.1
- s/to W, this device identifier is/to W. The device identifier used for 
this is

Section 4.3
- s/state is out of scope/state is out of the scope
- s/with echoed/with the echoed

Section 4.5

- s/U and V, which include/U and V, which includes

Section 4.5.1.1
- s/G_X which is reused/G_X that is reused

Section 4.5.1.2
- s/TBD1, triggers/TBD1 triggers

Section 4.5.2.2
s/Otherwise U MUST/Otherwise, U MUST

Section 4.6
- s/between V and with U/between V and U

Section 4.6.1.2
- s/identifiers associated to this/identifiers associated with this

Section 4.6.2.1
- s/associated to the secure/associated with the secure
- s/constructs the the Voucher/constructs the Voucher

Section 5
- s/in LOC_W URI/in the LOC_W URI

Section 5.1
- s/e.g. an X.509/e.g., an X.509
- s/e.g. if the public/e.g., if the public

Section 5.4.1
- s/issue a request:/issue a request such that:

Section 5.4.2
- s/issue a request:/issue a request such that:

Section 6
- s/In this specification the ephemeral/In this specification, the ephemeral
- s/calculations, one option/calculations. One option

Appendix A.1
- s/802.15.4 it is possible/802.15.4, it is possible
- s/Join Proxy does not/The Join Proxy does not

Appendix A.2.1
- s/constructs the EDHOC message_1/constructs EDHOC message_1

Appendix A.2.3
- s/described in Section 4.5}./described in Section 4.5.

Appendix C.1
- s/demonstrates successful/demonstrates a successful

Appendix C.2
- s/W verifies that MAC/W determines that MAC

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se