| Network Working Group | M. Pala |
| Internet-Draft | CableLabs |
| Intended status: Standards Track | June 4, 2019 |
| Expires: December 6, 2019 |
Credentials Provisioning and Management via EAP (EAP-CREDS)
draft-pala-eap-creds-02
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 802.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.
EAP-CREDS, if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP-CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/authenticated.
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.
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 6, 2019.
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.
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].
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 deliver server-side generated secrets (e.g., private keys, passwords, secret keys, etc.)
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: 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).
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
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.
This section outlines the operation of the protocol and message flows. The format of the CREDS messages is given in Section 6.
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.
In other words, the EAP-CREDS 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.
This choice was taken to simplify the message flow between Peer and Server, and to abstract EAP-CREDS from the secure-channel establishment mechanism. EAP-TLS, EAP-TTLS, and EAP-TEAP are examples of such mechanisms.s
EAP-CREDS message flow is logically subdivided into three different phases:
In this document we use the following notation in the diagrams to provide information about the cardinality of a data structure (TLV) within a single EAP-CREDS message:
| Symbol | Example | Usage |
|---|---|---|
| { } | { TLV1, TLV2 } | Curly Brackets are used to indicate a set |
| [ ] | { TLV1, [ TLV2 ] } | Square Brackets are used to indicate that a field is optional |
| ( ) | { TLV1(=VALUE) } | Round Squares are used to specify a value |
| + | { TLV1, [ TLV_2+ ] } | The Plus character indicates that one or more instances are allowed |
The following figure provides the message flow for Phase One:
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| Outer Tunnel Established |
| <--------------------------------------->
| |
| [1] EAP-Request/EAP-CREDS(Type=Init) | ,---------!.
| { [ Version+ ] } | |Phase One|_\
| <---------------------------------------- |Begins |
| | `-----------'
| [2] EAP-Response/EAP-CREDS(Type=Init) |
| { [ Version ], Protocol+, | ,---------!.
| [ CredInfo+ ], [ Token ] | |Phase One|_\
| [ Challenge ], [ Challenge-Rsp ] }| |Ends |
| ----------------------------------------> `-----------'
| |
| |
During the CREDS initialization, after the establishment of the outer mechanism (e.g., EAP-TLS, EAP-TEAP, EAP-TTLS, etc.), the server MAY decide to start a credentials management session. In order to do that, it sends an empty message to the Client. In particular, it sends a EAP-Request/EAP-CREDS(Type=Init) message with the list of supported EAP-CREDS version via the (possibly multiple) Supported-Version TLV.
The client, sends back a message that carries one ('Supported-Version') TLV to indicate the selected version of EAP-CREDS (i.e. from the list provided by the server) (optional), one or more ('Supported-Protocol') TLV to indicate the list of supported provisioning protocols, followed by the ('CredInfo') TLVs (one or more) that provide the status of the credentials (one or more) that the Network is responsible for. If multiple credentials are configured on the Peer for this Network, then the Peer MUST include one CredInfo TLV for each available credential.
When there are no abailable credentials, the Peer MAY include an authorization token that can be consumed by the Server for registering new credentials. In particular, the Peer can include the ('Token-Data') TLV to convey the value of the token. The ('Challenge-Data') and ('Challenge-Response') TLVs, instead, can be used to convey a challenge and the response to that challenge based on the authorization information (e.g., maybe a public key hash is present in the Token, then the peer can generate some random data - or use the one from the Server - and generate a signature on that: the value of the signature shall be in the ('Challenge-Response') TLV and should be calculated over the values of the ('Challenge-Data') TLV and the ('Token-Data') TLV).
The server checks that the Peer's selected protocol, version, and parameters are supported and, if not (or if the server detects an error), it can (a) send a non-recoverable error message to the peer, notify the outer (tunneling) layer, and terminate the EAP-CREDS session, or (b) start phase one again by sending a new ('EAP-CREDS-Init') message that will also carry an ERROR TLV that provides the Peer with the reason the initial response was not acceptable. The server and the peer can repeat phase one until they reach an agreement or the session is terminated.
On the other hand, in case the server can serve the request from the client, EAP-CREDS continues by starting the provisioning process. The determination of the need to start phase two or not is based on the contents of the CredInfo sent by the Peer (e.g., a credential is about to expire or a credential is simply missing). The Server can repeat phase two as many times as needed: each time, the combination of the ('Credentials-Info') TLV (a.k.a. CredInfo) and the ('Action') TLV shall be unique for each session to repeat the same operation on the same credential. In case all credentials for the Network do not need maintenance at this time, the Server can decide to end the EAP-CREDS session (no actions to be taken) and successfully complete the session.
In order to move to phase two (if the server needs to perform management operations on the credentials exposed by the peer), the Server selects the version, the provisioning protocol, associated parameters, and, optionally, the provider and sends it back to the Peer. Phase Two officially begins with the next message exchanged by the two parties which is an EAP-Request/EAP-CREDS(Type=ProtoFlow) message to the client which includes the selected ('Version'), ('Action'), ('Protocols'), ('CredInfo'), and optionally the ('Provider') TLVs with only one value each. The TLVs cannot be repeated within the same message. If multiple values are detected in the message, the message shall be discarded and the appropriate error message shall be issued by the Peer.
The following figure provides the message flow for Phase 2:
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [3] EAP-Request/EAP-CREDS(Type=ProtoFlow) |
| { [ Version ], Protocol, Action, | ,---------!.
| [ CredInfo ], [ ProvParams ], | |Phase Two|_\
| [ ProtoData ] } | |Begins |
| <------------------------------------------ `-----------'
| |
| [4] EAP-Response/EAP-CREDS(Type=ProtoFlow)|
| { ProtoData, [ ProtoHeaders ] } |
| ------------------------------------------>
| |
. .
. .
. .
. .
| [5] EAP-Request/EAP-CREDS(Type=ProtoFlow) |
| { ProtoData, [ ProtoHeaders ] } |
| <------------------------------------------
| |
| [6] EAP-Response/EAP-CREDS(Type=ProtoFlow)| ,---------!.
| { << Empty Body >> } | |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 'Version' and 'Protocol' 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.
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) in the Protocol-Data and Protocol-Headers TLVs respectively.
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).
After the Peer sends the final empty message, the server can start phase three of EAP-CREDS or it can repeat phase two by issuing a new ProtoFlow message with the appropriate TLVs to idicate the target credential and action to perform.
The following figure provides the message flow for Phase 3:
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Validate) | ,-----------!.
| { CredInfo, Challenge } | |Phase Three|_\
| <----------------------------------------- |Begins |
| | `-------------'
| [2] EAP-Response/EAP-CREDS(Type=Validate)|
| { Challenge, ChallengeResponse, |
| [ ExtraChallenge ] } |
| ----------------------------------------->
| |
| [3] EAP-Request/EAP-CREDS(Type=Validate) |
| { Challenge, ChallengeResponse } |
| <-----------------------------------------
| |
| [4] EAP-Response/EAP-CREDS(Type=Validate)| ,-----------!.
| { << Empty Body >> } | |Phase Three|_\
| -----------------------------------------> |Ends |
| | `-------------'
| |
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 messages, i.e. one EAP-Request/EAP-CREDS(Type=Validate) and one EAP-Response/EAP-CREDS(Type=Validate). These messages are used to verify the correctness of the exchanged credentials and the ability by the Peer to use the credentials. The server must include the ('Credentials-Info') TLV to provide the indication about which credential the Server intends to validate. The Server MUST also include a randomly generated challenge in the message to the client.
When the client receives the Validate message from the server, it calculates the response to the challenge (based on the type of credentials and the protocol itself) and sends the response back to the server. The Peer MUST calculate the response as follows:
Optionally, the client can optionally add a new ('Challenge-Data') TLV in its reply to request that the network proves it can calculate responses. This extra challenge is only available for symmetric secrets (it is not used to verify again the identity of the server, but it is used for the server to prove it does have the right symmetric data on its side). This 'extra' challenge carries the Peer-Generated challenge information that the server MUST use to calculate the corresponding ('Challenge-Response') TLV.
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.
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).
The EAP-CREDS defines the following message types:
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.
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:
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).
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.
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
TLV-Type (uint8)
Length (uint24)
| Message Type | Purpose |
|---|---|
| 0 | Action TLV |
| 1 | Challenge-Data TLV |
| 2 | Challenge-Response TLV |
| 3 | Credentials-Data TLV |
| 4 | Credentials-Info TLV |
| 5 | Error TLV |
| 6 | Profile TLV |
| 7 | Protocol TLV |
| 8 | Provisioning-Headers TLV |
| 9 | Provisioning-Data TLV |
| 10 | Provisioning-Params TLV |
| 11 | Token-Data TLV |
| 12 | Version TLV |
TLV Value ( > 1 octet )
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 2.
This section describes the structure of the different supported TLVs and their usage in the different messages.
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 | Flags | Action Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Flags (uint8)
Action Type (uint16)
Encoding (uint8)
Value (octet string)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Format | Encoding | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Flags (uint8)
For a Trusted Root CA, the value of the flags shall be 0x7 (0000 0111). For an intermediate CA certificate that is not implicitly trusted, the value of the flags field should be set to 0x02 (0000 0010). For an End-Entity certificate, the value of the Flags will be 0x0 (0000 0000).
Format (uint8)
Encoding (uint8)
Value (octet string)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Challenge Data (> 1 octet)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Challenge Response ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Challenge Response (> 1 octet)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | CredsType | ProtoID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IssuedOn (GMT) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Expires On (GMT) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credentials Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CredIDValue ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Credential-Information TLV is used by the Peer to provide a description of the installed credentials that are relevant for the network that is being accessed. The TLV is also used by the server to provide indication to the Peer about the required parameters when requesting/updating credentials.
For example, when a set of credentials need to be renewed, the server checks the CredInfo from the Peer and eventually selects the right one for renewal - in the first message of Phase Two, the CredInfo TLV is used by the server to convey (let's say that the credentials to renew are X.509 based) the requirements for generating the X.509 PKCS#10 request, such as the algorithm (RSA, ECDSA, etc.) further parameters (e.g., the specific curve to use or the Key Size) and the indication if the credentials are to be generated on the server or on the client.
The TLV structure is as follows:
TLV Type (uint8)
Length (uint24)
Flags (uint8)
CredType (uint8)
ProtoID (uint16)
IssuedOn (16 octets)
ExpiresOn (16 octets)
Credentials Length (uint16)
CredIDValue (> 1 octet)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cred Type | Format | Encoding | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Cred Type (uint8)
Format (uint8)
Encoding (uint8)
Value (octet string)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-CREDS Error Code | Secondary Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Description ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
EAP-CREDS Error Code (2 octets)
Secondary Error Code (2 octets)
Description ( > 1 octet)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Profile Identifying Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Profile Identifying Data (octet string)
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 | Protocol ID | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Protocol ID (uint16)
Version
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Provisioning Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Headers Data (> 1 octet)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Headers Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Headers Data (> 1 octet)
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Length | Max Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Flags | OBJECT IDENTIFIER (DER) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Min Length (uint16)
Max Length (uint16)
Flags (uint8)
Algorithm (uint8)
Object Identifier (binary; > 1 octet)
| OID Name | Dotted Representation | Binary Encoding |
|---|---|---|
| secp256r1 curve | 1.2.840.10045.3.1.7 | 06 08 2A 86 48 CE 3D 03 01 07 |
| secp384r1 curve | 1.2.840.10045.3.1.34 | 06 08 2A 86 48 CE 3D 03 01 22 |
| secp521r1 curve | 1.2.840.10045.3.1.35 | 06 08 2A 86 48 CE 3D 03 01 23 |
| X25519 curve | 1.3.101.110 | 06 03 2B 65 6E |
| X25519 curve | 1.3.101.110 | 06 03 2B 65 6E |
| X448 curve | 1.3.101.111 | 06 03 2B 65 6F |
| Ed25519 curve | 1.3.101.112 | 06 03 2B 65 70 |
| Ed448 curve | 1.3.101.113 | 06 03 2B 65 71 |
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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Token Type | Encoding | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Length (uint24)
Token Type (uint8)
Encoding (uint8)
Value (octet string)
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
Version (uint8)
This section describes each message and what TLVs are allowed or required. EAP-CREDS defines the following values for the Message Type (Type):
| Message Type | Name | Description |
|---|---|---|
| 0 | EAP-CREDS-Init | Initialization Phase |
| 1 | EAP-CREDS-ProtoFlow | Carries Provisioning Protocol Messages |
| 2 | EAP-CREDS-Validate | Validates newly installed credentials |
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, Protocol, Credentials-Info, and Error.
EAP-CREDS starts with an ('EAP-CREDS-Init') message from the server. This message MAY contain zero, one, or more ('Version') TLVs and, optionally, a ('Challenge-Data') TLV.
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. If omitted, the implict version of EAP-CREDS used in the session is one ('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 session should be terminated.
In case Token-Based registration is enabled on the Server, the Server SHOULD include, in its Init message, a ('Challenge-Data') field that can be used by the client to provide reply protection, and (unique) challenge data for proof-of-possession of secrets.
The Peer MUST reply to the Server's ('EAP-CREDS-Init') message with its own ('EAP-CREDS-Init') one. The Peer 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 also provide the list of supported provisioning protocols (via the 'Protocol' TLV), the list and status of the installed credentials (via the 'Credentials-Info' TLV). The Peer MAY include authorization data when registering new credentials (e.g., an authorization token or a device certifcate).
The Peer MUST include one ('Credentials-Info') TLV for each credential the Network is authorized to manage. Typically, a Peer will include only one ('Credentials-Info') TLV in its ('EAP-CREDS-Init') message, but there might be cases where multiple types of credentials are available (e.g., X.509 certificate and username/password combination) and used depending on the location and other factors.
In case the Peer does not have any credentials available yet, it does not add any ('Credentials-Info') TLV - leaving the Server with the only action possible: Registration.
The Registration process might rely on information exchanged during the Provisioning Process in Phase Two, however, if an authorization mechanism is not available, EAP-CREDS provides a simple machanism for the Peer to leverage an out-of-band token/passphrase/ott that is available (or can easily be made available) on the Peer and that can be verified by the Server.
In particular, when the Peer wants to register new credentials (and the Server requires the use of authorization because, for example, the Peer does not have any credentials yet) it may need to provide (a) a Token, (b) a challenge value, and (c) a response to the challenge value. To do so, the Peer MUST encode the token in a ('Token-Data') TLV, the challenge value in a ('Challenge-Data') TLV, and, finally, the response to the challenge in the ('Challenge-Response') TLV.
The use of ('Challenge-Data') and ('Challenge-Response') TLVs is optional, however it is suggested that if a token is used for bootstrapping the trust, it should provide a way to verify a secret associated with it.
It is also very important that the authorization token is disclosed only to authorized servers - the Peer MUST NOT disclose authorization tokens that are not meant for the network that is being accessed. This can be done, usually, by verifying the identity of the Server first (in the outer mechanism) and then verify that the target of the Token is the Server the Client is talking to.
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: Protocol, Credentials-Info, Provisioning-Headers, Provisioning-Data, Token-Data, and Error.
After the exchange of the initial two ('EAP-CREDS-Init') messages, the Server MAY start phase two by issuing an ('EAP-CREDS-ProtoFlow') message for the Peer where it encodes all the required details for starting the provisioning process. In particular, the server sends the selected ('Action'), ('Protocol'), ('Credentials-Info'), and metadata to the client in a EAP-Request/EAP-CREDS(Type=ProtoFlow) message.
The client checks that all the selected parameters are supported for the selected credentials and, if no errors are detected, it sends its first ('EAP-CREDS-ProtoFlow') message to the Server with the ('Provisioning-Headers') and ('Provisioning-Data') TLVs only.
From now on, the conversation between the Peer and the Server continues until an error is detected or the provisioning protocol completes successfully (the client sends an empty ('EAP-CREDS-ProtoFlow') message to the Server to indicate that the protocol completed successfully).
If no other actions, the server MAY continue with phase three or issue a success message and terminate the EAP session.
EAP-CREDS uses the SHA-256 hashing algorithm to verify credentials in phase three of the protocol. Peers and Servers MUST support SHA-256 for this purpose.
This section provides a description of the error handling by using the CREDS-Error-TLV in a CREDS message.
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
In order to use EAP-CREDS together with your favorite provisioning protocol, the messages from the provisioning protcol need to be sent to the other party. In EAP-CREDS, this is done by putting the provisioning protocol messages inside the ('Provisioning-Data') TLV. In case the provisioning protocol uses additional data for its operations (e.g., uses HTTP Headers), this data can be encoded in a separate ('Provisioning-Headers') TLV.
Since the implementation of the provisioning endpoint could happen in a (logically or physically) different component, a method is needed to identify when a provisioning protocol has actually ended. In EAP-CREDS, when the provisioning protocol is over, when an empty message is sent by the Server (not the Peer).
In the first message of Phase Two, the Server provides the client with all the selected parameters for one specific credential that needs attention (or for a new credential) to be registered with the network. In particular, the server provides the ('Version') TLV (optional), the ('Protocol') TLV, the ('Action') TLV, and the ('Provisioning-Params') TLV.
After checking the parameters sent by the Server, if the Peer does not support any of them, it MUST send a message with one single ('Error') TLV with the appropriate error code(s). The server, can then decide if to manage a different set of credentials (if more where reported by the Peer in its Phase One message) or if to terminate the EAP session with an error.
The Peer and the Server exchange ProtoFlow messages until an error is detected and the appropriate error message is sent to the other party. If the error message was sent by the Peer, then the Server MAY send an empty message to the Peer and terminate the session, or it MAY try to restart Phase Two for a different set of credentials or with a different action (same target and action MUST not be repeated in the same EAP-CREDS session).
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.
The Simple Provisioning Protocol (SPP), described in this section, behaves as any other provisioning protocol: its messages are encapsulated in the ('Provisioning-Data') TLVs in the second phase of the protocol.
When no ('Credentials-Info') TLVs have been provided by the client, the Server knows that the device does not have valid credentials it wants to use to access the Network. In this case, EAP-CREDS/SPP supports the use of Tokens to kick-off the registration process. The type, format, or encoding of the Token is orthogonal to EAP-CREDS/SPP which treats the token as a black-box field (i.e., it does not try to interpret or parse its contents).
In the case where an authorization Token MUST be used and it is not just a bearer token but it can be used (or a secret identified in it) to generate a verifiable proof-of-possession, the Peer can include a ('Challenge-Data') and a ('Challenge-Response') TLVs.
The ('Challenge-Data') TLV MUST be used to convey the challenge data (usually some random value), if any. If the Server provided a ('Challenge-Data') TLV, then the Peer MUST use the same TLV in its message (and to calculate the response).
The ('Challenge-Response') TLV is used, instead, to encode the response to the challenge data that can be generated by the Peer and verified by the Server.
The SPP Messages are constructed with zero, one, or more TLVs and encoded in the ('Provisioning-Data') TLV. The size of the encpasulating ('Provisioning-Data') TLV provides the size of the whole message.
EAP-CREDS/SPP defines the following flow of messages for provisioning symmetric secrets. This method can be used to deliver a username/password combination, a token, or a symmetric key. The message flow is provided
EAP-CREDS/SPP provides the possibility for shared secret to be generated in different ways:
In particular, when initiating the second phase of the protocol, the ('Provisioning-Params') TLV is used to specify how to generate the secret.
EAP-CREDS/SSP defines the following flow of messages for requesting the provisioning of credentials.
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.
| 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 |
Assignment of new values for new cryptosuites MUST be done through IANA with "Specification Required" and "IESG Approval" as defined in [RFC8126].
| Token Type | Description |
|---|---|
| 0 | Unspecified |
| 1 | JWT |
| 2 | Kerberos |
| 3 | OAuth |
| 200..254 | Vendor Specific |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].
| Credentials Type | Description |
|---|---|
| 0 | X.509 Certificate |
| 1 | Public Key |
| 2 | Symmetric Key |
| 3 | Username and Password |
| 4 | AKA Subscriber Key |
| 5 | Bearer Token |
| 6 | One-Time Token |
| 7 | API Key |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].
| ID | Algorithm |
|---|---|
| 0 | None |
| 1 | RSA |
| 2 | ECDSA |
| 3 | XMMS |
| 4 | AKA Subscriber Key |
| 5 | OAuth |
| 6 | Kerberos4 |
| 7 | Kerberos5 |
| 200-254 | Reserved |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].
| ID | Data Type |
|---|---|
| 0 | None (Binary) |
| 1 | PKCS#8 |
| 2 | PKCS#12 |
| 3 | PublicKeyInfo |
| 200-254 | Reserved |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].
| ID | Encoding |
|---|---|
| 0 | None (Raw) |
| 1 | DER |
| 2 | PEM |
| 3 | Base64 |
| 4 | JSON |
| 5 | XML |
| 6 | ASCII |
| 7 | UTF-8 |
| 200-254 | Reserved |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].
| ID | Data Type | Description |
|---|---|---|
| 0 | Registration | Registers New Credentials |
| 1 | Renewal | Renew an Existing Credential |
| 2 | Remove | Removes an Existing Credential |
| 200-254 | n/a | Reserved |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].
Several security considerations need to be explicitly considered for the system administrators and application developers to understand the weaknesses of the overall architecture.
The most important security consideration when deploying EAP-CREDS is related to the security of the outer channel. In particular, EAP-CREDS assumes that the communication channel has been properly authenticated and that the information exchanged between the Peer and the Server are protected (i.e., confidentiality and integrity).
For example, if certificate-based authentication is used, the server presents a certificate to the peer as part of the trust establishment (or negotiation). 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.
The authors would like to thank everybody who provided insightful comments and helped in the definition of the deployment considerations.
Describe how to use EAP-CREDS with CMP.
Describe how to use EAP-CREDS with EST.
Describe how to use EAP-CREDS with CMS.
Describe how to use EAP-CREDS with ACME.