| Network Working Group | E. Ingles |
| Internet-Draft | University of Murcia |
| Intended status: Experimental | D. Garcia |
| Expires: February 6, 2021 | Odin Solutions S.L. |
| R. Marin | |
| University of Murcia | |
| August 5, 2020 |
AAA-based assisted EDHOC Authentication
draft-ingles-radex-radius-edhoc-00
This document describes a proposal to place EDHOC server in an external Authentication, Authorization and Accounting (AAA) server. The purpose is to centralize the EDHOC authentication in AAA infrastructure.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
EDHOC [I-D.selander-lake-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 [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 | | EDHOC |
| Server | | Server|
+--------+ +-------+
| |
| +------------------ EDHOC MSG 1 --------------------> |
| |
| <------------------ EDHOC MSG 2 --------------------+ |
| |
| +------------------ EDHOC MSG 3 --------------------> |
| |
| <----------+ Application Protected Data +-----------> |
+ +
Figure 1: Overview EDHOC exchange
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.
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:
+------------+ +-----------+ +-----------+
| AAA | | EDHOC | | AAA |
| Client | | Server | | Server |
+------+-----+ +-----+-----+ +-----+-----+
| EDHOC MSG 1 | Access-Request |
+------------------>+ EDHOC-message Att |
| +------------------->+
| | |
| | Access-Challenge |
| | EDHOC-message Att |
| EDHOC MSG 2 +<-------------------+
+<------------------+ |
| | |
| EDHOC MSG 3 | Access-Request |
+------------------>+ EDHOC-message Att |
| +------------------->+
| | |
| | Access-Accept |
| | EDHOC-key(PRK) |
+ +<-------------------+
Figure 2: EDHOC-AAA exchange
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.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD. for EDHOC-message
Length
>= 3
String
The String field contains an EDHOC message.
Description
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD. for EDHOC-key Length >= 16 String The String field contains an EDHOC shared symmetric key.
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.
Request Accept Reject Challenge # Attribute 1 0 0 1 TBD. EDHOC-message 0 1 0 0 TBD. EDHOC-key Request Accept Reject Challenge # Attribute
Figure 3: Attributes Table
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
+--------+---------------+----------------------------+
| Number | Name | Reference |
+------------------------+----------------------------+
| TBD | EDHOC-message | Section 4 of this document |
| TBD | EDHOC-key | Section 4 of this document |
+--------+---------------+----------------------------+
In this document we define 2 new RADIUS Attributes that would need actions from IANA to assign the corresponding numbers.
| [I-D.selander-lake-edhoc] | Selander, G., Mattsson, J. and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Internet-Draft draft-selander-lake-edhoc-01, March 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [LoRaWAN] | Sornin, N., Luis, M., Eirich, T. and T. Kramp, "LoRa Specification V1.0", January 2015. |