Draft: draft-ietf-lake-edhoc

Commentary: As discussed , the " COSE construct " parts should be moved to the appendix instead of subsection as discussed in the issues . Might be good to write that the text is an explanation of how COSE calls the AEAD / Signature interface . This description was used to generate the current test vectors . 
 Look good . One minor questions : " prepended  , see { { ci - oscore } " The OSCORE ref is ok , but is that the best ref for the general  prepending ? 
 Ready to merge now ? 
 In you " Explanation : " to COSE processing description of Section 5 . I removed that as out context for that PR and instead opened this issue as placeholder . 
 Essential that something like that need to be to -11 . It is very important to point out that this is not specification at all . The COSE RFC specifies these things . If the EDHOC spec makes anything incorrect or COSE makes updates in the future , that apply and NOT the EHDOC spec . 
 Unless you have a better suggestion than " Explanation : " I think " Explanation : " should stay , but I can live with basically any formulation here . Whether it is out of the context of the PR is not very important . The important thing is that it is merged to master . The important thing is to make it very clear that these parts is not normative specification . 
 There was already an issue regarding this 
 OK . Just adding " Explanation : " was not sufficient explanation , at least not for me . So now we have two issues and surely wo n't forget adding it to the master . 
 I see now that you already submitted -11 . " Essential " was maybe a bit strong , but I it would have been good to clearly distinguish between COSE and EDHOC before more formal verfication . Let 's try to do that for -12 . Might be good to add that the separaration between signature algorithm and key authentication algorithm ( where the key authentication algorithm might not be a COSE algorithm ) comes from COSE . TLS chose a different approach than COSE where the curve ( but not RSA key lenght ) is integrated into the " signature algorithm " . So also in TLS the security level and exact parameters are determined by the signature algorithm and the key algorithm together . COSE is flexible and allows ECDSA with Brainpool as long as Brainpool is stored in a X509 even if Brainpool is not registered in the COSE IANA registry . The security consideration section in EDHOC should maybe consider refering to the section in COSE section discussion  . 
 Maybe something like COSE recap : COSE summary : COSE explanation : Informal COSE recap : Informal COSE summary : Informal COSE explanation : 
 Current text says : " COSE constructs the input to the Signature Algorithm as : The key is the private authentication key of the Responder . The message M to be signed = [ " Signature1 " , < < IDCREDR , < < TH2 , CREDR , ? EAD2 , MAC2 ] " If this is not clear , then I think a prefix is not enough . A potential confusion is where the COSE processing stops and EDHOC processing restarts . More clear is to separate the explanation from the processing and put this text in some other section . The purpose of appendix C.3 is to explain COSE , so that section could be used . At least a reference to the explanation should be put in that section . 
 Let 's make subsections for the " COSE constructs " . Lets discuss how COSE works with signature algorithms and public keys . 
 I went through the processing steps and removed the COSE constructs part , see . We may want to add to C.3 if something was lost in the process . 
 In C.3 . we may e.g. describe how Sigstructure and Encstructure are used 
 C.3 used to contain the " COSE constructs " parts . I.e. explanation of how COSE takes the input to its API and transform them to input to the AEAD / Signature interfaces . Some implementor a long time ago suggested to integrate this into the body , but maybe it is better to have it in the appendix to make it clearer what is EDHOC and what is COSE 
 in PR the " COSE constructs " explanations for COSESign1 and COSEEncrypt0 are now back in C.3 , with reference to it from the message processing sections 5.3 - 5.5 . 
 Fixed in 
 Several things in the document is not specification but rather clarification of how COSE works . The additon of this and the integration in the main body was requested by several implementors . It should be more clearly marked that these parts just explain COSE and does not define anything . If soemthing would be wrong . The COSE specification apply . E.g. 
 The explanations of COSE are moved to C.3 in PR .
