Credentials Provisioning and Management via EAP (EAP-CREDS)
draft-pala-eap-creds-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Massimiliano Pala | ||
| Last updated | 2019-02-07 | ||
| Replaced by | draft-pala-tian-eap-creds | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pala-eap-creds-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/info/rfc6402>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
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]