Network Working Group M. Pala
Internet-Draft CableLabs
Intended status: Standards Track June 1, 2019
Expires: December 3, 2019
Credentials Provisioning and Management via EAP (EAP-CREDS)
draft-pala-eap-creds-01
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 December 3, 2019.
Pala Expires December 3, 2019 [Page 1]
Internet-Draft EAP-CREDS June 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 . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of existing solutions . . . . . . . . . . . . . . . 4
4. Scope Statement . . . . . . . . . . . . . . . . . . . . . . . 4
5. EAP-CREDS Protocol . . . . . . . . . . . . . . . . . . . . . 5
5.1. EAP-CREDS as tunneled mechanism only . . . . . . . . . . 5
5.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Phase One: Initialization . . . . . . . . . . . . . . . . 6
5.4. Phase Two: Provisioning . . . . . . . . . . . . . . . . . 7
5.5. Phase Three: Validation . . . . . . . . . . . . . . . . . 8
6. EAP-CREDS Message Format . . . . . . . . . . . . . . . . . . 10
6.1. Message Header . . . . . . . . . . . . . . . . . . . . . 10
6.2. Message Payload . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. General TLV format . . . . . . . . . . . . . . . . . 11
6.2.2. EAP-CREDS defined TLVs . . . . . . . . . . . . . . . 12
6.2.2.1. The Protocol TLV . . . . . . . . . . . . . . . . 13
6.2.2.2. The Profiles TLV . . . . . . . . . . . . . . . . 13
6.2.2.3. The CredInfo TLV . . . . . . . . . . . . . . . . 13
6.2.2.4. The AuthToken TLV . . . . . . . . . . . . . . . . 14
6.2.2.5. The Challenge TLV . . . . . . . . . . . . . . . . 14
6.2.2.6. The ChallengeResponse TLV . . . . . . . . . . . . 14
6.2.2.7. The Error TLV . . . . . . . . . . . . . . . . . . 14
7. EAP-CREDS Messages . . . . . . . . . . . . . . . . . . . . . 14
7.1. The EAP-CREDS-Init Message . . . . . . . . . . . . . . . 14
7.1.1. Version TLV usage . . . . . . . . . . . . . . . . . . 14
7.1.2. The ProvProto TLV usage . . . . . . . . . . . . . . . 15
7.1.3. The CredsInfo TLV usage . . . . . . . . . . . . . . . 15
7.1.4. The IdProvider TLV . . . . . . . . . . . . . . . . . 15
7.2. The EAP-CREDS-ProtoFlow Message . . . . . . . . . . . . . 16
7.2.1. The ProvProtoHeader TLV . . . . . . . . . . . . . . . 16
7.2.2. The ProvProtoData TLV . . . . . . . . . . . . . . . . 16
Pala Expires December 3, 2019 [Page 2]
Internet-Draft EAP-CREDS June 2019
7.3. The ('Validate') Message . . . . . . . . . . . . . . . . 17
8. Error Handling in EAP-CREDS . . . . . . . . . . . . . . . . . 17
9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Using EAP-CREDS with EAP-TEAP . . . . . . . . . . . . . . . . 17
11. Using EAP-CREDS with EAP-TTLS . . . . . . . . . . . . . . . . 18
12. EAP-CREDS and Simple Provisioning Protocol (SPP) . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13.1. Provisioning Protocols . . . . . . . . . . . . . . . . . 20
13.2. Token Types . . . . . . . . . . . . . . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
16. Normative References . . . . . . . . . . . . . . . . . . . . 21
Appendix A. EAP-CREDS Example Message Flow for Provisioning
Standards . . . . . . . . . . . . . . . . . . . . . 22
A.1. EAP-CREDS and CMP . . . . . . . . . . . . . . . . . . . . 22
A.2. EAP-CREDS and EST . . . . . . . . . . . . . . . . . . . . 22
A.3. EAP-CREDS and CMS . . . . . . . . . . . . . . . . . . . . 22
A.4. EAP-CREDS and ACME . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
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 conduit 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 methods of EAP-
TTLS, EAP-TEAP, or any other tunnelling method that can provide the
required encryption and (at minimum) server-side authentication to
Pala Expires December 3, 2019 [Page 3]
Internet-Draft EAP-CREDS June 2019
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 credentials lifecycle
management. 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 protocols provide native support for client
that do not have IP connectivity yet (e.g., because they do not have
network-access credentials, yet). The EAP-CREDS provides the
possibility to use such protocols (i.e., message-based) by defining a
series of messages that can be used to encapsulate the provisioning
messages for the specified protocol. In particular, examples of the
message flow for the major provisioning protocols are provided in
Annex Appendix A.
In addition to these protocols, EAP-CREDS also defines a series of
simple messages that provide a generic enrollment protocol that
allows not only certificates but also other types of credentials
(e.g., username/password pairs or symmetric secrets) to be delivered
to the client as part of the provisioning and/or renewal process.
The set of messages that make up the generic provisioning protocol is
referred to as the CREDS protocol (not to be confused with the EAP-
CREDS).
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 server 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.
Pala Expires December 3, 2019 [Page 4]
Internet-Draft EAP-CREDS June 2019
5. EAP-CREDS Protocol
This section outlines the operation of the protocol and message
flows. The format of the CREDS messages is given in Section 6.
5.1. EAP-CREDS as tunneled mechanism only
EAP-CREDS requires that an outer mechanism is in place between the
Peer and the Server in order to provide authentication and
confidentiality of the messages exchanged via EAP-CREDS. This choice
was taken to simplify the message flow and abstract EAP-CREDS from
the secure-channel establishment mechanism.
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.
5.2. Message Flow
EAP-CREDS message flow is logically subdivided into three different
phases:
Phase One (Required). CREDS Initialization. During this phase the
Peer and the Server exchange the information needed to select the
appropriate credentials management protocol. In particular, the
Sever sends its initial message of type ('Init') with the details
about what protocols are supported, and additional information
such as the version of EAP-CREDS and the supported profiles
identifiers.
Phase Two (Required). Provisioning Protocol Flow. In this phase,
the Peer and the Server exchange the provisioning protocol's
messages encapsulated in a EAP-CREDS message of type ProtoFlow.
The messages contain only two TLVs: the first one (optional)
carries information that might be normally coveyed via the
transport protocol (e.g., HTTP headers), while the second one
(required) carries the provisioning protocol's messages.
Phase Three (Optional). Credentials Validation. This optional phase
can be initiated by the server and it is used to validate that the
Peer has properly installed the credentials and can use them to
authenticate itself. Depending on the credentials' type, the
messages can carry a challenge/nonce, the value of the secret/
token, or other information. The format of the credentials is
supposed to be known by the provider and the device.
Pala Expires December 3, 2019 [Page 5]
Internet-Draft EAP-CREDS June 2019
5.3. Phase One: Initialization
The following figure provides the message flow for Phase One:
+------------+ +--------------+
| EAP Peer | | EAP Server |
+------------+ +--------------+
| |
|<----------- Outer Tunnel Established ----------->|
| |
| | Phase One
| | Begins
|<----------[1] EAP-Request/EAP-CREDS -------------| .
| (Type=Init,Ver,Supported Protocols, | :
| Providers) | |
| | |
|-----------[2] EAP-Response/EAP-CREDS ----------->| |
| (Type=Init,Ver,Proto,Provider) | v
| | |
|<-----------[3] EAP-Request/EAP-CREDS ------------| |
| (Type=Init, << Empty >>) | v
| | Phase One
: : Ends
. .
During the CREDS initialization, after the establishment of the outer
mechanism (e.g., EAP-TLS, EAP-TEAP, EAP-TTLS, etc.), the initial the
server sends the EAP-Request/EAP-CREDS(Type=Init) message with the
('Versions') TLV to indicate the supported versions of EAP-CREDS
(i.e. a list of all supported version of EAP-CREDS), the
('Supported-Protocol') TLV to indicate the list of supported
provisioning protocols, followed by the ('Providers') TLVs that allow
the client to pick the credentials' vendor.
The peer selects the version, the protocol, and optionally the
provider, and sends back the response in a EAP-Response/EAP-
CREDS(Type=Init) message to the server which includes the
('Versions'), ('Protocols'), and optionally the ('Providers') TLVs
with only one value each. If multiple values are detected in the
message from the Peer, the message shall be discarded and the
appropriate error message shall be issued by the Server.
The server checks that the requested protocol and parameters are
supported and, if not (or if the server detects an error), it sends
an error message to the peer and notify the outer (tunneling) layer.
Pala Expires December 3, 2019 [Page 6]
Internet-Draft EAP-CREDS June 2019
In case the server can serve the request from the client, it sends an
empty EAP-Request/EAP-CREDS(Type=Init) message to indicate that the
server is ok with the selected parameters and is waiting on the Peer
to start Phase Two of the protocol.
5.4. Phase Two: Provisioning
The following figure provides the message flow for Phase 2:
+------------+ +--------------+
| EAP Peer | | EAP Server |
+------------+ +--------------+
| |
: :
. .
| | Phase Two
| | Begins
|------------ EAP-Response/EAP-CREDS ------------->| .
| (Type=ProtoFlow,ProtoData) | |
| | |
|<----------- EAP-Request/EAP-CREDS ---------------| |
| (Type=ProtoFlow,ProtoData) | |
| | |
: : :
. . .
: : :
| | |
| | |
|------------ EAP-Response/EAP-CREDS ------------->| v
| (Type=ProtoFlow,EMPTY) | Phase Two
| | Ends
: :
The server starts phase two of the EAP-CREDS protocol by sending an
EAP-Request/EAP-CREDS(Type=ProtoFlow) message with the selected
protocol's details to the Peer. This indicates that the Server is
ready to initiate the provisioning protocol.
Specifically, the Server MUST include the 'Ver' and 'Proto' TLVs to
indicate the EAP-CREDS version agreed upon by the parties and the
specific provisioning protocol to use. The 'provider' TLV is
optional and MUST be included if a selection was made by the Peer.
The 'provider' TLV MAY be included in the message even if the Peer
did not make a selection.
Pala Expires December 3, 2019 [Page 7]
Internet-Draft EAP-CREDS June 2019
After that, the Peer sends its first message to the Server by sending
the EAP-Response/EAP-CREDS(Type=ProtoFlow) message. This message
contains the selected provisioning protocol's message data and some
extra fields (e.g., transport-protocol headers).
The Server replies to the Peer's message with EAP-Request/EAP-
CREDS(Type=ProtoFlow) messages until the provisioning protocol
reaches an end (the client will send a 'ProtoFlow' message with an
empty body) or an error condition (the party that detected the error
condition will use a 'ProtoFlow' message with an 'Error' TLV to
convey the issue and terminate the protocol).
The communication between the client and the server continues until
the selected protocol and action is correctly performed or a failure
is detected and reported.
5.5. Phase Three: Validation
The following figure provides the message flow for Phase 3:
Pala Expires December 3, 2019 [Page 8]
Internet-Draft EAP-CREDS June 2019
+------------+ +--------------+
| EAP Peer | | EAP Server |
+------------+ +--------------+
| |
: :
. .
| | Phase Three
|<----------- EAP-Request/EAP-CREDS ---------------| Begin
| (Type=Validate,Challenge) | .
| | |
| | |
|------------ EAP-Response/EAP-CREDS ------------->| |
| (Type=Validate,ExtraChallenge, | |
| ChallengeResponse,Challenge) | |
: : :
. . :
: : :
: | |
| | |
|<----------- EAP-Request/EAP-CREDS ---------------| |
| (Type=Validate,ChallengeResponse) | |
| | |
|------------ EAP-Request/EAP-CREDS -------------->| |
| (Type=Validate,EMPTY) | v
| | Phase Three
| | Ends
| |
|<----------- EAP-Success -------------------------| EAP Success
| |
Phase three is optional and it is used by the server to request the
client to validate (proof) that the new credentials have been
installed correctly before issuing the final Success message.
In order to do that, the server and the client exchange two or three
EAP-Request/EAP-CREDS(Type=Validate) and EAP-Response/EAP-
CREDS(Type=Validate) messages where the correctness of the exchanged
credentials is verified by the server and (optionally) by the client.
In particular, when the client receives the first Validate message
from the server, it calculates the response to the challenge (based
on the type of credentials and the protocol itself - if supported,
this would be a 'test' authentication) and sends the response back to
the server.
Pala Expires December 3, 2019 [Page 9]
Internet-Draft EAP-CREDS June 2019
Optionally, the client can add the ExtraChallenge TLV that carries
the extra challenge information that was used to calculate the
ChallengeResponse TLV (if any). This field can be used to prevent
the use of the Validate phase as an encryption or validation oracle.
Optionally, the client can add the Challent TLV to the response.
When the server receives the EAP-Response/EAP-CREDS(Type=Validate)
with the Challenge TLV in it, it MUST calculate the response to the
challenge and send back the response to the client in an EAP-Request/
EAP-CREDS(Type=Validate) with the ChallengeResponse TLV and,
optionally, the ExtraChallenge TLV.
In case of issues with the validation of the newly deployed
credentials, both the client and the server should consider those
credentials invalid (or unusable) and should issue the required
failure message(s).
6. EAP-CREDS Message Format
The EAP-CREDS defines the following message types:
EAP-CREDS/Init
EAP-CREDS/ProtoFlow
EAP-CREDS/Validate
Each of these message types have the basic structure as identified in
Section 6.1 and in Section 6.2 and contain zero, one, or more TLVs.
The allowed TLVs for the different types of messages are described in
Section 7. The internal structure of the different types of TLVs is
described in Section 6.2.1.
6.1. Message Header
The EAP-CREDS messages consist of the standard EAP header (see
Section 4 of [RFC3748]), followed by the version of the EAP-CREDS (4
bits) and a field (4 bits) reserved for future use. The header has
the following structure:
Pala Expires December 3, 2019 [Page 10]
Internet-Draft EAP-CREDS June 2019
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.
Where the Code, Identifier, Length, and Type fields are all part of
the EAP header as defined in [RFC3748].
The Type field in the EAP header is <TBD> for EAP-CREDS.
The Ver (Version) bitfield (4 bits) identifies the version of the
EAP-CREDS protocol used for the exchange. This document defines the
value to use for this field as '0x1' (0001).
The Flags bitfield (4 bits) is currently not used and it is reserved
for future use. The value of the bitfield shall be ignored when the
Version ('Ver') field is set to '0x1' (0001).
6.2. Message Payload
The Data part of the message is organized as zero, one, or more TLV
objects whose structure is defined in this section. In particular,
the general structure of a TLV is described in Section 6.2.1, while
the specific structures for the supported TLVs is provided in
Section 6.2.2.
6.2.1. General TLV format
Each TLV object has the same basic structure that is defined as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
TLV-Type
Pala Expires December 3, 2019 [Page 11]
Internet-Draft EAP-CREDS June 2019
This field is used to indicate the type of data that the TLV
carries. The different types of TLVs are described in
Section 6.2.2.
Length
This field carries the size of the value of the TLV. In
particular, the overall size of a TLV (i.e., the header plus the
value) can be calculated by adding the size of the header (6
octects) to the value of the Length field (i.e., the size of the
TLV's value).
TLV Type
This field carries the type of TLV which determines its internal
structure. The supported values for this fields are provided in
the following table:
+--------------+----------------------------------+
| Message Type | Purpose |
+--------------+----------------------------------+
| 0 | Error TLV |
| 1 | EAP-CREDS Version TLV |
| 2 | Provisioning Protocol TLV |
| 3 | Provisioning Provider TLV |
| 4 | Provisioning Protocol Header TLV |
| 5 | Provisioning Protocol Data TLV |
| 6 | Credentials Information TLV |
| 7 | Authorization Token TLV |
| 8 | Registration Token TLV |
| 9 | Challenge TLV |
| 10 | Challenge Response TLV |
+--------------+----------------------------------+
Table 1: EAP-CREDS Supported TLVs Types
6.2.2. EAP-CREDS defined TLVs
EAP-CREDS messages's payload comprieses zero, one, or more TLVs that
are encoded in a single EAP-CREDS message. The values for the TLV
Type that are supported by this specifications are listed in Table 1.
This section describes the structure of the different supported TLVs
and their usage in the different messages.
Pala Expires December 3, 2019 [Page 12]
Internet-Draft EAP-CREDS June 2019
6.2.2.1. The Protocol TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID (uint16) | Protocol Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type
<TBD> - Provisioning Protocol TLV
Length
4 octets
Protocol ID
The Protocol ID field is 2 octets. The allowed values for this
field are maintained in a subdirectory by IANA. The initial
values for the provisioning protocol identifiers can be found in
Section 13.1.
Protocol Version
The Protocol Version field is 2 octet (uint16). When no version
is specified for a protocol (i.e., either it does not support
multiple versions or it does not matter), the value should be set
to '0x0'.
6.2.2.2. The Profiles TLV
6.2.2.3. The CredInfo TLV
Type (Int; 1Byte) | HashAlgoId (Int; 1 byte) | Installed On (GMT; 15
bytes) | ExpiresOn (GMT; 15 bytes) | Salt/Nonce (RND; 32 bytes) |
id_len (Int; 2 bytes) | id_value | cred_hash_len (Int; 2 bytes) |
Cred_Hash (Binary; 20-64 bytes)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|S| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32 bit Integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pala Expires December 3, 2019 [Page 13]
Internet-Draft EAP-CREDS June 2019
6.2.2.4. The AuthToken TLV
6.2.2.5. The Challenge TLV
6.2.2.6. The ChallengeResponse TLV
6.2.2.7. The Error TLV
7. EAP-CREDS Messages
This section describes each message and what TLVs are allowed or
required. EAP-CREDS defines the following values for the Message
Type (Type):
+------------+---------------------+--------------------------------+
| Message | Name | Description |
| Type | | |
+------------+---------------------+--------------------------------+
| 0 | EAP-CREDS-Init | Initialization Phase |
| 1 | EAP-CREDS-ProtoFlow | Carries Provisioning Protocol |
| | | Messages |
| 2 | EAP-CREDS-Validate | Validates newly installed |
| | | credentials |
+------------+---------------------+--------------------------------+
Table 2: EAP-CREDS Message Types
7.1. The EAP-CREDS-Init Message
The EAP-CREDS-Init message type is used in Phase One only of EAP-
CREDS. The message flow is depicted in Section 5.3. This message
supports the following TLVs: Version, ProvProto, CredsInfo, and
IdProvider.
In this section we specify how these TLVs are used in the phase-one
messages.
7.1.1. Version TLV usage
The Version TLV is used to convey the version of EAP-CREDS to be used
for the current session.
The Server uses one or more Version TLVs in the EAP-Request/EAP-
CREDS(Type=Init) message to provide the Peer with the list of EAP-
CREDS versions supported. At minimum, the Server must include one
Version TLV with the value of '0x1'. If the Server detects multiple
occurrences of this TLV in the reply from the Peer, an error shall be
issued and the EAP-CREDS should abort.
Pala Expires December 3, 2019 [Page 14]
Internet-Draft EAP-CREDS June 2019
The Peer, on the other hand, MUST include only one Version TLV in the
EAP-Response/EAP-CREDS(Type=Init) message to indicate the version of
EAP-CREDS that the client wants to use for the session. The Peer
MUST pick from the list provided in the message from the server and,
if no common version is supported by the client, then the client
shall send an error message (i.e., an EAP-Response/EAP-
CREDS(Type=Init) with at least one EAP-CREDS-Err TLV).
7.1.2. The ProvProto TLV usage
The ProvProto TLV is used to idicate which provisioning protocols are
are supported by the peer and the server.
The Server uses one or more ProvProto TLVs in the EAP-Request/EAP-
CREDS(Type=Init) message to provide the Peer with the list of
supported provisioning protocol. At minimum, the Server must include
one ProvProto TLV with the Simple Provisioning Protocol value (SSP
MUST be supported by EAP-CREDS servers). If the Server detects
multiple occurrences of this TLV in the reply from the Peer, an error
shall be issued and the EAP-CREDS should abort.
The Peer, on the other hand, MUST include only one ProvProto TLV in
the EAP-Response/EAP-CREDS(Type=Init) message to indicate the
protocol it intends to use in phase two. The Peer MUST pick from the
list provided in the message from the server and, if no common
protocol is supported by the client, then the client shall send an
error message (i.e., an EAP-Response/EAP-CREDS(Type=Init) with at
least one EAP-CREDS-Err TLV).
7.1.3. The CredsInfo TLV usage
The CredsInfo TLV is used by the peer to convey information to the
EAP-CREDS server about the installed (if any) credentials for the
network being accessed.
The Server does not use this TLV in its EAP-CREDS-Init messages.
The Peer, on the other hand, MUST include one CredsInfo TLV for each
installed credentials (that the network is authorized to manage) in
the EAP-Response/EAP-CREDS(Type=Init) message. If no credentials are
available, yet, then the client SHALL NOT include this TLV in its
EAP-CREDS-Init message.
7.1.4. The IdProvider TLV
The IdProvider TLV is used to convey the list of supported providers
that can be used for managing credentials (e.g., a list of identity
providers).
Pala Expires December 3, 2019 [Page 15]
Internet-Draft EAP-CREDS June 2019
The Server uses one or more IdProvider TLVs in the EAP-Request/EAP-
CREDS(Type=Init) message to provide the Peer with the list of
supported credentials providers. The server can omit the set of TLVs
in case a single provider is supported (or if the selection of the
provider is done based on different factors - e.g., the authenticated
credentials via the tunneling mechanism).
The Peer, on the other hand, MAY include only one IdProvider TLV in
the EAP-Response/EAP-CREDS(Type=Init) message to indicate which
provider it wants the Server to use. The Peer MUST pick from the
list provided in the message from the server. If the client does not
support any of the providers listed in the Server's message or if no
selection is provided and the Peer requires a specific provider, then
an EAP-Response/EAP-CREDS(Type=Init) with an EAP-CREDS-Err TLV MUST
be sent to the server as a response.
7.2. The EAP-CREDS-ProtoFlow Message
The EAP-CREDS-ProtoFlow message type is used in Phase Two only of
EAP-CREDS. The message flow is depicted in Section 5.4. This
message type supports the following TLVs: ProvProtoHeaders and
ProvProtoData.
In this section we specify how these TLVs are used in the phase-one
messages.
7.2.1. The ProvProtoHeader TLV
The ProvProtoHeader TLV is used to convey one or more headers (or
extra information) that add relevant information for the provisioning
protocol.
Both on the Peer and on the Server, this TLV should be used to, for
example, provide HTTP headers that might be required for some
provisioning protocols that do not properly abstract from the
transport layer (e.g., ACME and EST are examples of this type of
protocols).
7.2.2. The ProvProtoData TLV
The ProvProtoData TLV is used to transport the body of the messages
for the provisioning protocol across the Peer and the Server.
Both on the Peer and on the Server, this TLV is used to carry the
provisioning protocol's messages. In particular, the protocols'
messages are encapsulated in this TLV without further re-encoding of
the message. Only one instance of this TLV is allowed in EAP-CREDS-
ProtoFlow messages.
Pala Expires December 3, 2019 [Page 16]
Internet-Draft EAP-CREDS June 2019
7.3. The ('Validate') Message
8. Error Handling in EAP-CREDS
This section provides a description of the error handling by using
the CREDS-Error-TLV in a CREDS message.
9. Fragmentation
Although EAP does not directly support handling of fragmented
packets, EAP-CREDS requires that its messages are encapsulated via an
outer method that MUST provide fragmentation support.
Because of the outer method requirements in particular, removing any
support for fragmented messages in EAP-CREDS removes the duplication
of packets (e.g., Acknowledgment Packets) sent across the Peer and
the Server, thus resulting in a smaller number of exchanged messages
10. Using EAP-CREDS with EAP-TEAP
Pala Expires December 3, 2019 [Page 17]
Internet-Draft EAP-CREDS June 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 |
|<------------------------|
11. Using EAP-CREDS with EAP-TTLS
Pala Expires December 3, 2019 [Page 18]
Internet-Draft EAP-CREDS June 2019
+--------+ +-------------+
| Client | | AAA |
+--------+ +-------------+
| |
| ClientHello |
|------------------------>|
| ServerHello, |
| Certificate(1), |
| ServerKeyExchange, |
| CertificateRequest(2), |
| ServerHelloDone, |
|<------------------------|
| Certificate(3), |
| ClientKeyExchange, |
| CertificateVerify, |
| ChangeCipherSpec, |
| Finished |
|------------------------>|
| ChangeCipherSpec, |
| Finished |
|<------------------------|
: :
// //
// <---- EAP-CREDS ----> //
// //
: :
| EAP-Success |
|<------------------------|
12. EAP-CREDS and Simple Provisioning Protocol (SPP)
EAP-CREDS supports a Simple Provisioning Protocol (SPP) which
comprises a series of messages that enables the management not only
of certificates, but also of other types of credentials like
username/password pairs, asymmetric keys, and symmetric keys.
EAP-CREDS/SSP defines the following flow of messages for requesting
the provisioning of credentials.
13. 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].
Pala Expires December 3, 2019 [Page 19]
Internet-Draft EAP-CREDS June 2019
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.
13.1. Provisioning Protocols
+-----------------+-------------------------------------------------+
| Message Type | Purpose |
+-----------------+-------------------------------------------------+
| 0 | Unspecified |
| 1 | Simple Provisioning Protocol (SPP) |
| 2 | Basic Certificate Management Protocol (CMP-S) |
| 3 | Full Certificate Management Protocol (CMP-F) |
| 4 | Enrollment over Secure Transport (EST) |
| 5 | Certificate Management over CMS (CMC) |
| 6 | Automatic Certificate Management Environment |
| | (ACME) |
| ... | ... |
| 49141 ... 65534 | Vendor Specific |
+-----------------+-------------------------------------------------+
Table 3: 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].
13.2. Token Types
+------------+-----------------+
| Token Type | Description |
+------------+-----------------+
| 0 | Unspecified |
| 1 | JWT |
| 2 | Kerberos |
| 3 | OAuth |
| 200..254 | Vendor Specific |
+------------+-----------------+
Table 4: Token Types
Assignment of new values for new Message Types MUST be done through
IANA with "Expert Review" as defined in [RFC8126].
Pala Expires December 3, 2019 [Page 20]
Internet-Draft EAP-CREDS June 2019
14. 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.
As part of the TLS negotiation, the server presents a certificate to
the peer. The peer SHOULD verify the validity of the EAP server
certificate and SHOULD also examine the EAP server name presented in
the certificate in order to determine whether the EAP server can be
trusted. When performing server certificate validation,
implementations MUST provide support for the rules in [RFC5280] for
validating certificates against a known trust anchor.
15. Acknowledgments
The authors would like to thank everybody who provided insightful
comments and helped in the definition of the deployment
considerations.
16. 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>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
Pala Expires December 3, 2019 [Page 21]
Internet-Draft EAP-CREDS June 2019
[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>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[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 Example Message Flow for Provisioning Standards
A.1. EAP-CREDS and CMP
Describe how to use EAP-CREDS with CMP.
A.2. EAP-CREDS and EST
Describe how to use EAP-CREDS with EST.
A.3. EAP-CREDS and CMS
Describe how to use EAP-CREDS with CMS.
A.4. 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 December 3, 2019 [Page 22]