Paragraph (version A):
This section specifies formatting of the messages and processing
steps.  Error messages are specified in error.
Paragraph (version B):
This section specifies formatting of the messages and processing
steps.  Error messages are specified in error.  Annotated traces of
EDHOC protocol runs are provided in I-D.selander-lake-traces.
Paragraph (version A):
For each session, the endpoints are assumed to keep an associated
protocol state containing identifiers, keys, etc. used for subsequent
processing of protocol related data.  The protocol state is assumed
to be associated to an applicability statement (applicability) which
provides the context for how messages are transported, identified,
and processed.
Paragraph (version B):
For each new/ongoing session, the endpoints are assumed to keep an
associated protocol state containing identifiers, keying material,
etc. used for subsequent processing of protocol related data.  The
protocol state is assumed to be associated to an applicability
statement (applicability) which provides the context for how messages
are transported, identified, and processed.
Paragraph (version A):
METHOD = 0, 1, 2, or 3 (see fig-method-types).
Paragraph (version B):
METHOD - authentication method, see method.
Paragraph (version A):
The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages.  SUITES_I contains
the ordered list of supported cipher suites, truncated after the
cipher suite selected for this session.  The selected cipher suite
MAY be changed between sessions, e.g., based on previous error
messages (see next bullet), but all cipher suites which are more
preferred than the selected cipher suite in the list MUST be
included in SUITES_I.
Paragraph (version A):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.  If the Initiator previously received from the
Responder an error message with error code 2 (see wrong-selected)
indicating cipher suites supported by the Responder, then the
Initiator SHOULD select the most preferred supported cipher suite
among those (note that error messages are not authenticated and
may be forged).
Paragraph (version B):
SUITES_I contains a list of supported cipher suites, in order of
preference, truncated after the cipher suite selected for this
session.
Paragraph (version B):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.
Paragraph (version B):
The selected cipher suite MAY be changed between sessions,
e.g., based on previous error messages (see next bullet), but
all cipher suites which are more preferred than the selected
cipher suite in the list MUST be included in SUITES_I.
Paragraph (version B):
If the Initiator previously received from the Responder an
error message with error code 2 (see wrong-selected) indicating
cipher suites supported by the Responder, then the Initiator
SHOULD select the most preferred supported cipher suite among
those (note that error messages are not authenticated and may
be forged).
Paragraph (version B):
The supported cipher suites and the order of preference MUST
NOT be changed based on previous error messages.
Paragraph (version A):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error, and the session
MUST be discontinued.  Sending error messages is essential for
debugging but MAY e.g., be skipped due to denial-of-service reasons,
see security.
Paragraph (version B):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error, and the session
MUST be discontinued.  Sending error messages is essential for
debugging but MAY e.g., be skipped due to denial-of-service reasons,
see dos.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version A):
The key is the private authentication key of the Responder.
Paragraph (version A):
CIPHERTEXT_2 is encrypted by using the Expand function as a binary
additive stream cipher.
Paragraph (version A):
Note that if ID_CRED_R contains a single 'kid' parameter,
i.e., ID_CRED_R = { 4 : kid_R }, only the byte string or
integer kid_R is conveyed in the plaintext encoded as a bstr
or int.
Paragraph (version A):
Verify that the identity of the Responder is an allowed identity
for this connection, see auth-key-id.
Paragraph (version B):
Verify that the identity of the Responder is an allowed identity
for this connection, see identities.
Paragraph (version A):
If any processing step fails, the Initiator SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version B):
If any processing step fails, the Initiator SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g., be skipped if a
session cannot be found or due to denial-of-service reasons, see dos.
If an error message is sent, the session MUST be discontinued.
Paragraph (version A):
The key is the private authentication key of the Initiator.
Paragraph (version A):
Compute an outer COSE_Encrypt0 as defined in Section 5.3 of I-
D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in
the selected cipher suite, K_3, IV_3, and the following
parameters.  The protected header SHALL be the empty CBOR byte
string.
Paragraph (version A):
Note that if ID_CRED_I contains a single 'kid' parameter,
i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or
integer kid_I is conveyed in the plaintext encoded as a bstr
or int.
Paragraph (version A):
CIPHERTEXT_3 is the 'ciphertext' of the outer COSE_Encrypt0.
Paragraph (version A):
Encode message_3 as a sequence of CBOR encoded data items as
specified in asym-msg3-form.
Paragraph (version B):
CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.
Paragraph (version B):
Encode message_3 as a CBOR data item as specified in asym-
msg3-form.
Paragraph (version A):
Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token and the 5-tuple as a
client, or the prepended C_R as a server).
Paragraph (version A):
Decrypt and verify the outer COSE_Encrypt0 as defined in
Section 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC
AEAD algorithm in the selected cipher suite, K_3, and IV_3.
Paragraph (version A):
Verify that the identity of the Initiator is an allowed identity
for this connection, see auth-key-id.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Section 5.3 of
I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in
the selected cipher suite, and the parameters defined in asym-
msg3-proc.
Paragraph (version B):
Verify that the identity of the Initiator is an allowed identity
for this connection, see identities.
Paragraph (version A):
Further considerations are provided in applicability.
Paragraph (version B):
Further considerations about when to use message_4 are provided in
applicability and sec-prop.
Paragraph (version A):
Compute a COSE_Encrypt0 as defined in Section 5.3 of I-D.ietf-
cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the
selected cipher suite, and the following parameters.  The
protected header SHALL be the empty CBOR byte string.
Paragraph (version A):
CIPHERTEXT_4 is the ciphertext of the COSE_Encrypt0.
Paragraph (version A):
Encode message_4 as a sequence of CBOR encoded data items as
specified in asym-msg4-form.
Paragraph (version B):
EAD_4 - protected external authorization data, see AD.
Paragraph (version B):
CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.
Paragraph (version B):
Encode message_4 as a CBOR data item as specified in asym-
msg4-form.
Paragraph (version A):
Decrypt and verify the outer COSE_Encrypt0 as defined in
Section 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC
AEAD algorithm in the selected cipher suite, and the parameters
defined in asym-msg4-proc.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Section 5.3 of
I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in
the selected cipher suite, and the parameters defined in asym-
msg4-proc.