idnits 2.17.1 draft-pala-eap-creds-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 (February 7, 2019) is 1876 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) 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 M. Pala 3 Internet-Draft CableLabs 4 Intended status: Standards Track February 7, 2019 5 Expires: August 11, 2019 7 Credentials Provisioning and Management via EAP (EAP-CREDS) 8 draft-pala-eap-creds-00 10 Abstract 12 With the increase number of devices, protocols, and applications that 13 rely on strong credentials (e.g., digital certificates, keys, or 14 tokens) for network access, the need for a standardized credentials 15 provisioning and management framework is paramount. The .1x 16 architecture allows for entities (e.g., devices, applications, etc.) 17 to authenticate to the network by providing a communication channel 18 where different methods can be used to exchange different types of 19 credentials. However, the need for managing these credentials (i.e., 20 provisioning and renewal) is still a hard problem to solve. 22 This specifications define how to support the provisioning and 23 management of authentication credentials that can be exploited in 24 different environments (e.g., Wired, WiFi, cellular, etc.) to users 25 and/or devices by using EAP together with standard provisioning 26 protocols. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 11, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of existing solutions . . . . . . . . . . . . . . . 3 65 4. Scope Statement . . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . 4 68 6. EAP-CREDS Messages . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. CREDS-Request . . . . . . . . . . . . . . . . . . . . . . 6 70 6.2. CREDS-Response . . . . . . . . . . . . . . . . . . . . . 6 71 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 6 72 8. EAP-CREDS as tunneled method . . . . . . . . . . . . . . . . 6 73 8.1. Using EAP-CREDS with EAP-TEAP . . . . . . . . . . . . . . 6 74 8.2. Using EAP-CREDS with EAP-TTLS . . . . . . . . . . . . . . 7 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 9.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 8 77 9.2. Provisioning Protocols . . . . . . . . . . . . . . . . . 9 78 9.3. Token Types . . . . . . . . . . . . . . . . . . . . . . . 9 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 12. Normative References . . . . . . . . . . . . . . . . . . . . 10 82 Appendix A. EAP-CREDS and CMP . . . . . . . . . . . . . . . . . 10 83 Appendix B. EAP-CREDS and EST . . . . . . . . . . . . . . . . . 11 84 Appendix C. EAP-CREDS and CMS . . . . . . . . . . . . . . . . . 11 85 Appendix D. EAP-CREDS and ACME . . . . . . . . . . . . . . . . . 11 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 Many environments are, today, moving towards requiring strong 97 authentication when it comes to gain access to networks. The .1x 98 architecture provides the network administrators with the possibility 99 to check credentials presented by a device even before providing any 100 IP service to it. 102 However, the provisioning and management of these credentials is a 103 hard problem to solve and many vendors opt for long-lived credentials 104 that can not be easily revoked, replaced, or simply renewed. 106 This specification addresses the problem of providing a simple-to-use 107 and simple-to-deploy system for credentials management by extending 108 the EAP protocol to support credentials provisioning and management 109 functionality. In particular, the EAP-CREDS method defined here 110 provides a generic framework that can carry the messages for 111 provisioning different types of credentials. The method can be use 112 as a stand-alone method or it can be used as an inner method of EAP- 113 TTLS or EAP-TEAP which can provide the required encryption and 114 server-side authentication to deliver server-side generated secrets 115 (e.g., private keys, passwords, secret keys, etc.) 117 3. Overview of existing solutions 119 Currently there are many protocols that address the lifecycle of 120 credentials. In particular, when it comes to digital certificates, 121 some of the most deployed management protocols are: 123 o Certificate Management Protocol (CMP) [RFC4210] 125 o Certificate Management over CMS (CMC) [RFC5272][RFC6402] 127 o Enrollment over Secure Transport (EST) [RFC7030] 129 o Automated Certificate Management Environment 131 However, none of these can be used without the client having IP 132 connectivity. The EAP-CREDS fixes this issue by defining a series of 133 messages that can be used to encapsulate the provisioning messages 134 from the supported standard protocol. 136 4. Scope Statement 138 This document focuses on the definition of the EAP-CREDS method to 139 convey credentials provisioning and managing messages between the 140 client and the AAA server. Moreover, the document defines how to 141 encode messages for the main IETF provisioning protocols. 143 This document, however, does not provide specifications for how and 144 where the credentials are generated. In particular, the credentials 145 could be generated directly within the AAA or at a different location 146 (i.e., the Certificate Service Provider or CSP) site. Different 147 authentication mechanisms (e.g., TLS, etc.) can be used to secure the 148 communication between the server's endpoint and the CSP. 150 5. Protocol Overview 152 This section outlines the generic protocol flow. Upon receiving the 153 EAP-Response/Identity from the peer, 155 5.1. Message Flow 157 Here we describe the main message flow. 159 +------------+ +--------------+ 160 | EAP Peer | | EAP Server | 161 +------------+ +--------------+ 162 | | 163 |<----------- EAP-Request/Identity -| | 164 | | 165 | | 166 |------------ EAP-Response/Identity -------------->| 167 | (NAI=register@realm|NAI=manage@realm) | 168 | | 169 | | 170 |<----------- EAP-Request/EAP-CREDS ---------------| 171 | (Type=1,Vers,Supported Protocols, | 172 | Providers,Capabilities,Profiles) | 173 | | 174 | | 175 |------------ EAP-Response/EAP-CREDS ------------->| 176 | (Type=1,Verp,Proto,Provider, | 177 | Crypto,Profile,token, action) | 178 | | 179 | | 180 |<----------- EAP-Request/EAP-CREDS ---------------| 181 | (Type=2,Empty) | 182 | | 183 | | 184 |------------ EAP-Response/EAP-CREDS ------------->| 185 | (Type=2,ProtoData) | 186 | | 187 : : 188 . . 190 . . 191 : : 192 | | 193 |<----------- EAP-Request/EAP-CREDS ---------------| 194 | (Type=2,ProtoData) | 195 | | 196 | | 197 |------------ EAP-Response/EAP-CREDS ------------->| 198 | (Type=2,EMPTY) | 199 | | 200 | | 201 |<----------- EAP-Success -------------------------| 202 | | 204 6. EAP-CREDS Messages 206 The EAP-CREDS defines the following Messages: 208 o CREDS-Request 210 o CREDS-Response 212 o CREDS-AuthToken 214 o CREDS-Renew 216 o CREDS-Revoke 218 o CREDS-Scope 220 6.1. CREDS-Request 222 Provides a description of the CREDS-Request TLV. 224 6.2. CREDS-Response 226 Provides a description of the CREDS-Response TLV. 228 7. Error Handling 230 8. EAP-CREDS as tunneled method 232 When no secrets have to be shared across the two parties, the EAP- 233 CREDS method MAY be used as a stand-alone method for credentials 234 provisioning and management. However, when secrets have to be 235 shared, the EAP-CREDS method MUST be used as the inner method of EAP- 236 TEAP, EAP-TTLS, or any other tunnelled method that provides, at 237 minimum, server-side authentication and secrecy (encryption) to the 238 subsequent method, i.e. EAP-CREDS. In other words, the method 239 assumes that an appropriate protection outer layer has been 240 established to prevent the possibility to leak information or to 241 allow man-in-the-middle attacks. 243 8.1. Using EAP-CREDS with EAP-TEAP 244 +--------+ +-------------+ 245 | Client | | AAA | 246 +--------+ +-------------+ 247 | | 248 | ClientHello | 249 |------------------------>| 250 | ServerHello, | 251 | Certificate(1), | 252 | ServerKeyExchange, | 253 | CertificateRequest(2), | 254 | ServerHelloDone, | 255 |<------------------------| 256 | Certificate(3), | 257 | ClientKeyExchange, | 258 | CertificateVerify, | 259 | ChangeCipherSpec, | 260 | Finished | 261 |------------------------>| 262 | ChangeCipherSpec, | 263 | Finished | 264 |<------------------------| 265 // // 266 // <---- EAP-CREDS ----> // 267 // // 268 | Crypto-Binding TLV | 269 |<------------------------| 270 | Crypto-Binding TLV | 271 |------------------------>| 272 | Result TLV | 273 |<------------------------| 274 | Result TLV | 275 |------------------------>| 276 | EAP-Success | 277 |<------------------------| 279 8.2. Using EAP-CREDS with EAP-TTLS 280 +--------+ +-------------+ 281 | Client | | AAA | 282 +--------+ +-------------+ 283 | | 284 | ClientHello | 285 |------------------------>| 286 | ServerHello, | 287 | Certificate(1), | 288 | ServerKeyExchange, | 289 | CertificateRequest(2), | 290 | ServerHelloDone, | 291 |<------------------------| 292 | Certificate(3), | 293 | ClientKeyExchange, | 294 | CertificateVerify, | 295 | ChangeCipherSpec, | 296 | Finished | 297 |------------------------>| 298 | ChangeCipherSpec, | 299 | Finished | 300 |<------------------------| 301 : : 302 // // 303 // <---- EAP-CREDS ----> // 304 // // 305 : : 306 | EAP-Success | 307 |<------------------------| 309 9. IANA Considerations 311 This document uses a new EAP type, EAP-CREDS, whose value (TBD) MUST 312 be allocated by IANA from the EAP TYPEs subregistry of the RADIUS 313 registry. This section provides guidance to the Internet Assigned 314 Numbers Authority (IANA) regarding registration of values related to 315 the EAP-CREDS protocol, in accordance with [RFC8126]. 317 The EAP Method Type number for EAP-CREDS needs to be assigned. 319 This document also requires IANA to create new registries as defined 320 in the following subsections. 322 9.1. Message Types 324 EAP-CREDS Request and Response pairs are identified by an integer 325 Message Type. The following Message Types are defined by EAP-CREDS: 327 +--------------+-----------------------------------------+ 328 | Message Type | Purpose | 329 +--------------+-----------------------------------------+ 330 | 1 | Initialization | 331 | 2 | Provisioning protocol messages exchange | 332 +--------------+-----------------------------------------+ 334 Table 1: EAP-CREDS Messages 336 Assignment of new values for new Message Types MUST be done through 337 IANA with "Expert Review" as defined in [RFC8126]. 339 9.2. Provisioning Protocols 341 +--------------+-------------+ 342 | Message Type | Purpose | 343 +--------------+-------------+ 344 | 0 | Unspecified | 345 | 1 | CMP | 346 | 2 | EST | 347 | 3 | CMC | 348 | 4 | ACME | 349 +--------------+-------------+ 351 Table 2: EAP-CREDS Inner Protocol Identifiers 353 Assignment of new values for new cryptosuites MUST be done through 354 IANA with "Specification Required" and "IESG Approval" as defined in 355 [RFC8126]. 357 9.3. Token Types 359 +------------+-------------+ 360 | Token Type | Description | 361 +------------+-------------+ 362 | 0 | Unspecified | 363 | 1 | JWT | 364 | 2 | OAuth1 | 365 | 3 | OAuth2 | 366 +------------+-------------+ 368 Table 3: Token Types 370 Assignment of new values for new Message Types MUST be done through 371 IANA with "Expert Review" as defined in [RFC8126]. 373 10. Security Considerations 375 Several security considerations need to be explicitly considered for 376 the system administrators and application developers to understand 377 the weaknesses of the overall architecture. 379 11. Acknowledgments 381 The authors would like to thank everybody who provided insightful 382 comments and helped in the definition of the deployment 383 considerations. 385 12. Normative References 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, 389 DOI 10.17487/RFC2119, March 1997, 390 . 392 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 393 "Internet X.509 Public Key Infrastructure Certificate 394 Management Protocol (CMP)", RFC 4210, 395 DOI 10.17487/RFC4210, September 2005, 396 . 398 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 399 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 400 . 402 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 403 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 404 . 406 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 407 "Enrollment over Secure Transport", RFC 7030, 408 DOI 10.17487/RFC7030, October 2013, 409 . 411 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 412 Writing an IANA Considerations Section in RFCs", BCP 26, 413 RFC 8126, DOI 10.17487/RFC8126, June 2017, 414 . 416 Appendix A. EAP-CREDS and CMP 418 Describe how to use EAP-CREDS with CMP. 420 Appendix B. EAP-CREDS and EST 422 Describe how to use EAP-CREDS with EST. 424 Appendix C. EAP-CREDS and CMS 426 Describe how to use EAP-CREDS with CMS. 428 Appendix D. EAP-CREDS and ACME 430 Describe how to use EAP-CREDS with ACME. 432 Author's Address 434 Massimiliano Pala 435 CableLabs 436 858 Coal Creek Cir 437 Louisville, CO 80027 438 US 440 Email: m.pala@openca.org 441 URI: http://www.linkedin.com/in/mpala