Draft: draft-ietf-lake-edhoc

Commentary: The definition says array but the CDDL is a CBOR sequence . In this case it works to use a sequence . The CDDL for message1 , 2 3 4 needs to be updated . Right now they say ? EAD1 : any , 
 Might also want to allow more that one CBOR item . The following would be quite general : Should probably write that " + extauthzdata , " follows from " type : int , " 
 Looks good . 
 Was there any reason that this was not merged today . The new IANA registry for Aux Data should probably be another PR . 
 The reason for not merging this yet was to first conclude the discussion about CWT in EAD2 and EAD3 in . 
 By moving out the IANA type to a separate issue and waiting with the CWT related part of we are ready to merge . 
 In PR the type of external authorization data is defined in separate specification . For better interoperability EAD types should be registered in an IANA register . Template for new IANA subsection : ~~ 
 Yes 
 Included in -08 . 
 Has been suggestion to add AD_4 to message 4 . 
 I made a PR addressing all the issue mentioned with aux data . The PR addresses issue 
 EAD4 is to  in -07 so I close this issue . 
 It is too easy to confuse " application data " with " auxiliary data " . The former is the data which is protected with keys obtained through the use of EDHOC , i.e. a straightforward application of EDHOC so the name " application data " is fairly intuitive . The latter is an extension point for use with security applications during EDHOC execution , like third party assisted authorization or certificate enrolment . Perhaps we should rename " auxiliary data " something with " extension " ? 
 I think extension is a bad word choice as it is easy to think about TLS extensions , which this is not similar to at all . Maybe " external data " 
 I suggest " external authorization data " EAD . I think it is good to point out that the data is external to EDHOC and to give a hint of what it is used for . 
 Doing a pull request for this , I stumbled upon several things : ? AD1 : bstr , Why is this bstr instead of any . If the data is CBOR encoded in the first place , wrapping it in a bstr adds two bytes without any benefit I suggest we change this to ? AD1 : any , 
  bstr also makes it harder to put any structure to the data in a formal way later as was discussed . 
 The Responder MUST finish the verification step of message3 before passing AD3 to the application . Why is this stated ? I do n't understand at all . The reason for AD3 to exist is to send things like access tokens that are processed before message3 is completely processed . The current text makes it sound like  is application data which the agreement is that it is not ..... 
 I made a PR addressing all the issue mentioned with aux data . The PR addresses issue 
 Any comments on ? 
 An earlier version of EDHOC stated that was then called EXT and is now called EAD " could be used for authorization tokens that are protected outside of EDHOC . " The intention with that text was CWT . The text has since been removed without being being replaced with any other way to transfer CWT . CWT can in the current version not be transfered in EAD2 or EAD3 
 Why ca n't CWT can be transferred in EAD2 or EAD3 ? As I recall the statement about " protected outside of EDHOC " that allowed protection within as well as outside of EDHOC . 
 It can , but it creates more overhead . Treating CWT differently than X509 seems a bit strange , especially in the opportunistic RPK case . I do n't think the question is why ca n't . It is more why should it . Are there any benefits with sending it in EAD ? 
 Closing this issue : The discussion above was a misunderstanding between  and myself on authentication vs. authorization related information . Meanwhile , in addition to PR , IANA registration of COSE header parameter for CWT and for EAD types have been requested . With this , CWT can be transported in IDCREDx and in EAD ( as soon as the accompanying EAD type has been registered ) .
