AAA-based assisted EDHOC Authentication

EDHOC is a new protocol for autentication and key derivation that has been proposed as an alternative in IoT mainly due to two main characteristics, namely, it works on top of any reliable transport, which means it can be carried over a protocol such as CoAP and provides a secure exchange in an end-to-end fashion. This key material can be futher used to run other protocols such as OSCORE, as well as providing key material to any other protocol that needs pre-shared key material to secure the communications. EDHOC has another characteristic that makes it an interesting alternative that is work underlining, it is designed to be lightweight, for which is build using COSE, reducing the overhead of the protocol. The proposal of this protocol coalesces with the advancement of the new set of technologies known as LPWAN, which generally have high constrains in the link, even more than traditional IoT networks. Furthermore, these technologies generally lack in measurements for refreshing the key material that is used to protect the communications, for which methods to provide them with bootstrapping and key management capabilities has been subject of reseach, as well as extending the protocols provided to perform the joining of the devices into the network. In this work we propose an architecture to allow the EDHOC authentication being carried out with the assistance of a AAA infraestructure. The motivation is to centralize not only authentication but also authorization and accounting of a joining IoT node to a particular domain.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Regarding the overall functionality, AAA support for EDHOC will take care of adapting AAA protocols, such as RADIUS or Diameter, to add the support for EDHOC. An example of this could be with RADIUS. In this instance, RADIUS support for EDHOC will define the new Attributes needed to manage the protocol. The EDHOC server implements the RADIUS client supporting this specification and therefore, it MUST implement the RADIUS attributes for this service. The NAS-Port-Type specifying the type of port on which the EDHOC Server is authenticating the End-Device will be set according to the technology used. For example, if we use LoRaWAN we MAY set it to 18 (Wireless - Other) or a new one specifically assigned for LoRaWAN (TBD.). Similarly, the adaptation could be done for Diameter.

EDHOC is a lightweight authenticated key exchange protocol that enables to establish a cryptographic key between two entities. To this end, EDHOC implements the Elliptic Curve Diffie-Hellman algorithm with ephemeral keys (ECDHE), by which both entities must generate a new ephemeral key pair every time they launch this protocol. Therefore, EDHOC also provides the perfect forward secrecy property. Additionally, EDHOC supports the same authentication modes as DTLS (i.e., PSK, RPK, and certificates). Hence, the {key generation} process remains independent concerning the selected authentication mode. The EDHOC protocol defines a three-message exchange. These messages are encoded following the CBOR representation and are protected using COSE standard. This way, the minimum message size is assured in contrast to other JSON-based representation formats (such as JWS and JWE), therefore, reducing the overhead on the network. EDHOC protects specific fields selectively using COSE objects, ensuring end-to-end security, while intermediate entities can access the information required to carry out their functionality.

The EDHOC specification defines an exchange of three messages. The exact message content differs depending, if the authentication method used is PSK, or of RPK or Certificates. The EDHOC client starts the exchange sending the first message that includes the ephimeral public key of the client. When this message arrives to the EDHOC server, it generates it own ephemeral key pair and sends its public key to the client in the second message. The client, then finishes the EDHOC exchange sending the third message.

| | | | <------------------ EDHOC MSG 2 --------------------+ | | | | +------------------ EDHOC MSG 3 --------------------> | | | | <----------+ Application Protected Data +-----------> | + + ]]> Each message of the EDHOC protocol is defined as a COSE object with specific content depending on the message and the mode of authentication, as specified in the document.

When the first message is received by the EDHOC server, it generates its own ephemeral key pair and is able to compute the Secret, called pseudorandom keys (PRK), as follows: PRK = HKDF-Extract( salt, IKM ) Upon receiving the last exchange both entites have a shared secret key that is derived using a HDKF the input keying material (IKM): Secret, Salt, Context and Key Length. The derivation is done in a different way depending on the method used for authentication. The Secret is the same, since it is the result of the Ephemeral Diffie-Hellman exchange as specified above. The Context. In case the it is done using PSK, the Salt is the PSK value, otherwise the field is not used. The context is the COSE_KDF_CONTEXT defined in the protocol The key length is the lenght of the derived shared symetric key that has to be at least 128-bits long. According to the last version of the draft, there is a key derivation hierarchy by which a Pseudorandom Key (PRK) is derived from the ECDH shared secrets, and from the RPK additional key material called output keying material (OKM) can be also derived.

In the current specification of EDHOC, there is no explicit reference to an external entity to which the EDHOC Server can degate the authentication. In this sense, we propose to add the support for RADIUS to provide such delegation

For the integration of EDHOC with RADIUS next we describe some assumptions. The first is that the credentials that are used for authenticating the devices are only shared (in the case of PSK) between the AAA server and the EDHOC client. The outcome of the successful authentication (i.e. PRK) is sent from the AAA server to the EDHOC server. This allows for the EDHOC client to exchange messages with the EDHOC server, once the protocol is finished.

The join procedure between the client and the server consists if three messages. In RADIUS the EDHOC server implements a RADIUS client to communicate with the AAA server. The protocol exchange is done in the following steps: The client sends the first message to the EDHOC server. Upon reception of this message, the EDHOC server creates a RADIUS Access-Request message, with the EDHOC-message attribute containing all the fields of the first message of EDHOC. Once the AAA server receives this message, performs the processing of said message as the EDHOC server would in the specification, generating in turn the message 2 and sendig it in a new RADIUS Attribute EDHOC-message, embedded in an Access-Challenge. The EDHOC client, then processes the message and generates the third EDHOC message. The AAA server, receives the third EDHOC message and processes it, deriving the PRK and generating and Access-Accept for the EDHOC server that contains the key in an EDHOC-key attribute.

Description This Attribute contains the original EDHOC messages. This attribute will appear in the Access-Request and Access-Challenge messages. A summary of the EDHOC-message attribute format is shown below. The fields are transmitted from left to right.

= 3 String The String field contains an EDHOC message. ]]> The String field contains an octet string with the Join-Request message as received over the network, such as defined in .

Description This Attribute contains the EDHOC PRK, a shared secret key specific for the EDHOC client. This attribute only appears in the RADIUS Access-Accept message. A summary of the EDHOC-key attribute format is shown below. The fields are transmitted from left to right.

= 16 String The String field contains an EDHOC shared symmetric key. ]]>

A specification can be considered about the way credentials are identified in EDHOC to support federation. According to the EDHOC draft, the credentials are identified by each communication endpoing by a 'kid'. We propose that this value will contain a network access identifier, that will be used to retreive the credentials in both the symmetric asymmetric keys. This value is extracted, it is passed to a textual form to include it in an AAA attribute (e.g. User-Name in RADIUS) to be routed to the appropiate server.

The security considerations of this proposal inherit the same security considerations of EDHOC. TBD.

This work is possible due the EU Project IoTCrawlwer under grant agreement n. 779852 and to the pre-doctoral grant Industrial PhD DI-16-08432 granted to ODIN Solutions S.L

In this document we define 2 new RADIUS Attributes that would need actions from IANA to assign the corresponding numbers.