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 Abstract 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. Status of This Memo 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 Notice 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 Ingles, et al. Expires February 6, 2021 [Page 1] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. EDHOC support in AAA . . . . . . . . . . . . . . . . . . . . 3 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 3.2. EDHOC protocol overview . . . . . . . . . . . . . . . . . 4 3.3. EDHOC key derivation . . . . . . . . . . . . . . . . . . 4 4. Integration Overview . . . . . . . . . . . . . . . . . . . . 5 4.1. Mapping EDHOC entities to AAA infrastructure . . . . . . 5 4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . 5 4.4. EDHOC-message Attribute . . . . . . . . . . . . . . . . . 6 4.5. EDHOC-key attribute . . . . . . . . . . . . . . . . . . . 7 4.6. Table of Attribute . . . . . . . . . . . . . . . . . . . 8 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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 Ingles, et al. Expires February 6, 2021 [Page 2] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 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. 1.1. Requirements Language 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 [RFC2119]. 2. EDHOC support in AAA 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. 3. EDHOC Overview 3.1. Introduction 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 Ingles, et al. Expires February 6, 2021 [Page 3] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 using COSE objects, ensuring end-to-end security, while intermediate entities can access the information required to carry out their functionality. 3.2. EDHOC protocol overview 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. 3.3. EDHOC key derivation 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. Ingles, et al. Expires February 6, 2021 [Page 4] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 o The Secret is the same, since it is the result of the Ephemeral Diffie-Hellman exchange as specified above. The Context. o In case the it is done using PSK, the Salt is the PSK value, otherwise the field is not used. o The context is the COSE_KDF_CONTEXT defined in the protocol o 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. 4. Integration Overview 4.1. Mapping EDHOC entities to AAA infrastructure 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 4.2. Assumptions 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. 4.3. Protocol Exchange 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: 1. The client sends the first message to the EDHOC server. 2. 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. Ingles, et al. Expires February 6, 2021 [Page 5] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 3. 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. 4. The EDHOC client, then processes the message and generates the third EDHOC message. 5. 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. +------------+ +-----------+ +-----------+ | 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 4.4. EDHOC-message 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. Ingles, et al. Expires February 6, 2021 [Page 6] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 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. The String field contains an octet string with the Join-Request message as received over the network, such as defined in [LoRaWAN]. 4.5. EDHOC-key attribute 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. Ingles, et al. Expires February 6, 2021 [Page 7] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 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. 4.6. Table of Attribute 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 5. Open Issues 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. 6. Security Considerations The security considerations of this proposal inherit the same security considerations of EDHOC. TBD. Ingles, et al. Expires February 6, 2021 [Page 8] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 7. Acknowledgements 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 8. IANA Considerations In this document we define 2 new RADIUS Attributes that would need actions from IANA to assign the corresponding numbers. +--------+---------------+----------------------------+ | Number | Name | Reference | +------------------------+----------------------------+ | TBD | EDHOC-message | Section 4 of this document | | TBD | EDHOC-key | Section 4 of this document | +--------+---------------+----------------------------+ 9. References 9.1. Normative References [I-D.selander-lake-edhoc] Selander, G., Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", draft-selander-lake- edhoc-01 (work in progress), 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, . 9.2. Informative References [LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa Specification V1.0", January 2015, . Authors' Addresses Eduardo Ingles Sanchez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain Email: eduardo.ingles@um.es Ingles, et al. Expires February 6, 2021 [Page 9] Internet-Draft draft-ingles-radex-radius-edhoc-00 August 2020 Dan Garcia Carrillo Odin Solutions S.L. Poligono Industrial Oeste, C/ Peru, 5 Alcantarilla, Murcia 30820 Spain Email: dgarcia@odins.es Rafael Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain Phone: +34 868 88 85 01 Email: rafa@um.es Ingles, et al. Expires February 6, 2021 [Page 10]