Draft: draft-ietf-lake-edhoc

Commentary:  requested the basic authentication services by EDHOC being highlighted in the beginning of the document . I tried to fit that in but did n't find a good place . Here is some text if someone wants to try : 
 A lot of changes are good and needed . Comments Hard to get an overview of this PR . Especially which of the deleted text that has been removed and what has just been moved around . EDHOC MUST allow the application to read the authentication credential . Should this be " information about authentication credentials " , i.e. IDCREDx ? EDHOC MUST have access to the authentication key of the authentication credential . EDHOC also need the authentication credentials , i.e. CRED_x ? Not sure all the EAD text belongs in the body . Lot of duplication in processing . A lot of the text is talking about unfinished drafts . The new text is Authentication Related Verifications { # auth - validation } has several issues . "match the algorithm " " The validation needs to be made " " The issuer of the authentication credential needs to be trusted with issuing the credential . " " the trust anchor is a Certification Authority ( CA ) certificate " " at least one CA public key certificate " " subject of the certificate owns the public key " I am also not sure it should be . The comment was to shorten down 3.5 . This seems to expand things . 
 I 've made an attempt at all comments by have a look . 
 This looks quite good now . I just checked the greed part of the diff ( I have not checked the parts , i.e. , if something important was removed ) . Comments ( but most of them minor ) " When the identified credential is a chain or a bag , the authentication credential CREDx is just the end - entity X.509 or C509 certificate / CWT . " That is always true . " Since CREDx is used in the integrity verification , see { { asym - msg2 - proc } } and { { asym - msg3 - proc } } , it needs to be specified such that it is identical when used by Initiator or Responder . " I do n't understand why this was . " When the authentication credential is an ( end - entity ) X.509 " If " end - entity " should be it is better to not have the parathesis Can we make the end - entity text more general . Applies to CWT as well even if you can not transfer more then one . " If EAD1 is present , make message1 content available to the application for EAD processing . " Do we want to force that everything is available . Maybe goood . As it is simple . " Make IDCREDR and EAD2 ( if present ) available to the application for authentication- and EAD processing . " Are you sure GY , CR is not needed ? This seems different from message1 where the whole message is made available . " Message is 1,2,3 or 4 , " ? " * Similarly , when a PKI is used with CWTs , each endpoint needs a specific identity or set of identities it is allowed to communicate with " This is not PKI specific " When PKI is not used ( CCS , self - signed certificate / CWT ) " Is it " self - signed " or is pre - configured ? " For example , the name of the subject may be a canonical representation of the public key . " What should the reader do with this . Might be confusing . " To prevent misbinding attacks in systems where an attacker can " Should this come a bit earlier ? OLD When a Public Key Infrastructure ( PKI ) is used with certificates , the trust anchor is a Certification Authority ( CA ) certificate . Each party needs at least one CA public key certificate , or just the CA public key . NEW When a Public Key Infrastructure ( PKI ) is used with certificates , the trust anchor is a Certification Authority ( CA ) certificate , or just the CA public key . " The issuer of the authentication credential needs to be trusted with issuing the credential . X.509 and C509 certificates includes the “ Issuer ” field . In CWT and CCS , the “ iss ” claim has a similar meaning . " Not sure this is needed . TOFU is misssing that is ok for now How ead_label is not defined . 
 The section are now using different terms for CREDx and IDCREDx than other parts of the document . The intro defines them as and . is also used in the security considerations . CREDI and CREDR are the containing the public authentication keys of I and R , respectively . IDCREDI and IDCRED_R are enabling the recipient party to retrieve the credential of I and R , respectively . 
 From follow up of Sean 's review : How to handle errors in EAD processing should be included in the new EAD appendix . 
 I propose that errors in EAD processing are left out of scope for EDHOC . If a security application processing EAD reaches an unexpected state it may discontinue the EDHOC processing , or it may continue EDHOC processing potentially with an EAD being sent back . The specification defining the EAD for this security application should describe this . I add this to PR . 
 With the new content of Section 3.8 and Appendix E ( now merged with master branch ) it should be clear that EAD processing is separate from EDHOC . Regarding EAD - related errors , Appendix E now states : Good enough ? 
 Provide examples to simplify understanding of intended use 
  . This is releated to . I should not have closed that one . EAD is stil underspecified . 
 Related to Stephen 's comment in : checking authentication ? If EAD2 indeed contains external authorization data ( e.g. information about identity of intended endpoint ) , then EAD2 needs to be processed before you can verify the identity of the other endpoint and the integrity of the message . But if we look at EAD3 , the same things apply , but we also claim that EAD_3 is protected between Initiator and Responder , which with the current order of things is n't verified at the time when EAD processed . 
 PR addresses this issue . Rewrite of section 3.8 and appendix with more details Application should consider EAD unprotected by EDHOC . Details of how EAD protection is moved to security considerations ( 8.1 ) 
 as above and with the new appendix E is now merged . 
 Thanks for doing these changes . Section 3.5 reads nice . A couple of comments inline .
Mailing list commentary: Hi I pruned out the “ done ” ones and removed them from this response . I wanted to close the loop on some of the others , which frankly mostly appeared to be my misunderstanding . Nope that explains it . Okay I can re - review when it ’s shortened up . I think you can safely ignore this one ;) I was thinking about how CMS has a bag of certs and how S / MIME says send up to but not including the root . The x5u , as you noted , serves the same purpose . You can safely ignore this comment . Yeah I remember I was there . As long as your consider what to do when you get an enrollment error this will be fine to do . I ’d leave it if it works . No strong objection on my part . Yes I think that ’s a better way to describe it . And there I missed it ;) You ’re confused . I think it was me . You can safely ignore this one . Cheers , spt
Paragraph (version A):
CRED_I and CRED_R are the credentials containing the public
authentication keys of I and R, respectively.
Paragraph (version A):
ID_CRED_I and ID_CRED_R are used to identify and optionally
transport the authentication keys of the Initiator and the
Responder, respectively.
Paragraph (version B):
CRED_I and CRED_R are the authentication credentials containing
the public authentication keys of I and R, respectively.
Paragraph (version B):
ID_CRED_I and ID_CRED_R are used to identify and optionally
transport the credentials of the Initiator and the Responder,
respectively.
Paragraph (version A):
EDHOC supports various settings for how the other endpoint's
authentication (public) key is transported, identified, and trusted
as described in this section.
Paragraph (version A):
in the key derivation (in case of a static Diffie-Hellman key, see
key-der).
Paragraph (version A):
The authentication credential (CRED_x) contains, in addition to the
authentication key, also the authentication key algorithm and
optionally other parameters such as identity, key usage, expiry,
issuer, etc. (see auth-cred).  Identical authentication credentials
need to be established in both endpoints to be able to verify
integrity, see fig-sigma.  For many settings it is not necessary to
transport the authentication credential within EDHOC over constrained
links, for example, it may be pre-provisioned or acquired out-of-band
over less constrained links.
Paragraph (version A):
EDHOC relies on COSE for identification of authentication credentials
(using ID_CRED_x, see id_cred) and supports all credential types for
which COSE header parameters are defined (see auth-cred).
Paragraph (version A):
The choice of authentication credential depends also on the trust
model (see identities).  For example, a certificate or CWT may rely
on a trusted third party, whereas a CCS or a self-signed certificate/
CWT may be used when trust in the public key can be achieved by other
means, or in the case of trust-on-first-use.
Paragraph (version A):
The type of authentication key, authentication credential, and the
way to identify the credential have a large impact on the message
size.  For example, the signature_or_MAC field is much smaller with a
static DH key than with a signature key.  A CCS is much smaller than
a self-signed certificate/CWT, but if it is possible to reference the
credential with a COSE header like 'kid', then that is typically much
smaller than to transport a CCS.
Paragraph (version A):
Policies for what connections to allow are typically set based on the
identity of the other party, and parties typically only allow
connections from a specific identity or a small restricted set of
identities.  For example, in the case of a device connecting to a
network, the network may only allow connections from devices which
authenticate with certificates having a particular range of serial
numbers and signed by a particular CA.  On the other hand, the device
may only be allowed to connect to a network which authenticates with
a particular public key (information of which may be provisioned,
e.g., out of band or in the external authorization data, see AD).
The EDHOC implementation or the application must decide on allowing a
connection or not depending on the intended endpoint, and in
particular whether it is a specific identity or a set of identities.
Either EDHOC passes information about identity to the application for
a decision, or EDHOC needs to have access to relevant information and
makes the decision on its own.
Paragraph (version A):
EDHOC assumes the existence of mechanisms (certification authority,
trusted third party, pre-provisioning, etc.) for specifying and
distributing authentication credentials.
Paragraph (version A):
When a Public Key Infrastructure (PKI) is used with certificates,
the trust anchor is a Certification Authority (CA) certificate,
and the identity is the subject whose unique name, e.g., a domain
name, a Network Access Identifier (NAI), or an Extended Unique
Identifier (EUI), is included in the endpoint's certificate.  In
order to run EDHOC each party needs at least one CA public key
certificate, or just the public key, and a specific identity or
set of identities it is allowed to communicate with.  Only
validated public-key certificates with an allowed subject name, as
specified by the application, are to be accepted.  EDHOC provides
proof that the other party possesses the private authentication
key corresponding to the public authentication key in its
certificate, also known as proof-of-possession.  The certification
path contains proof that the subject of the certificate owns the
public key in the certificate.
Paragraph (version A):
Similarly, when a PKI is used with CWTs, each party needs to have
at least one trusted third party public key as trust anchor to
verify the end-entity CWTs, and a specific identity or set of
identities it is allowed to communicate with to match against the
relevant claim, such as 'sub' (subject).  The trusted third party
public key can, e.g., be stored in a self-signed CWT or in a CCS.
Paragraph (version A):
When PKI is not used (CCS, self-signed certificate/CWT), the trust
anchor is the authentication key of the other party.  In this
case, the identity is typically directly associated to the
authentication key of the other party.  For example, the name of
the subject may be a canonical representation of the public key.
Alternatively, if identities can be expressed in the form of
unique subject names assigned to public keys, then a binding to
identity can be achieved by including both public key and
associated subject name in the protocol message computation:
CRED_I or CRED_R may be a self-signed certificate/CWT or CCS
containing the authentication key and the subject name, see auth-
cred.  In order to run EDHOC, each endpoint needs a specific
authentication key/unique associated subject name, or a set of
public authentication keys/unique associated subject names, which
it is allowed to communicate with.  EDHOC provides the proof that
the other party possesses the private authentication key
corresponding to the public authentication key.
Paragraph (version A):
To prevent misbinding attacks in systems where an attacker can
register public keys without proving knowledge of the private key,
SIGMA SIGMA enforces a MAC to be calculated over the "identity".
EDHOC follows SIGMA by calculating a MAC over the whole credential,
which in case of an X.509 or C509 certificate includes the "subject"
and "subjectAltName" fields, and in the case of CWT or CCS includes
the "sub" claim.  While the SIGMA paper only focuses on the identity,
the same principle is true for other information such as policies
associated to the public key.
Paragraph (version A):
The authentication key (i.e. the public key used for authentication)
MUST be a signature key or static Diffie-Hellman key.  The Initiator
and the Responder MAY use different types of authentication keys,
e.g., one uses a signature key and the other uses a static Diffie-
Hellman key.  The authentication key algorithm needs to be compatible
with the method and the cipher suite.  The authentication key
algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used, and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version B):
EDHOC supports various settings for how the other endpoint's
authentication (public) key may be transported, identified, and
trusted.
Paragraph (version B):
EDHOC transports information about credentials in ID_CRED_I and
ID_CRED_R (described in id_cred).  Based on this information, the
authentication credentials CRED_I and CRED_R (described in auth-
cred) can be obtained.  EDHOC may also transport certain
authentication related information as External Authorization Data
(see AD).
Paragraph (version B):
The authentication credential is input to the integrity
verification using the MAC fields.
Paragraph (version B):
The authentication key of the authentication credential is used
with the Signature_or_MAC field to verify proof-of-possession
of the private key.
Paragraph (version B):
Other authentication related verifications are out of scope for
EDHOC, and is the responsibility of the application.  In particular,
the authentication credential needs to be validated in the context of
the connection for which EDHOC is used, see auth-validation.  EDHOC
MUST allow the application to read received information about
credential (ID_CRED_R, ID_CRED_I).  EDHOC MUST have access to the
authentication key and the authentication credential.
Paragraph (version B):
Note that the type of authentication key, authentication credential,
and the identification of the credential have a large impact on the
message size.  For example, the signature_or_MAC field is much
smaller with a static DH key than with a signature key.  A CCS is
much smaller than a self-signed certificate/CWT, but if it is
possible to reference the credential with a COSE header like 'kid',
then that is in turn much smaller than a CCS.
Paragraph (version B):
The authentication key (i.e. the public key used for authentication)
MUST be a signature key or static Diffie-Hellman key.  The Initiator
and the Responder MAY use different types of authentication keys,
e.g., one uses a signature key and the other uses a static Diffie-
Hellman key.
Paragraph (version B):
The authentication key algorithm needs to be compatible with the
method and the cipher suite (see cs).  The authentication key
algorithm needs to be compatible with the EDHOC key exchange
algorithm when static Diffie-Hellman authentication is used, and
compatible with the EDHOC signature algorithm when signature
authentication is used.
Paragraph (version A):
Note that for most signature algorithms, the signature is determined
by the signature algorithm and the authentication key algorithm
together.  When using static Diffie-Hellman keys the Initiator's and
Responder's private authentication keys are called I and R,
respectively, and the public authentication keys are called G_I and
G_R, respectively.
Paragraph (version A):
For X.509 the authentication key is represented with a
SubjectPublicKeyInfo field.  For CWT and CCS, the authentication key
is represented with a 'cnf' claim RFC8747 containing a COSE_Key I-
D.ietf-cose-rfc8152bis-struct.
Paragraph (version A):
EDHOC relies on COSE for identification of authentication credentials
(see id_cred) and supports all credential types for which COSE header
parameters are defined including X.509 RFC5280, C509 I-D.ietf-cose-
cbor-encoded-cert, CWT RFC8392 and CWT Claims Set (CCS) RFC8392.
When the identified credential is a chain or bag, CRED_x is just the
end-entity X.509 or C509 certificate / CWT.  In X.509 and C509
certificates, signature keys typically have key usage
"digitalSignature" and Diffie-Hellman public keys typically have key
usage "keyAgreement" RFC8410.
Paragraph (version A):
CRED_x needs to be defined such that it is identical when used by
Initiator or Responder.  The Initiator and Responder are expected to
agree on a specific encoding of the credential, see applicability.
It is RECOMMENDED that the COSE 'kid' parameter, when used, refers to
a specific encoding.  The Initiator and Responder SHOULD use an
available authentication credential (transported in EDHOC or
otherwise provisioned) without re-encoding.  If for some reason re-
encoding of the authentication credential may occur, then a potential
common encoding for CBOR based credentials is bytewise lexicographic
order of their deterministic encodings as specified in Section 4.2.1
of RFC8949.
Paragraph (version A):
When the authentication credential is an X.509 certificate, CRED_x
SHALL be the end-entity DER encoded certificate, encoded as a bstr
I-D.ietf-cose-x509.
Paragraph (version B):
Note that for most signature algorithms, the signature is determined
by the signature algorithm and the authentication key algorithm
together.  When using static Diffie-Hellman keys the Initiator's and
Responder's private authentication keys are denoted I and R,
respectively, and the public authentication keys are denoted G_I and
G_R, respectively.
Paragraph (version B):
For X.509 certificates the authentication key is represented with a
SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the
authentication key is represented with a 'cnf' claim RFC8747
containing a COSE_Key I-D.ietf-cose-rfc8152bis-struct.
Paragraph (version B):
EDHOC relies on COSE for identification of credentials (see id_cred),
for example X.509 certificates RFC5280, C509 certificates I-D.ietf-
cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS)
RFC8392.  When the identified credential is a chain or a bag, the
authentication credential CRED_x is just the end entity X.509 or C509
certificate / CWT.
Paragraph (version B):
Since CRED_R is used in the integrity verification, see asym-
msg2-proc, it needs to be specified such that it is identical when
used by Initiator or Responder.  Similarly for CRED_I, see asym-
msg3-proc.  The Initiator and Responder are expected to agree on a
specific encoding of the credential, see applicability.
Paragraph (version B):
It is RECOMMENDED that the COSE 'kid' parameter, when used to
identify the authentication credential, refers to a specific
encoding.  The Initiator and Responder SHOULD use an available
authentication credential (transported in EDHOC or otherwise
provisioned) without re-encoding.  If for some reason re-encoding of
the authentication credential may occur, then a potential common
encoding for CBOR based credentials is bytewise lexicographic order
of their deterministic encodings as specified in Section 4.2.1 of
RFC8949.
Paragraph (version B):
When the authentication credential is an X.509 certificate, CRED_x
SHALL be the DER encoded certificate, encoded as a bstr I-D.ietf-
cose-x509.
Paragraph (version B):
When the authentication credential is a C509 certificate, CRED_x
SHALL be the C509Certificate I-D.ietf-cose-cbor-encoded-cert.
Paragraph (version A):
ID_CRED_R and ID_CRED_I are transported in message_2 and message_3,
respectively (see asym-msg2-proc and asym-msg3-proc).  They are used
to identify and optionally transport the authentication keys of the
Initiator and the Responder, respectively.  ID_CRED_I and ID_CRED_R
do not have any cryptographic purpose in EDHOC since EDHOC integrity
protects the authentication credential.  EDHOC relies on COSE for
identification of authentication credentials and supports all types
of COSE header parameters used to identify authentication credentials
including X.509, C509, CWT and CCS.
Paragraph (version A):
ID_CRED_R is intended to facilitate for the Initiator to retrieve
the Responder's authentication key.
Paragraph (version A):
ID_CRED_I is intended to facilitate for the Responder to retrieve
the Initiator's authentication key.
Paragraph (version A):
ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more
COSE header parameter.  ID_CRED_I and ID_CRED_R MAY contain different
header parameters.  The header parameters typically provide some
information about the format of authentication credential.
Paragraph (version A):
Note that COSE header parameters in ID_CRED_x are used to identify
the sender's authentication credential.  There is therefore no reason
to use the "-sender" header parameters, such as x5t-sender, defined
in Section 3 of I-D.ietf-cose-x509.  Instead, the corresponding
parameter without "-sender", such as x5t, SHOULD be used.
Paragraph (version B):
ID_CRED_R is intended to facilitate for the Initiator to retrieve
the authentication credential CRED_R and the authentication key of
R.
Paragraph (version B):
ID_CRED_I is intended to facilitate for the Responder to retrieve
the authentication credential CRED_I and the authentication key of
I.
Paragraph (version B):
ID_CRED_x may contain the authentication credential CRED_x, but for
many settings it is not necessary to transport the authentication
credential within EDHOC, for example, it may be pre-provisioned or
acquired out-of-band over less constrained links.  ID_CRED_I and
ID_CRED_R do not have any cryptographic purpose in EDHOC since the
authentication credentials are integrity protected.
Paragraph (version B):
EDHOC relies on COSE for identification of credentials and supports
all credential types for which COSE header parameters are defined
including X.509 certificates (I-D.ietf-cose-x509), C509 certificates
(I-D.ietf-cose-cbor-encoded-cert), CWT (cwt-header-param) and CWT
Claims Set (CCS) (cwt-header-param).
Paragraph (version B):
ID_CRED_I and ID_CRED_R are COSE header maps and contains one or more
COSE header parameters.  ID_CRED_I and ID_CRED_R MAY contain
different header parameters.  The header parameters typically provide
some information about the format of the credential.
Paragraph (version B):
Note that COSE header parameters in ID_CRED_x are used to identify
the sender's credential.  There is therefore no reason to use the
"-sender" header parameters, such as x5t-sender, defined in Section 3
of I-D.ietf-cose-x509.  Instead, the corresponding parameter without
"-sender", such as x5t, SHOULD be used.
Paragraph (version B):
An EDHOC cipher suite consists of an ordered set of algorithms from
the "COSE Algorithms" and "COSE Elliptic Curves" registries as well
as the EDHOC MAC length.  All algorithm names and definitions follows
from COSE I-D.ietf-cose-rfc8152bis-algs.  Note that COSE sometimes
uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for
AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to
be specified with enough parameters to make them completely
determined.  The MAC length MUST be at least 8 bytes.  Any
cryptographic algorithm used in the COSE header parameters in ID_CRED
is selected independently of the cipher suite.  EDHOC is currently
only specified for use with key exchange algorithms of type ECDH
curves, but any Key Encapsulation Method (KEM), including Post-
Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc.
Use of other types of key exchange algorithms to replace static DH
authentication (method 1,2,3) would likely require a specification
updating EDHOC with new methods.
Paragraph (version A):
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 in the messages.
One example is third-party identity and authorization information
whose protection is out of scope of EDHOC I-D.selander-ace-ake-authz.
Another example is a certificate enrollment request or the resulting
issued certificate.
Paragraph (version A):
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) should 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 A):
Applications using external authorization data need to specify
ead_value format, processing, and security considerations and
register the ead_label, see iana-ead.
Paragraph (version A):
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 it does
not violate security and privacy requirements of the service which
uses this data.  Moreover, the content in an EAD field may impact the
security properties provided by EDHOC.  Security applications making
use of the EAD fields must perform the necessary security analysis.
Paragraph (version B):
In order to reduce round trips and the number of messages or to
simplify processing, external security applications may be integrated
into EDHOC by transporting authorization related data in the
messages.
Paragraph (version B):
EDHOC allows opaque external authorization data (EAD) to be sent in
each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).
Paragraph (version B):
A security application using external authorization data need to
register an ead_label, specify the ead_value format for each message
(see iana-ead), and describe processing and security considerations.
Paragraph (version B):
The EAD fields of EDHOC must not be used for generic application
data.  Examples of the use of EAD is provided in ead-appendix.
Paragraph (version A):
Type used to identify authentication credentials (ID_CRED_I,
ID_CRED_R; see id_cred).
Paragraph (version B):
Type used to identify credentials (ID_CRED_I, ID_CRED_R; see
id_cred).
Paragraph (version A):
For other parameters, like CRED_x in the case that it is not
transported, it may not be possible to verify that incompliance with
applicability template was the reason for failure: Integrity
verification in message_2 or message_3 may fail not only because of
wrong authentication credential.  For example, in case the Initiator
uses public key certificate by reference (i.e., not transported
within the protocol) then both endpoints need to use an identical
data structure as CRED_I or else the integrity verification will
fail.
Paragraph (version B):
For other parameters, like CRED_x in the case that it is not
transported, it may not be possible to verify that incompliance with
applicability template was the reason for failure: Integrity
verification in message_2 or message_3 may fail not only because of
wrong credential.  For example, in case the Initiator uses public key
certificate by reference (i.e., not transported within the protocol)
then both endpoints need to use an identical data structure as CRED_I
or else the integrity verification will fail.
Paragraph (version A):
EAD_1 - unprotected external authorization data, see AD.
Paragraph (version B):
EAD_1 - external authorization data, see AD.
Paragraph (version A):
Verify that G_X is not equal to G_X in a simultanous EDHOC message
exchange initiated by the Responder.
Paragraph (version A):
Pass EAD_1 to the security application.
Paragraph (version B):
If EAD_1 is present then make it available to the application for
EAD processing.
Paragraph (version A):
Pass EAD_2 to the security application.
Paragraph (version A):
Verify that the identity of the Responder is an allowed identity
for this connection, see identities.
Paragraph (version B):
Make ID_CRED_R and EAD_2 (if present) available to the application
for authentication- and EAD processing.
Paragraph (version B):
Obtain the authentication credential (CRED_R) and the
authentication key of R from the application (or by other means).
Paragraph (version A):
Pass the connection identifiers (C_I, C_R) and the application
algorithms in the selected cipher suite to the application.  The
application can now derive application keys using the EDHOC-Exporter
interface, see exporter.
Paragraph (version A):
Pass EAD_3 to the security application.
Paragraph (version A):
Verify that the identity of the Initiator is an allowed identity
for this connection, see identities.
Paragraph (version A):
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 B):
Make ID_CRED_I and EAD_3 (if present) available to the application
for authentication- and EAD processing.
Paragraph (version B):
Obtain the authentication credential (CRED_I) and the
authentication key of I from the application (or by other means).
Paragraph (version A):
EAD_4 - protected external authorization data, see AD.  PAD
= 1*true is padding that may be used to hide the length of
the unpadded plaintext.
Paragraph (version B):
PAD = 1*true is padding that may be used to hide the length
of the unpadded plaintext.
Paragraph (version B):
EAD_4 - external authorization data, see AD.
Paragraph (version A):
Pass EAD_4 to the security application.
Paragraph (version B):
Make EAD_4 (if present) available to the application for EAD
processing.
Paragraph (version B):
There are many kinds of errors that can occur during EDHOC
processing.  As in CoAP, an error can be triggered by errors in the
received message or internal errors in the recieving endpoint.
Except for processing and formatting errors, it is up to the
implementation when to send an error message.  Sending error messages
is essential for debugging but MAY be skipped if, for example, a
session cannot be found or due to denial-of-service reasons, see dos.
Errors messages in EDHOC are always fatal.  After sending an error
message, the sender MUST discontinue the protocol.  The receiver
SHOULD treat an error message as an indication that the other party
likely has discontinued the protocol.  But as the error message is
not authenticated, a received error message might also have been sent
by an attacker and the receiver MAY therefore try to continue the
protocol.
Paragraph (version B):
As described in SIGMA, different levels of identity protection are
provided to the Initiator and the Responder.  EDHOC protects the
credential identifier of the Initiator against active attacks and the
credential identifier of the Responder against passive attacks.  An
active attacker can get the credential identifier of the Responder by
eavesdropping on the destination address used for transporting
message_1 and send its own message_1 to the same address.  The roles
should be assigned to protect the most sensitive identity/identifier,
typically that which is not possible to infer from routing
information in the lower layers.
Paragraph (version B):
External authorization data sent in message_1 (EAD_1) or message_2
(EAD_2) should be considered unprotected by EDHOC, see unprot-data.
EAD_2 is encrypted but the Responder has not yet authenticated the
Initiator.  External authorization data sent in message_3 (EAD_3) or
message_4 (EAD_4) is protected between Initiator and Responder by the
protocol, but note that EAD fields may be used by the application
before the message verification is completed, see AD.
Paragraph (version B):
So-called selfie attacks are mitigated as long as the Initiator does
not have its own identity in the set of Responder identities it is
allowed to communicate with.  In trust on first use (TOFU) use cases
the Initiator should verify that the the Responder's identity is not
equal to its own.  Any future EHDOC methods using e.g., pre-shared
keys might need to mitigate this in other ways.
Paragraph (version A):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.
Paragraph (version A):
The EDHOC MAC length MUST be at least 8 bytes and the tag length of
the EDHOC AEAD algorithm MUST be at least 64-bits.  Note that
secp256k1 is only defined for use with ECDSA and not for ECDH.  Note
that some COSE algorithms are marked as not recommended in the COSE
IANA registry.
Paragraph (version B):
The output size of the EDHOC hash algorithm MUST be at least
256-bits, i.e., the hash algorithms SHA-1 and SHA-256/64 (SHA-256
truncated to 64-bits) SHALL NOT be supported for use in EDHOC except
for certificate identification with x5t and c5t.  For security
considerations of SHA-1, see RFC6194.  As EDHOC integrity protects
the whole authentication credential, the choice of hash algorithm in
x5t and c5t does not affect security and it is RECOMMENDED to use the
same hash algorithm as in the cipher suite but with as much
truncation as possible, i.e, when the EDHOC hash algorithm is SHA-256
it is RECOMMENDED to use SHA-256/64 in x5t and c5t.  The EDHOC MAC
length MUST be at least 8 bytes and the tag length of the EDHOC AEAD
algorithm MUST be at least 64-bits.  Note that secp256k1 is only
defined for use with ECDSA and not for ECDH.  Note that some COSE
algorithms are marked as not recommended in the COSE IANA registry.
Paragraph (version B):
For many constrained IoT devices it is problematic to support several
crypto primitives.  Existing devices can be expected to support
either ECDSA or EdDSA.  If ECDSA is supported, "deterministic ECDSA"
as specified in RFC6979 MAY be used.  Pure deterministic elliptic-
curve signatures such as deterministic ECDSA and EdDSA have gained
popularity over randomized ECDSA as their security do not depend on a
source of high-quality randomness.  Recent research has however found
that implementations of these signature algorithms may be vulnerable
to certain side-channel and fault injection attacks due to their
determinism.  See e.g., Section 1 of I-D.mattsson-cfrg-det-sigs-with-
noise for a list of attack papers.  As suggested in Section 6.1.2 of
I-D.ietf-cose-rfc8152bis-algs this can be addressed by combining
randomness and determinism.
Paragraph (version A):
If two nodes unintentionally initiate two simultaneous EDHOC message
exchanges with each other even if they only want to complete a single
EDHOC message exchange, they MAY terminate the exchange with the
lexicographically smallest G_X.  If the two G_X values are equal, the
received message_1 MUST be discarded to mitigate reflection attacks.
Reflection attacks are not possible when the other endpoint's
identity is verified, but could be a problem with trust on first use
(TOFU) and future EHDOC methods using e.g., pre-shared keys.  Note
that in cases where several EDHOC exchanges with different parameter
sets (method, COSE headers, etc.) are used, an attacker can affect
which of the parameter sets that will be used by blocking some of the
parameter sets.
Paragraph (version A):
IANA has created a new registry entitled "EDHOC External
Authorization Data" under the new group name "Ephemeral Diffie-
Hellman Over COSE (EDHOC)".  The registration procedure is "Expert
Review".  The columns of the registry are Label, Description, and
Reference, where Label is an integer and the other columns are text
strings.
Paragraph (version B):
IANA has created a new registry entitled "EDHOC External
Authorization Data" under the new group name "Ephemeral Diffie-
Hellman Over COSE (EDHOC)".  The registration procedure is
"Specification Required".  The columns of the registry are Label,
Message, Description, and Reference, where Label is an integer and
the other columns are text strings.