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

[Geovane Fedrecheski <[e-mail]>]

Hi Marco, 

Thank you for your detailed and helpful review. We are working to update the draft based on the provided comments. 

Best regards, 
Geovane. 

> De: "Marco Tiloca" <marco.tiloca=[e-mail]>
> À: "lake" <[e-mail]>
> Envoyé: Mercredi 20 Mars 2024 05:54:27
> Objet: [Lake] Review of draft-ietf-lake-authz-01

> 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 ( [ mailto:[e-mail] | [e-mail] ] ) or IETF
> Applications and Real-Time Area ( [ mailto:[e-mail] | [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
> |
> 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 |
> 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 |
> 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/ | https://www.ri.se ]

> --
> Lake mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lake