Paragraph (version A):
Transport of opaque auxiliary data.
Paragraph (version B):
Transport of external authorization data.
Paragraph (version A):
which may be provisioned, e.g., out of band or in the Auxiliary Data,
see AD).
Paragraph (version B):
which may be provisioned, e.g., out of band or in the external
authorization data, see AD).
Paragraph (version A):
In order to reduce round trips and number of messages, and in some
cases also streamline processing, certain security applications may
be integrated into EDHOC by transporting auxiliary data together with
the messages.  One example is the transport of third-party
authorization information protected outside of EDHOC I-D.selander-
ace-ake-authz.  Another example is the embedding of a certificate
enrolment request or a newly issued certificate.
Paragraph (version A):
EDHOC allows opaque auxiliary data (AD) to be sent in the EDHOC
messages.  Unprotected Auxiliary Data (AD_1, AD_2) may be sent in
message_1 and message_2, respectively.  Protected Auxiliary Data
(AD_3) may be sent in message_3.
Paragraph (version A):
Since data carried in AD_1 and AD_2 may not be protected, and the
content of AD_3 is available to both the Initiator and the Responder,
special considerations need to be made such that the availability of
the data a) does not violate security and privacy requirements of the
service which uses this data, and b) does not violate the security
properties of EDHOC.
Paragraph (version B):
In order to reduce round trips and number of messages or to simplify
processing, external security applications may be integrated into
EDHOC by transporting authorization related data together with the
messages.  One example is the transport third-party identity and
authorization information protected out of scope of EDHOC I-
D.selander-ace-ake-authz.  Another example is the embedding of a
certificate enrolment request or a newly issued certificate.
Paragraph (version B):
EDHOC allows opaque external authorization data (EAD) to be sent in
the EDHOC messages.  External authorization data sent in message_1
(EAD_1) or message_2 (EAD_2) must be considered unprotected by EDHOC,
see unprot-data.  External authorization data sent in message_3
(EAD_3) or message_4 (EAD_4) is protected between Initiator and
Responder.
Paragraph (version B):
where type is an int and is followed by one or more ext_authz_data
depending on type as defined in a separate specification.
Paragraph (version B):
The EAD fields of EDHOC are not intended for generic application
data.  Since data carried in EAD_1 and EAD_2 fields may not be
protected, special considerations need to be made such that a) it
does not violate security, privacy etc. requirements of the service
which uses this data, and b) it does not violate the security
properties of EDHOC.  Security applications making use of the EAD
fields must perform the necessary security analysis.
Paragraph (version A):
Use and type of Auxiliary Data (AD_1, AD_2, AD_3; see AD).
Paragraph (version B):
Use and type of external authorization data (EAD_1, EAD_2, EAD_3,
EAD_4; see AD).
Paragraph (version A):
For some parameters, like METHOD_CORR, ID_CRED_x, type of AD_x, the
receiver is able to verify compliance with applicability statement,
and if it needs to fail because of incompliance, to infer the reason
why the protocol failed.
Paragraph (version B):
For some parameters, like METHOD_CORR, ID_CRED_x, type of EAD, the
receiver is able to verify compliance with applicability statement,
and if it needs to fail because of incompliance, to infer the reason
why the protocol failed.
Paragraph (version A):
Other conditions may be part of the applicability statement, such as
target application or use (if there is more than one application/use)
to the extent that EDHOC can distinguish between them.  In case
multiple applicability statements are used, the receiver needs to be
able to determine which is applicable for a given session, for
example based on URI or Auxiliary Data type.
Paragraph (version B):
Other conditions may be part of the applicability statement, such as
target application or use (if there is more than one application/use)
to the extent that EDHOC can distinguish between them.  In case
multiple applicability statements are used, the receiver needs to be
able to determine which is applicable for a given session, for
example based on URI or external authorization data type.
Paragraph (version B):
EAD_1 - unprotected external authorization data, see AD.
Paragraph (version A):
Pass AD_1 to the security application.
Paragraph (version B):
Pass EAD_1 to the security application.
Paragraph (version A):
CRED_R - bstr containing the credential of the Responder,
see id_cred.
Paragraph (version B):
Pass EAD_2 to the security application.
Paragraph (version A):
Pass AD_2 to the security application.
Paragraph (version B):
Pass EAD_3 to the security application.
Paragraph (version A):
Pass AD_3, the connection identifiers (C_I, C_R), and the
application algorithms in the selected cipher suite to the
security application.  The application can now derive application
keys using the EDHOC-Exporter interface.
Paragraph (version B):
Pass the connection identifiers (C_I, C_R), and the application
algorithms in the selected cipher suite to the security
application.  The application can now derive application keys
using the EDHOC-Exporter interface.
Paragraph (version A):
MAC_4 is the 'ciphertext' of the COSE_Encrypt0.
Paragraph (version B):
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 empty.
Paragraph (version B):
CIPHERTEXT_4 is the 'ciphertext' of the COSE_Encrypt0.
Paragraph (version A):
Verify MAC_4 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 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):
Pass EAD_4 to the security application.
Paragraph (version A):
Compared to SIGMA, EDHOC adds an explicit method type and expands the
message authentication coverage to additional elements such as
algorithms, auxiliary data, and previous messages.  This protects
against an attacker replaying messages or injecting messages from
another session.
Paragraph (version B):
Compared to SIGMA, EDHOC adds an explicit method type and expands the
message authentication coverage to additional elements such as
algorithms, external authorization data, and previous messages.  This
protects against an attacker replaying messages or injecting messages
from another session.
Paragraph (version A):
The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information.  This also
applies for encrypted data sent to an unauthenticated party.  In
particular, it applies to AD_1, ID_CRED_R, AD_2, and ERR_MSG.  Using
the same AD_1 in several EDHOC sessions allows passive eavesdroppers
to correlate the different sessions.  Another consideration is that
the list of supported cipher suites may potentially be used to
identify the application.
Paragraph (version A):
The Initiator and the Responder must also make sure that
unauthenticated data does not trigger any harmful actions.  In
particular, this applies to AD_1 and ERR_MSG.
Paragraph (version B):
The Initiator and the Responder must make sure that unprotected data
and metadata do not reveal any sensitive information.  This also
applies for encrypted data sent to an unauthenticated party.  In
particular, it applies to EAD_1, ID_CRED_R, EAD_2, and error
messages.  Using the same EAD_1 in several EDHOC sessions allows
passive eavesdroppers to correlate the different sessions.  Another
consideration is that the list of supported cipher suites may
potentially be used to identify the application.
Paragraph (version B):
The Initiator and the Responder must also make sure that
unauthenticated data does not trigger any harmful actions.  In
particular, this applies to EAD_1 and error messages.
Paragraph (version A):
The Responder MUST finish the verification step of message_3 before
passing AD_3 to the application.