idnits 2.17.1 draft-ingles-radex-radius-edhoc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 5, 2020) is 1358 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ingles 3 Internet-Draft University of Murcia 4 Intended status: Experimental D. Garcia 5 Expires: February 6, 2021 Odin Solutions S.L. 6 R. Marin 7 University of Murcia 8 August 5, 2020 10 AAA-based assisted EDHOC Authentication 11 draft-ingles-radex-radius-edhoc-00 13 Abstract 15 This document describes a proposal to place EDHOC server in an 16 external Authentication, Authorization and Accounting (AAA) server. 17 The purpose is to centralize the EDHOC authentication in AAA 18 infrastructure. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 6, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. EDHOC support in AAA . . . . . . . . . . . . . . . . . . . . 3 57 3. EDHOC Overview . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. EDHOC protocol overview . . . . . . . . . . . . . . . . . 4 60 3.3. EDHOC key derivation . . . . . . . . . . . . . . . . . . 4 61 4. Integration Overview . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Mapping EDHOC entities to AAA infrastructure . . . . . . 5 63 4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . 5 65 4.4. EDHOC-message Attribute . . . . . . . . . . . . . . . . . 6 66 4.5. EDHOC-key attribute . . . . . . . . . . . . . . . . . . . 7 67 4.6. Table of Attribute . . . . . . . . . . . . . . . . . . . 8 68 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 EDHOC [I-D.selander-lake-edhoc] is a new protocol for autentication 80 and key derivation that has been proposed as an alternative in IoT 81 mainly due to two main characteristics, namely, it works on top of 82 any reliable transport, which means it can be carried over a protocol 83 such as CoAP and provides a secure exchange in an end-to-end fashion. 84 This key material can be futher used to run other protocols such as 85 OSCORE, as well as providing key material to any other protocol that 86 needs pre-shared key material to secure the communications. EDHOC 87 has another characteristic that makes it an interesting alternative 88 that is work underlining, it is designed to be lightweight, for which 89 is build using COSE, reducing the overhead of the protocol. The 90 proposal of this protocol coalesces with the advancement of the new 91 set of technologies known as LPWAN, which generally have high 92 constrains in the link, even more than traditional IoT networks. 93 Furthermore, these technologies generally lack in measurements for 94 refreshing the key material that is used to protect the 95 communications, for which methods to provide them with bootstrapping 96 and key management capabilities has been subject of reseach, as well 97 as extending the protocols provided to perform the joining of the 98 devices into the network. In this work we propose an architecture to 99 allow the EDHOC authentication being carried out with the assistance 100 of a AAA infraestructure. The motivation is to centralize not only 101 authentication but also authorization and accounting of a joining IoT 102 node to a particular domain. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2. EDHOC support in AAA 112 Regarding the overall functionality, AAA support for EDHOC will take 113 care of adapting AAA protocols, such as RADIUS or Diameter, to add 114 the support for EDHOC. An example of this could be with RADIUS. In 115 this instance, RADIUS support for EDHOC will define the new 116 Attributes needed to manage the protocol. The EDHOC server 117 implements the RADIUS client supporting this specification and 118 therefore, it MUST implement the RADIUS attributes for this service. 119 The NAS-Port-Type specifying the type of port on which the EDHOC 120 Server is authenticating the End-Device will be set according to the 121 technology used. For example, if we use LoRaWAN [LoRaWAN] we MAY set 122 it to 18 (Wireless - Other) or a new one specifically assigned for 123 LoRaWAN (TBD.). Similarly, the adaptation could be done for 124 Diameter. 126 3. EDHOC Overview 128 3.1. Introduction 130 EDHOC is a lightweight authenticated key exchange protocol that 131 enables to establish a cryptographic key between two entities. To 132 this end, EDHOC implements the Elliptic Curve Diffie-Hellman 133 algorithm with ephemeral keys (ECDHE), by which both entities must 134 generate a new ephemeral key pair every time they launch this 135 protocol. Therefore, EDHOC also provides the perfect forward secrecy 136 property. Additionally, EDHOC supports the same authentication modes 137 as DTLS (i.e., PSK, RPK, and certificates). Hence, the {key 138 generation} process remains independent concerning the selected 139 authentication mode. The EDHOC protocol defines a three-message 140 exchange. These messages are encoded following the CBOR 141 representation and are protected using COSE standard. This way, the 142 minimum message size is assured in contrast to other JSON-based 143 representation formats (such as JWS and JWE), therefore, reducing the 144 overhead on the network. EDHOC protects specific fields selectively 145 using COSE objects, ensuring end-to-end security, while intermediate 146 entities can access the information required to carry out their 147 functionality. 149 3.2. EDHOC protocol overview 151 The EDHOC specification defines an exchange of three messages. The 152 exact message content differs depending, if the authentication method 153 used is PSK, or of RPK or Certificates. The EDHOC client starts the 154 exchange sending the first message that includes the ephimeral public 155 key of the client. When this message arrives to the EDHOC server, it 156 generates it own ephemeral key pair and sends its public key to the 157 client in the second message. The client, then finishes the EDHOC 158 exchange sending the third message. 160 +--------+ +-------+ 161 | EDHOC | | EDHOC | 162 | Server | | Server| 163 +--------+ +-------+ 164 | | 165 | +------------------ EDHOC MSG 1 --------------------> | 166 | | 167 | <------------------ EDHOC MSG 2 --------------------+ | 168 | | 169 | +------------------ EDHOC MSG 3 --------------------> | 170 | | 171 | <----------+ Application Protected Data +-----------> | 172 + + 174 Figure 1: Overview EDHOC exchange 176 Each message of the EDHOC protocol is defined as a COSE object with 177 specific content depending on the message and the mode of 178 authentication, as specified in the document. 180 3.3. EDHOC key derivation 182 When the first message is received by the EDHOC server, it generates 183 its own ephemeral key pair and is able to compute the Secret, called 184 pseudorandom keys (PRK), as follows: 186 PRK = HKDF-Extract( salt, IKM ) 188 Upon receiving the last exchange both entites have a shared secret 189 key that is derived using a HDKF the input keying material (IKM): 190 Secret, Salt, Context and Key Length. The derivation is done in a 191 different way depending on the method used for authentication. 193 o The Secret is the same, since it is the result of the Ephemeral 194 Diffie-Hellman exchange as specified above. The Context. 196 o In case the it is done using PSK, the Salt is the PSK value, 197 otherwise the field is not used. 199 o The context is the COSE_KDF_CONTEXT defined in the protocol 201 o The key length is the lenght of the derived shared symetric key 202 that has to be at least 128-bits long. 204 According to the last version of the draft, there is a key derivation 205 hierarchy by which a Pseudorandom Key (PRK) is derived from the ECDH 206 shared secrets, and from the RPK additional key material called 207 output keying material (OKM) can be also derived. 209 4. Integration Overview 211 4.1. Mapping EDHOC entities to AAA infrastructure 213 In the current specification of EDHOC, there is no explicit reference 214 to an external entity to which the EDHOC Server can degate the 215 authentication. In this sense, we propose to add the support for 216 RADIUS to provide such delegation 218 4.2. Assumptions 220 For the integration of EDHOC with RADIUS next we describe some 221 assumptions. The first is that the credentials that are used for 222 authenticating the devices are only shared (in the case of PSK) 223 between the AAA server and the EDHOC client. The outcome of the 224 successful authentication (i.e. PRK) is sent from the AAA server to 225 the EDHOC server. This allows for the EDHOC client to exchange 226 messages with the EDHOC server, once the protocol is finished. 228 4.3. Protocol Exchange 230 The join procedure between the client and the server consists if 231 three messages. In RADIUS the EDHOC server implements a RADIUS 232 client to communicate with the AAA server. 234 The protocol exchange is done in the following steps: 236 1. The client sends the first message to the EDHOC server. 238 2. Upon reception of this message, the EDHOC server creates a RADIUS 239 Access-Request message, with the EDHOC-message attribute 240 containing all the fields of the first message of EDHOC. 242 3. Once the AAA server receives this message, performs the 243 processing of said message as the EDHOC server would in the 244 specification, generating in turn the message 2 and sendig it in 245 a new RADIUS Attribute EDHOC-message, embedded in an Access- 246 Challenge. 248 4. The EDHOC client, then processes the message and generates the 249 third EDHOC message. 251 5. The AAA server, receives the third EDHOC message and processes 252 it, deriving the PRK and generating and Access-Accept for the 253 EDHOC server that contains the key in an EDHOC-key attribute. 255 +------------+ +-----------+ +-----------+ 256 | AAA | | EDHOC | | AAA | 257 | Client | | Server | | Server | 258 +------+-----+ +-----+-----+ +-----+-----+ 259 | EDHOC MSG 1 | Access-Request | 260 +------------------>+ EDHOC-message Att | 261 | +------------------->+ 262 | | | 263 | | Access-Challenge | 264 | | EDHOC-message Att | 265 | EDHOC MSG 2 +<-------------------+ 266 +<------------------+ | 267 | | | 268 | EDHOC MSG 3 | Access-Request | 269 +------------------>+ EDHOC-message Att | 270 | +------------------->+ 271 | | | 272 | | Access-Accept | 273 | | EDHOC-key(PRK) | 274 + +<-------------------+ 276 Figure 2: EDHOC-AAA exchange 278 4.4. EDHOC-message Attribute 280 Description 282 This Attribute contains the original EDHOC messages. This attribute 283 will appear in the Access-Request and Access-Challenge messages. A 284 summary of the EDHOC-message attribute format is shown below. The 285 fields are transmitted from left to right. 287 0 1 2 288 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Length | String... 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Type 295 TBD. for EDHOC-message 297 Length 299 >= 3 301 String 303 The String field contains an EDHOC message. 305 The String field contains an octet string with the Join-Request 306 message as received over the network, such as defined in [LoRaWAN]. 308 4.5. EDHOC-key attribute 310 Description 312 This Attribute contains the EDHOC PRK, a shared secret key specific 313 for the EDHOC client. This attribute only appears in the RADIUS 314 Access-Accept message. A summary of the EDHOC-key attribute format 315 is shown below. The fields are transmitted from left to right. 317 0 1 2 318 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | String... 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Type 325 TBD. for EDHOC-key 327 Length 329 >= 16 331 String 332 The String field contains an EDHOC shared symmetric key. 334 4.6. Table of Attribute 336 Request Accept Reject Challenge # Attribute 337 1 0 0 1 TBD. EDHOC-message 338 0 1 0 0 TBD. EDHOC-key 339 Request Accept Reject Challenge # Attribute 341 Figure 3: Attributes Table 343 5. Open Issues 345 A specification can be considered about the way credentials are 346 identified in EDHOC to support federation. According to the EDHOC 347 draft, the credentials are identified by each communication endpoing 348 by a 'kid'. We propose that this value will contain a network access 349 identifier, that will be used to retreive the credentials in both the 350 symmetric asymmetric keys. This value is extracted, it is passed to 351 a textual form to include it in an AAA attribute (e.g. User-Name in 352 RADIUS) to be routed to the appropiate server. 354 6. Security Considerations 356 The security considerations of this proposal inherit the same 357 security considerations of EDHOC. TBD. 359 7. Acknowledgements 361 This work is possible due the EU Project IoTCrawlwer under grant 362 agreement n. 779852 and to the pre-doctoral grant Industrial PhD DI- 363 16-08432 granted to ODIN Solutions S.L 365 8. IANA Considerations 367 In this document we define 2 new RADIUS Attributes that would need 368 actions from IANA to assign the corresponding numbers. 370 +--------+---------------+----------------------------+ 371 | Number | Name | Reference | 372 +------------------------+----------------------------+ 373 | TBD | EDHOC-message | Section 4 of this document | 374 | TBD | EDHOC-key | Section 4 of this document | 375 +--------+---------------+----------------------------+ 377 9. References 379 9.1. Normative References 381 [I-D.selander-lake-edhoc] 382 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 383 Diffie-Hellman Over COSE (EDHOC)", draft-selander-lake- 384 edhoc-01 (work in progress), March 2020. 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 9.2. Informative References 393 [LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa 394 Specification V1.0", January 2015, . 398 Authors' Addresses 400 Eduardo Ingles Sanchez 401 University of Murcia 402 Campus de Espinardo S/N, Faculty of Computer Science 403 Murcia 30100 404 Spain 406 Email: eduardo.ingles@um.es 407 Dan Garcia Carrillo 408 Odin Solutions S.L. 409 Poligono Industrial Oeste, C/ Peru, 5 410 Alcantarilla, Murcia 30820 411 Spain 413 Email: dgarcia@odins.es 415 Rafael Marin-Lopez 416 University of Murcia 417 Campus de Espinardo S/N, Faculty of Computer Science 418 Murcia 30100 419 Spain 421 Phone: +34 868 88 85 01 422 Email: rafa@um.es