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.

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. Introduction
• 3. Overview of existing solutions
• 4. Scope Statement
• 5. Protocol Overview
• 5.1. Message Flow
• 6. EAP-CREDS Messages
• 6.1. CREDS-Request
• 6.2. CREDS-Response
• 7. Error Handling
• 8. EAP-CREDS as tunneled method
• 8.1. Using EAP-CREDS with EAP-TEAP
• 8.2. Using EAP-CREDS with EAP-TTLS
• 9. IANA Considerations
• 9.1. Message Types
• 9.2. Provisioning Protocols
• 9.3. Token Types
• 10. Security Considerations
• 11. Acknowledgments
• 12. Normative References
• Appendix A. EAP-CREDS and CMP
• Appendix B. EAP-CREDS and EST
• Appendix C. EAP-CREDS and CMS
• Appendix D. EAP-CREDS and ACME
• Author's Address

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].

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:

• Certificate Management Protocol (CMP) [RFC4210]
• Certificate Management over CMS (CMC) [RFC5272][RFC6402]
• Enrollment over Secure Transport (EST) [RFC7030]
• 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.

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.

 +------------+                                  +--------------+
 |  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 -------------------------|
      |                                                  |

6. EAP-CREDS Messages

The EAP-CREDS defines the following Messages:

• CREDS-Request
• CREDS-Response
• CREDS-AuthToken
• CREDS-Renew
• CREDS-Revoke
• 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

   +--------+             +-------------+
   | 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

   +--------+             +-------------+
   | 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:

Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].

9.2. Provisioning Protocols

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

Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].

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

Appendix A. EAP-CREDS and CMP

Describe how to use EAP-CREDS with CMP.

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