Network Working Group M. Pala Internet-Draft CableLabs Intended status: Standards Track February 7, 2019 Expires: August 11, 2019 Credentials Provisioning and Management via EAP (EAP-CREDS) draft-pala-eap-creds-00 Abstract With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The .1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols. 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 August 11, 2019. Pala Expires August 11, 2019 [Page 1] Internet-Draft EAP-CREDS February 2019 Copyright Notice Copyright (c) 2019 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of existing solutions . . . . . . . . . . . . . . . 3 4. Scope Statement . . . . . . . . . . . . . . . . . . . . . . . 3 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . 4 6. EAP-CREDS Messages . . . . . . . . . . . . . . . . . . . . . 6 6.1. CREDS-Request . . . . . . . . . . . . . . . . . . . . . . 6 6.2. CREDS-Response . . . . . . . . . . . . . . . . . . . . . 6 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 6 8. EAP-CREDS as tunneled method . . . . . . . . . . . . . . . . 6 8.1. Using EAP-CREDS with EAP-TEAP . . . . . . . . . . . . . . 6 8.2. Using EAP-CREDS with EAP-TTLS . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Provisioning Protocols . . . . . . . . . . . . . . . . . 9 9.3. Token Types . . . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 12. Normative References . . . . . . . . . . . . . . . . . . . . 10 Appendix A. EAP-CREDS and CMP . . . . . . . . . . . . . . . . . 10 Appendix B. EAP-CREDS and EST . . . . . . . . . . . . . . . . . 11 Appendix C. EAP-CREDS and CMS . . . . . . . . . . . . . . . . . 11 Appendix D. EAP-CREDS and ACME . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Requirements notation 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 [RFC2119]. Pala Expires August 11, 2019 [Page 2] Internet-Draft EAP-CREDS February 2019 2. Introduction Many environments are, today, moving towards requiring strong authentication when it comes to gain access to networks. The .1x architecture provides the network administrators with the possibility to check credentials presented by a device even before providing any IP service to it. However, the provisioning and management of these credentials is a hard problem to solve and many vendors opt for long-lived credentials that can not be easily revoked, replaced, or simply renewed. This specification addresses the problem of providing a simple-to-use and simple-to-deploy system for credentials management by extending the EAP protocol to support credentials provisioning and management functionality. In particular, the EAP-CREDS method defined here provides a generic framework that can carry the messages for provisioning different types of credentials. The method can be use as a stand-alone method or it can be used as an inner method of EAP- TTLS or EAP-TEAP which can provide the required encryption and server-side authentication to deliver server-side generated secrets (e.g., private keys, passwords, secret keys, etc.) 3. Overview of existing solutions Currently there are many protocols that address the lifecycle of credentials. In particular, when it comes to digital certificates, some of the most deployed management protocols are: o Certificate Management Protocol (CMP) [RFC4210] o Certificate Management over CMS (CMC) [RFC5272][RFC6402] o Enrollment over Secure Transport (EST) [RFC7030] o Automated Certificate Management Environment However, none of these can be used without the client having IP connectivity. The EAP-CREDS fixes this issue by defining a series of messages that can be used to encapsulate the provisioning messages from the supported standard protocol. 4. Scope Statement This document focuses on the definition of the EAP-CREDS method to convey credentials provisioning and managing messages between the client and the AAA server. Moreover, the document defines how to encode messages for the main IETF provisioning protocols. Pala Expires August 11, 2019 [Page 3] Internet-Draft EAP-CREDS February 2019 This document, however, does not provide specifications for how and where the credentials are generated. In particular, the credentials could be generated directly within the AAA or at a different location (i.e., the Certificate Service Provider or CSP) site. Different authentication mechanisms (e.g., TLS, etc.) can be used to secure the communication between the server's endpoint and the CSP. 5. Protocol Overview This section outlines the generic protocol flow. Upon receiving the EAP-Response/Identity from the peer, 5.1. Message Flow Here we describe the main message flow. Pala Expires August 11, 2019 [Page 4] Internet-Draft EAP-CREDS February 2019 +------------+ +--------------+ | EAP Peer | | EAP Server | +------------+ +--------------+ | | |<----------- EAP-Request/Identity -| | | | | | |------------ EAP-Response/Identity -------------->| | (NAI=register@realm|NAI=manage@realm) | | | | | |<----------- EAP-Request/EAP-CREDS ---------------| | (Type=1,Vers,Supported Protocols, | | Providers,Capabilities,Profiles) | | | | | |------------ EAP-Response/EAP-CREDS ------------->| | (Type=1,Verp,Proto,Provider, | | Crypto,Profile,token, action) | | | | | |<----------- EAP-Request/EAP-CREDS ---------------| | (Type=2,Empty) | | | | | |------------ EAP-Response/EAP-CREDS ------------->| | (Type=2,ProtoData) | | | : : . . . . : : | | |<----------- EAP-Request/EAP-CREDS ---------------| | (Type=2,ProtoData) | | | | | |------------ EAP-Response/EAP-CREDS ------------->| | (Type=2,EMPTY) | | | | | |<----------- EAP-Success -------------------------| | | Pala Expires August 11, 2019 [Page 5] Internet-Draft EAP-CREDS February 2019 6. EAP-CREDS Messages The EAP-CREDS defines the following Messages: o CREDS-Request o CREDS-Response o CREDS-AuthToken o CREDS-Renew o CREDS-Revoke o CREDS-Scope 6.1. CREDS-Request Provides a description of the CREDS-Request TLV. 6.2. CREDS-Response Provides a description of the CREDS-Response TLV. 7. Error Handling 8. EAP-CREDS as tunneled method When no secrets have to be shared across the two parties, the EAP- CREDS method MAY be used as a stand-alone method for credentials provisioning and management. However, when secrets have to be shared, the EAP-CREDS method MUST be used as the inner method of EAP- TEAP, EAP-TTLS, or any other tunnelled method that provides, at minimum, server-side authentication and secrecy (encryption) to the subsequent method, i.e. EAP-CREDS. In other words, the method assumes that an appropriate protection outer layer has been established to prevent the possibility to leak information or to allow man-in-the-middle attacks. 8.1. Using EAP-CREDS with EAP-TEAP Pala Expires August 11, 2019 [Page 6] Internet-Draft EAP-CREDS February 2019 +--------+ +-------------+ | Client | | AAA | +--------+ +-------------+ | | | ClientHello | |------------------------>| | ServerHello, | | Certificate(1), | | ServerKeyExchange, | | CertificateRequest(2), | | ServerHelloDone, | |<------------------------| | Certificate(3), | | ClientKeyExchange, | | CertificateVerify, | | ChangeCipherSpec, | | Finished | |------------------------>| | ChangeCipherSpec, | | Finished | |<------------------------| // // // <---- EAP-CREDS ----> // // // | Crypto-Binding TLV | |<------------------------| | Crypto-Binding TLV | |------------------------>| | Result TLV | |<------------------------| | Result TLV | |------------------------>| | EAP-Success | |<------------------------| 8.2. Using EAP-CREDS with EAP-TTLS Pala Expires August 11, 2019 [Page 7] Internet-Draft EAP-CREDS February 2019 +--------+ +-------------+ | Client | | AAA | +--------+ +-------------+ | | | ClientHello | |------------------------>| | ServerHello, | | Certificate(1), | | ServerKeyExchange, | | CertificateRequest(2), | | ServerHelloDone, | |<------------------------| | Certificate(3), | | ClientKeyExchange, | | CertificateVerify, | | ChangeCipherSpec, | | Finished | |------------------------>| | ChangeCipherSpec, | | Finished | |<------------------------| : : // // // <---- EAP-CREDS ----> // // // : : | EAP-Success | |<------------------------| 9. IANA Considerations This document uses a new EAP type, EAP-CREDS, whose value (TBD) MUST be allocated by IANA from the EAP TYPEs subregistry of the RADIUS registry. This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP-CREDS protocol, in accordance with [RFC8126]. The EAP Method Type number for EAP-CREDS needs to be assigned. This document also requires IANA to create new registries as defined in the following subsections. 9.1. Message Types EAP-CREDS Request and Response pairs are identified by an integer Message Type. The following Message Types are defined by EAP-CREDS: Pala Expires August 11, 2019 [Page 8] Internet-Draft EAP-CREDS February 2019 +--------------+-----------------------------------------+ | Message Type | Purpose | +--------------+-----------------------------------------+ | 1 | Initialization | | 2 | Provisioning protocol messages exchange | +--------------+-----------------------------------------+ Table 1: EAP-CREDS Messages Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126]. 9.2. Provisioning Protocols +--------------+-------------+ | Message Type | Purpose | +--------------+-------------+ | 0 | Unspecified | | 1 | CMP | | 2 | EST | | 3 | CMC | | 4 | ACME | +--------------+-------------+ Table 2: EAP-CREDS Inner Protocol Identifiers Assignment of new values for new cryptosuites MUST be done through IANA with "Specification Required" and "IESG Approval" as defined in [RFC8126]. 9.3. Token Types +------------+-------------+ | Token Type | Description | +------------+-------------+ | 0 | Unspecified | | 1 | JWT | | 2 | OAuth1 | | 3 | OAuth2 | +------------+-------------+ Table 3: Token Types Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126]. Pala Expires August 11, 2019 [Page 9] Internet-Draft EAP-CREDS February 2019 10. Security Considerations Several security considerations need to be explicitly considered for the system administrators and application developers to understand the weaknesses of the overall architecture. 11. Acknowledgments The authors would like to thank everybody who provided insightful comments and helped in the definition of the deployment considerations. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Appendix A. EAP-CREDS and CMP Describe how to use EAP-CREDS with CMP. Pala Expires August 11, 2019 [Page 10] Internet-Draft EAP-CREDS February 2019 Appendix B. EAP-CREDS and EST Describe how to use EAP-CREDS with EST. Appendix C. EAP-CREDS and CMS Describe how to use EAP-CREDS with CMS. Appendix D. EAP-CREDS and ACME Describe how to use EAP-CREDS with ACME. Author's Address Massimiliano Pala CableLabs 858 Coal Creek Cir Louisville, CO 80027 US Email: m.pala@openca.org URI: http://www.linkedin.com/in/mpala Pala Expires August 11, 2019 [Page 11]