| Internet-Draft | EAP-CREDS-SPP | June 2022 |
| Pala & Tian | Expires 1 January 2023 | [Page] |
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. EAP-CREDS is an EAP method that specifically designed for credential provisioning and management. If implemented in Access Networks (e.g., wired), EAP-CREDS can offer credentials management services such as registration, provisioning, and renewal. Besides, EAP-CREDS provides protocol encapsulation mechanism that allows it to use with other credential management protocols. Therefore, this document defines how to use EAP-CREDS with the Simple Provisioning Protocol (SPP) to support the provisioning and management of authentication credentials for user and/or devices in an access network. Other credential provisioning protocols can also use this document as a guideline and template for its own encapsulation with EAP-CREDS.¶
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 1 January 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised 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. 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. The 802.1x architecture provides network administrators with the possibility to check credentials presented by a device even before providing any connectivity or IP services to it. 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 in provides a generic framework that can carry the messages for provisioning different types of credentials. EAP-CREDS implements the Simple Provisioning Protocol (SPP) which comprises of a series of messages that enable the management not only of certificates, but also of other types of credentials like username/password pairs, asymmetric keys, and symmetric keys. EAP-CREDS cannot be used as a stand-alone method. It is required that EAP-CREDS is used as an inner method of EAP-TLS, EAP-TEAP, or any other tunnelling method that can provide the required secrecy and (at minimum) server-side authentication to make sure that the communication is protected and with the right server.¶
Currently, there are many protocols that address credentials lifecycle management. Particularly, when it comes to digital certificates, some of the most deployed management protocols are: Certificate Management Protocol (CMP) [RFC4210], Certificate Management over CMS (CMC) [RFC5272][RFC6402], Enrollment over Secure Transport (EST) [RFC7030], and Automated Certificate Management Environment (ACME) . 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). 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 selected provisioning protocol. 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, tokens, 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 Simple Provisioning Protocol protocol or SPP.¶
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.¶
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, EAP-CREDS assumes that an appropriatly encrypted and authenticated channel 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, or EAP-TEAP are examples of such mechanisms.s¶
EAP does not directly support handling fragmented packets and it requires the outer method to 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 encoding 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, the 'D' bit in the message headers is used for this purpose.¶
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 managed by the network. In particular, the server provides, at minimum, the ('Protocol') TLV, the ('Action') TLV, and the ('Provisioning-Params') or the ('Credentials-Info') TLV.¶
After checking the parameters sent by the Server, if the Peer does not support any of the proposed ones, 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 Provisioning messages until an error is detected (and the appropriate error message is sent to the other party) or until Phase Two is successfully completed.¶
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.¶
In this document we use the following notation in the diagrams to provide information about the cardinality of the data structures (TLVs) within EAP-CREDS messages:¶
+--------+------------+---------------------------------------------+
| Symbol | Example | Usage |
+--------+------------+---------------------------------------------+
| { } | {TLV1} | Curly Brackets are used to indicate a set |
| [ ] | {[TLV2]} | Square Brackets are used to indicate that a |
| | | field is optional |
| ( ) | {TLV1(=V)} | Round Squares are used to specify a value |
| + | {TLV_2+} | The Plus character indicates that one or |
| | | more instances are allowed |
+--------+------------+---------------------------------------------+
In a nutshell, EAP-CREDS provides the abstraction layer on top of which credentials provisioning/managing protocols can be deployed thus enabling their use even before provisioning IP services.¶
This section outlines the operation of the protocol and message flows. The format of the CREDS messages is given in Section 4.¶
EAP-CREDS message flow is logically subdivided into three different phases: Initialization, Provisioning, and Validation. EAP-CREDS enforces the order of phases, i.e. it is not possible to move to an earlier phase.¶
Phase transitioning is controlled by the Server. In particular, the server, after the last message of a phase, it can decide to either (a) start the next phase by sending the first message of the next phase, or (b) continue the same phase by sending another "first" message of the phase (e.g., managing a second set of credentials) - this is allowed only in Phase Two and Phase Three but NOT in Phase One, or (c) terminate the EAP session.¶
In order to keep track of starting and ending a phase, EAP-CREDS defines several bits and fields in the EAP-CREDS message headers. In particular, as described in Section 4.1, the 'S' bit is used to indicate the beginning (or Start) of a phase, while the 'Phase' field (4 bits) is used to indicate the phase for this message.¶
In EAP-CREDS, phase transitioning is under the sole control of the Server, therefore the value of the 'S' bit is meaningful only in messages sent by the Server. The value of the 'S' bit in Peer's messages SHALL be set to '0x0' and SHALL be ignored by the server.¶
When starting a new phase, the Server MUST set the 'S' bit to '1' and the 'Phase' field to the current phase number (e.g., one, two, or three).¶
In case the first message of a phase is to be repeated (e.g., because of processing multiple credentials), the 'S' bit SHALL be set to '0' (i.e., it should be set to '1' only on the first occurrency and set to '0' in subsequent messages).¶
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| Outer Tunnel Established |
| <-------------------------------------->
| |
| [1] EAP-Request/EAP-CREDS(Type=Init) | ,---------!.
| { [ Version+ ], [ Challenge-Data ] } | |Phase One|_\
| <--------------------------------------- |Begins |
| | `-----------'
| [2] EAP-Response/EAP-CREDS(Type=Init) |
| { [Version], [ Protocols+ ], |
| [ Creds-Info+ ], [ Encoding+ ] | ,---------!.
| [ Format+ ], [ Token-Data ] | |Phase One|_\
| [ Profile+ ], [ Challenge-Rsp ] | |Ends |
| [ Storage-Info ],[ Net-Usage] } | `-----------'
| --------------------------------------->
| |
| |
EAP-CREDS Phase One Message Flow
[1] Server sends EAP-Request/EAP-CREDS(Type=Init):
¶
The Peer, sends back a message that carries one ('Version') TLV to indicate the selected version of EAP-CREDS (i.e. from the list provided by the server) (optional). If the client does not include the ('Version') TLV, the Server MUST use the most recent supported version of EAP-CREDS. Moreover, the Server includes one or more ('Protocol') TLVs to indicate the list of supported provisioning protocols, followed by one or more ('Credentials- Info') TLVs for each installed credential to provide their status to the server (i.e., if multiple credentials are configured on the Peer for this Network, then the Peer MUST include one ('Credentials-Info') TLV for each of them).¶
The Peer also provides the list of supported Encodings and Formats by adding one or more ('Encodings') and ('Formats') TLVs.¶
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 its response 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 value: the signature SHALL be encoded in the ('Challenge- Response') TLV and it should be calculated over the concatenation of values inside the ('Challenge-Data') TLV and the ('Token-Data') TLV.¶
Also, the Peer MAY add one or more ('Profile') TLVs to indicate to the Server which profiles are requested/supported (e.g., a pre- configuration MAY exist on the Peer with these ecosystem-specific identifiers).¶
Ultimately, the Peer MAY include additional metadata regarding the status of the Peer. To this end, the Peer can use a ('Storage- Info') TLV to provide the server with additional data about the Peer's capabilities and resources (e.g., credentials storage). Also, the ('Network-Usage') TLV can be used to provide the Server with the indication of which network resources are needed by the Peer and what is its intended utilization pattern(s).¶
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. In this case, the 'Phase' field MUST be omitted since it is not the first message of phase one (see Section 3.2). The server and the peer can repeat phase one until they reach an agreement or the session is terminated by the Server.¶
NOTE WELL: The determination of the need to start Phase Two or not is based on the contents of the ('Credentials-Info') TLV sent by the Peer (e.g., a credential is about to expire or a credential is simply missing).¶
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Provisioning) |
| { Protocol, Action, | ,---------!.
| [ CredInfo ], [ Params ], | |Phase Two|_\
| [ ProtoData ], [ ProtoHeaders ] } | |Begins |
| <---------------------------------------------- `-----------'
| |
| [2] EAP-Response/EAP-CREDS(Type=Provisioning) |
| { ProtoData, [ ProtoHeaders ] } |
| ---------------------------------------------->
| |
. .
. .
. .
. .
| [N] EAP-Response/EAP-CREDS(Type=Provisioning) |
| { [ CredInfo ], [ ProtoData ], |
| [ ProtoHeaders ] } |
| <----------------------------------------------
| |
| [N+1] EAP-Request/EAP-CREDS(Type=Provisioning)| ,---------!.
| { [ ProtoData ], [ ProtoHeaders ] } | |Phase Two|_\
| ----------------------------------------------> |Ends |
| | `-----------'
| |
¶
EAP-CREDS Phase Two Message Flow¶
At this point, the Server can decide to provision (or manage) another set of credentials by issuing a new ('Provisioning') message, or it can decide to start Phase Three by sending its first ('Validate') message, or it can terminate the EAP session.¶
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Validate) | ,-----------!.
| { Cred-Info, Challenge-Data } | |Phase Three|_\
| <----------------------------------------- |Begins |
| | `-------------'
| [2] EAP-Response/EAP-CREDS(Type=Validate)| ,-----------!.
| { Challenge-Response } | |Phase Three|_\
| -----------------------------------------> |Ends |
| | `-------------'
| |
EAP-CREDS Phase Three Message Flow (Basic)
¶
Phase three is optional and it is usually 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. However, it is also possible for the Peer to request the server-side validation for symmetric credentials. The message flow and diagram of the server-side validation is listed below in this section.¶
In order to start Phase Three, the Server sends an EAP-Request/ EAP-CREDS(Type=Validate) message to the Peer. The Server MUST include the ('Credentials-Info') TLV to provide the indication about which set of credentials the Server intends to validate. The Server MUST also include a randomly generated challenge in the message to the client. The type of challenge determines how the ('Challenge-Response') is calculated. EAP-CREDS defines the asymmetric and symmetric challenges in Section 8.6 and others can be defined according to the specified rules.¶
As usual, the Server MUST set, in the headers, the 'S' bit to '1' in its first message of Phase Three and the 'Phase' value shall be set to '3' (beginning of Phase Three).¶
When the client receives the Validate message from the server, it calculates the response to the challenge and sends the response back to the server in a EAP-Response/EAP-CREDS(Type=Validate) message. When the EAP-CREDS-ASYMMETRIC-CHALLENGE and EAP-CREDS- SYMMETRIC-CHALLENGE values are used in the Challenge type, the Peer MUST calculate the response as follows:¶
Public-Key¶
For any public-key based credentials (e.g., certificates or raw key pairs), the response to the challenge is calculated by generating a signature over the hashed value of the challenge. The hashing algorithm to be used for this purpose is specified in Section 2.6. The format of the signature in the ('Challenge-Response') TLV is the concatenation of:¶
For any symmetric based credentials (e.g., password or Key), the response to the challenge is calculated by using the selected hash function (see Section 2.6) on the concatenation of (a) the value carried in the server- provided ('Challenge-Data') TLV, and (b) the secret value itself (salted hash).¶
The initial values for the type of challenges are described in the Section 8.6. Other types of challenges MAY be defined according to the specified procedures.¶
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Validate) | ,-----------!.
| { Cred-Info, Challenge-Data } | |Phase Three|_\
| <----------------------------------------- |Begins |
| | `-------------'
| [2] EAP-Response/EAP-CREDS(Type=Validate)|
| { Challenge-Response, Challenge-Data } |
| ----------------------------------------->
| |
| [3] EAP-Response/EAP-CREDS(Type=Validate)| ,-----------!.
| { Challenge-Response } | |Phase Three|_\
| <----------------------------------------| |Ends |
| | `-------------'
EAP-CREDS Phase Three Message Flow (Server-side Validation)
[1] The Server sends EAP-Request/EAP-CREDS(Type=Validate)
¶
When the Server receives the response message from the Peer with ('Challenge-Data') included, the Server MUST include (if a symmetric secret) the response to the Peer-issued ('Challenge- Data') TLV by computing the response and adding it to the ('Challenge-Response') TLV in its reply.¶
Finally, in the last message, the Server (if Phase Three is to be ended) SHALL set the 'S' bit to '0' (end of phase) and the value of 'Phase' field set to '0x03'.¶
In case of issues with the validation of newly deployed credentials, both the Server and the Peer 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 4.1. EAP-CREDS messages contain zero, one, or more TLVs. The internal structure of the different types of TLVs is described in Section 4.2, while a detailed description of the EAP-CREDS message types is provided in Section 5.¶
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 |J|S|F|D| Phase | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.¶
Where the Code, Identifier, Length, and Type fields are all part of the EAP header as defined in [RFC3748]. Since EAP-CREDS can only be used as a tunneled mechanism, the presence of these fields is only for backward compatibility with existing parsers. In particular, the 'Length' field is not used (can be ignored): the message length is carried in the 'Message Length' field instead.¶
The Type field in the EAP header is <TBD> for EAP-CREDS.¶
The Flags bitfield is used to convey status information (e.g., extra long message, phase number, phase transitioning state). The transition-control bit (i.e., the 'S' bit) are set in Server's messages and are ignored in Peer's messages (the Server is the entity that unilaterally controls the phase transition process). The meanins of the bits in the 'Flags' field are as follows:¶
The Phase field is a 4-bits value and identifies the EAP-CREDS phase for the current message. The version of EAP-CREDS described in this document supports three values for this field:¶
A detailed explanation of the 'Phase' and 'Flags' fields of the message headers is provided in Section 3.2.¶
The Data field is the message payload. The full description of this field is provided in the next section.¶
The Data part of the message is organized as zero, one, or more TLV objects whose structure is defined in this section.¶
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)¶
| TLV Name | TLV Type | Scope/Usage |
|---|---|---|
| <TBD> | Action TLV | Phase Two |
| <TBD> | Certificate-Data TLV | Phase Two/SPP |
| <TBD> | Challenge-Data TLV | Phase Two, Phase Three |
| <TBD> | Challenge-Response TLV | Phase Two, Phase Three |
| <TBD> | Credentials-Data TLV | Phase Two/SPP |
| <TBD> | Credentials-Info TLV | Phase Two, Phase Three |
| <TBD> | Error TLV | All Phases |
| <TBD> | Network-Usage TLV | Phase One |
| <TBD> | Profile TLV | Phase Two |
| <TBD> | Protocol TLV | Phase One, Phase Two |
| <TBD> | Provisioning-Data TLV | Phase Two |
| <TBD> | Provisioning-Headers TLV | Phase Two |
| <TBD> | Provisioning-Params TLV | Phase Two |
| <TBD> | Certificate-Request TLV | SPP |
| <TBD> | Storage-Info TLV | SPP |
| <TBD> | Supported-Format TLV | SPP |
| <TBD> | Supported-Encoding TLV | SPP |
| <TBD> | Token-Data TLV | Phase One |
| <TBD> | Version TLV | Phase One |
The rest of this section describes the structure of the different supported TLVs and their usage in the different messages.¶
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.¶
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 | Action Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type (uint8)
<TBD> - Action TLV
TLV Length (uint24)
Fixed value (=2)
Flags (uint8)
Reserved
¶
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 | Encoding | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Certificate-Data TLV Length (uint24) Provides the length of the TLV (> 3 octets) 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).¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ch. Type | Challenge Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Challenge-Data TLV Length (uint24) 3 octets Challenge Type (uint8).¶
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) <TBD> - Challenge-Response TLV Length (uint24) 3 octets 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.¶
For example, when a set of credentials need to be renewed, the server checks the ('Credentials-Info') from the Peer and eventually selects the right one for renewal. The TLV structure is as follows:¶
Provides a BITMASK that can be used to provide information about the status of the credentials (e.g., if the use marks the credentials to be compromised). The bits have the following meaning:¶
Bit 0 - If set, the credential is marked as compromised¶
Bit 1 - If set, the credential is immutable and cannot be updated¶
Bit 2 - Private Key or Secret Immutable, the public part of the credential (e.g., a certificate) can still be updated¶
Bit 3 - If set, the credential cannot be updated (both public and private parts)¶
Bit 4 - If set, the credential is ready to be used¶
Bit 5 - If set, the credential was generated on the server¶
Bit 6 - If set, the Peer would like to update the credential even if they are not expired¶
Bit 7 - Reserved¶
This field carries the GMT date for when this credential was issued. This field is 16 bytes long (the last byte must be set to '0x00') and contains the NULL-terminated ASCII string that represents the timestamp where the credential was issued. When the value is not set, the field should be set to { 0x00 }. The format of the string is as follows:¶
YYYYMMDDHHmmssZ¶
YYYY - is the 4 digits representation of the year¶
MM - is the 2 digits representation of the month¶
DD - is the 2 digits representation of the day of the month¶
HH - is the 2 digits representation of the hour of the day (24 hour format)¶
mm - is the 2 digits representation of the minutes of the hour¶
ss - is the 2 digits representation of the seconds of the minute¶
Z - is the character 'Z'¶
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) <TBD> - Credentials-Data TLV Length (uint24) Provides the length of the TLV (> 3 octets) Cred Type (uint8)¶
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) <TBD> - Challenge-Response-Data TLV Length (uint24) 3 octets EAP-CREDS Error Code (2 octets)¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Desc Format | Encoding | Network-Usage Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Network-Usage TLV Length (uint24) Variable Length TLV (Value must be > 2 ) Description Format (uint8)¶
The 'URL' bit ('U') is used to indicate if the value of the Network-Usage Data field is to be interpreted as a URL or as the actual data. In particular, if the value in the 'URL' bit is '1', then the value in the Network-Usage Data field is to be interpreted as the URL where the actual data can be downloaded from. Otherwise, if the 'URL' bit is set to '0', then the value in the Netowrk-Usage Data field is to be interpreted as the actual data (not a URL referencing it).¶
An example use of this bit is when the Peer wants to convey the URL of the MUD file [RFC8520]. In this case, the Peer can set the Network-Usage Data field to the Url of the MUD file related to the Peer.¶
This field provide the expected data format for the Network-Usage Data. For example, the value in this field could be set to 'MUD' and have the 'U' bit set to '1' to provide the MUD-related information at credentials management time instead of at network- provisioning time (DHCP option). This possibility could help the Network controller to decide if the device shall be allowed to register its credentials or not.¶
The list of initial values for this field is provided in Section 8.7.¶
This is additional information related to the device. In particular, this TLV can be used by the Peer to provide the Server with the description of the intended network usage or a URL that points to the same information.¶
For example, this field can be used to convey a MUD file (Manufacturer Usage Description) or the latest firmware-update manifest.¶
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) <TBD> - Profile Identifying Data TLV Length (uint24) Length value should be >= 1 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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Protocol TLV TLV Length (uint24) Fixed TLV Length value of 4. Protocol ID (uint16)¶
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) <TBD> - Provisioning-Data TLV Length (uint24) 3 octets Headers Data (> 1 octet) This field carries the provisioning protocol's 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 | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Headers Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Provisioning-Headers TLV Length (uint24) 3 octets 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) <TBD> - Provisioning-Params TLV Length (uint24) Provides the length of the TLV (>= 6 octets) Min Length (uint16)¶
Provides the indication maximum size of the credentials. This value has meaning depending on the context of the credentials, however sizes are always expressed in bytes.¶
The same considerations apply to this field as well as the ('Min Length') one discussed above.¶
Provides a BITMASK that can be used to provide information about the status of the credentials (e.g., if the use marks the credentials to be compromised). The bits have the following meaning:¶
Bit 0 - Credentials (or part of it) are to be generated on the server¶
Bit 1 - Credentials (or part of it) are to be generated on the peer¶
Bit 2 - Credentials are to be generated on dedicated hardware¶
Bit 3 - Reserved¶
Bit 4 - Reserved¶
Bit 5 - Reserved¶
Bit 6 - Reserved¶
Bit 7 - Reserved¶
When using public-key based credentials, the bits 0 and 1 are mutually exclusive.¶
When using passwords or shared secrets, if bit 0 is set, then the secret is generated by the server and then sent to the client. On the other hand, if bit 1 is set, then the secret is generated by the peer and then sent to the server. Ultimately, if both bits are set, then the Server generates the first part of the password and sends it to the Peer, while the Peer generates the second part of the password and sends it to the Server. The password to be used for future authentication is the concatenation of the two shares of the password: first the one from the Server, then the one from the Client.¶
NOTE WELL: Last but not least, since these passwords/secrets are meant to be used in a automated fashion, there is no restriction around the character set to use or their interpretation. Therefore,it is good practice to generate random passphrases that use the full 8-bit character set (on client and server) to maximize the secret's search space.¶
| OID Name | Dotted Representation | Binary Encoding |
|---|---|---|
| secp256r1 | 1.2.840.10045.3.1.7 | 06 08 2A 86 48 CE 3D 03 |
| curve | 01 07 | |
| secp384r1 | 1.2.840.10045.3.1.34 | 06 08 2A 86 48 CE 3D 03 |
| curve | 01 22 | |
| secp521r1 | 1.2.840.10045.3.1.35 | 06 08 2A 86 48 CE 3D 03 |
| curve | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding | Format | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Token-Data TLV TLV Length (uint24) Provides the length of the TLV (> 3 octets) Encoding (uint8)¶
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 | Spare Slots | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Memory | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Store-Info TLV Flags (8 bits)¶
When the number of slots is not fixed or not known, the value of {
0xFF, 0xFF } shall be used.
Available Memory (uint32)
¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Format | +-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Supported-Format TLV TLV Length (uint24)¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoding | +-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Store-Info TLV TLV Length (uint24)¶
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) <TBD> - Token-Data TLV TLV Length (uint24) Provides the length of the TLV (> 3 octets) Token Type (uint8)¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+ TLV Type (uint8) <TBD> - Version TLV TLV Length (uint24)¶
The Version field represents the specific version of the EAP-CREDS protocol that are supported by the end point. When multiple versions of EAP-CREDS are supported, multiple ('Version') TLVs can be used.¶
When no version is specified (i.e., either it does not support multiple versions or it does not matter), the value of this field should be set to '0x0' (any version).¶
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-Provisioning | 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 3.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 first message from the server is the one that starts Phase One, therefore the Server MUST set the headers' 'S' bit to '1' (Start) and the headers' 'Phase' value to '0x01' (Phase One).¶
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 MUST include, in its Init message, a ('Challenge-Data') field that can be used by the client to provide 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 SHOULD include one ('Version') TLV in its first 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 one or more 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) via the ('Token-Data') and ('Challenge-Response') TLV.¶
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 and selected depending on the location and other factors (e.g., X.509 certificate and username/password combination).¶
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. In this case, the Peer SHOULD include authorization information via the ('Token-Data') TLV as described in Section 5.1.2.1. Additionally, the Peer can add the ('Profile') TLV to indicate a preferred profile for the credentials.¶
When the Peer does not have any valid credentials for the Network that it is authenticating to, it does not provide any ('Credentials- Info') TLV. This indicates to the Server that new credentials MUST be registered before the Peer is allowed on the network.¶
The Registration process might rely on information exchanged during the Provisioning Process in Phase Two. However, if an authorization mechanism is not available from the supported provisioning protocol and no credentials are available on the Peer, EAP-CREDS provides a simple machanism for the Peer to leverage an out-of-band token/passphrase/ott that may be already available on the Peer (e.g., a device certificate or a 'spendable' credentials token like a kerberos ticket or a crypto-currency transaction) 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 additional authorization data) 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-Provisioning message type is used in Phase Two only of EAP-CREDS. The message flow is depicted in Section 3.4. This message type supports the following TLVs: Protocol, Profile, Credentials-Info, Provisioning-Headers, Provisioning-Data, Token- Data, and Error.¶
After the exchange of Phase One messages, the Server MAY start phase two by issuing an ('EAP-CREDS-Provisioning') 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'), and metadata to the client in a EAP- Request/EAP-CREDS(Type=Provisioning) message. The header's 'S' bit MUST be set to '1' (Start) and the 'Phase' value set to '0x02' (Phase Two begins).¶
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-Provisioning') 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.¶
If no other actions, the server MAY continue with phase three or issue a success message and terminate the EAP session.¶
The EAP-CREDS-Validate message type is used in Phase Three only of EAP-CREDS. The message flow is depicted in Section 3.5. This message type supports the following TLVs: Protocol, Credentials-Info, Provisioning-Headers, Provisioning-Data, Token-Data, and Error.¶
After Phase One (and/or Phase Two) ends, the Server MAY start phase three by issuing an ('EAP-CREDS-Validate') message for the Peer where it encodes all the required details for starting the validation process. In particular, the server sends the ('Credentials-Info'), a ('Challenge-Data'), in a EAP-Request/EAP-CREDS(Type=Validate) message. The 'S' bit (Start) should set the '1' for its value and the 'Phase' field sets to '0x03' (Phase Three starts).¶
The Peer generates the answer to the Challenge and sends back a EAP- Response/EAP-CREDS(Type=Validate) message with the ('Challenge- Response') and an optional ('Challenge') field (only for server-side validation of the symmetric credentials). If the Peer requested server-side validation of the credentials, the Server MUST include (if a symmetric secret) the response to the Peer-issued ('Challenge- Data') TLV by computing the response and adding it to the ('Challenge-Response') TLV in its reply.¶
Finally, in the last message, the Server (if Phase Three is to be ended) SHALL set the 'S' bit to '0' (end of phase) and the value of 'Phase' field set to '0x03'.¶
At this point, EAP-CREDS has terminated all possible operations and can be terminated. The Server can now terminate the EAP session successfully. In case the Peer was not authenticated during the tunnel establishment (i.e., no credentials were already available on the Peer), the Server should terminate the EAP session with a Failure (thus requiring the device to re-attach and authenticate to the network - phase two should have provided the Peer with the credentials to use for authenticating to the Network).¶
This section provides a description of the error handling by using the CREDS-Error-TLV in a CREDS message.¶
EAP-CREDS supports a Simple Provisioning Protocol (SPP) which comprises of a series of messages that enable 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. SPP does not make use of any ('Provisioning-Headers') TLVs because its messages are all self-contained (no transport- protocol specific options are needed).¶
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 SHOULD NOT try to interpret or parse its contents).¶
In the case where an authorization token is used, different usage patterns are supported. For tokens that require an associated verifiable proof-of-possession, the Peer can include a ('Challenge- Response') TLVs.¶
The ('Challenge-Data') TLV provided by the Server MUST be used to convey the challenge data (usually some random value) to compute the contents of the ('Challenge-Response') TLV.¶
The ('Challenge-Response') TLV is used, instead, to encode the response to the challenge data. The ('Challenge-Response') TLV is generated by the Peer and verified by the Server. At minimum, the ('Challenge-Response') TLV SHOULD be calculated over the values of the ('Token-Data') and the ('Challenge-Data') TLVs to make sure that the authentication covers the token's data as well.¶
The SPP Messages are constructed with zero, one, or more TLVs and encoded in the ('Provisioning-Data') TLV in EAP-CREDS/Provisioning message types. The size of the encpasulating ('Provisioning-Data') TLV provides the size of the whole message.¶
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Provisioning) |
| { Protocol(=SPP), Action, |
| [ CredsInfo ] [ Params ], |
| [ ProvData(=CredsData) ] } |
| <------------------------------------------
| |
| [2] EAP-Response/EAP-CREDS(Type=Provisioning)|
| { [ ProvData(=CredsData) ] } |
| ------------------------------------------>
| |
| [3] EAP-Response/EAP-CREDS(Type=Provisioning)|
| { [ ProvData(=CredsData) ] } |
| <------------------------------------------
| |
| |
¶
SPP was designed to provide an easy alternative to more complex provisioning protocols. When no extra flexibility is needed, SPP provides an easy-to-implement alternative that can handle not only certificates, but also symmetric secrets and access tokens provisioning. In this section we provide the generic flow of messages for SPP and specific examples for certificates, username/ password, and token provisioning.¶
EAP-CREDS defines several actions for a set of credentials and they are listed in Section 8.9.¶
When a Peer wants to join a network it may or may not have have the needed credentials to do so. In case the Peer does not have valid credentials yet, the Server MAY start Phase Two with the intention of registering a new set of credentials. Alternatively, the Server MAY start Phase Two when the presented credentials information from the Peer triggers the Renew or the Remove action.¶
When registering new credentials, the first message from the Server, MUST not carry a ('Credentials-Info') TLV since there is no targeted credentials to apply the action on (i.e., for other actions - like 'renew' or 'remove' - the TLV would be required to identify the right set of credentials to renew or delete).¶
In SPP, the Server sets the ('Protocol') TLV to SPP, the ('Action') TLV to 'Register', 'Renew', or 'Remove'. When provisioning (or registering) new credentials for the Peer, the Server also sets the ('Provisioning-Params') TLV (or Params) to the type of credentials to be provisioned. The Server also sets any relevant constraints, and, optionally, the ('Profile') TLV.¶
NOTE WELL: If the Peer is authorized to register a new set of credentials, then the first message from the Server will have the ('Action') TLV set to 'register' and no ('Credentials- Info') TLV is present in the Server's message. In case server- side generation is used, an additional ('Credentials-Info') TLV MAY be encoded inside the ('Provisioning-Data') TLV.¶
If the type of credentials is symmetric and the parameters call for server-side generation of a symmetric key share, the Server MUST also include its own generated share in a ('Credentials- Data') TLV inside the ('Provisioning-Data') one (the data for the provisioning protocol are encapsulated in the 'Provisioning-Data' TLV for any protocol used during Phase Two - SPP is no exception to this rule).¶
In case Server-side only is selected, the Server MUST send the new credentials in its message and include the ('Credentials-Info') TLV. If no other credentials need to be managed, the Server MUST end Phase Two by setting the appropriate bits in the EAP-CREDS headers as well.¶
The last message of SPP is from the Server and it is used to deliver the finalized value of the credentials and/or associated metadata. In case the credentials being provisioned are Certificate-based, the Server MUST include the issued certificate in its reply. The issued credentials shall be encoded in a ('Credentials-Data') TLV inside the ('Provisioning-Data') one. In case that the selected format supported/selected by the Peer and the Server does not provide the possibility to encode the full chain (i.e., intermediate and Root CAs) in the response, the Server MUST add one ('Certificate-Data') TLV for each certificate in the chain (including the Root CA's certificate).¶
The Server MUST include the ('Credentials-Info') TLV in its message. This provide the Peer with some additional data (e.g., the 'Profile' or the 'Identifier' associated with the credentials that were provisioned/managed).¶
In the case where additional credentials need to be managed, the Server can continue Phase Two by issuing a new [1] message where the tuple Action/Credentials must be unique for the current EAP- CREDS session.¶
The Server can now decide to start Phase Three (suggested if new credentials were provisioned or renewed) or to terminate the EAP session successfully.¶
,--------. ,----------.
|EAP Peer| |EAP Server|
`---+----' `----+-----'
| [1] EAP-Request/EAP-CREDS(Type=Provisioning) |
| { Protocol(=SPP), Action, [ Creds-Info ], |
| [ Prov-Params ], [ Profile ] |
| [ Prov-Data(=[Creds-Info],[Creds-Data]) ] }|
| <-----------------------------------------------
| |
| [2] EAP-Response/EAP-CREDS(Type=Provisioning) |
| { [ Prov-Data(=[Creds-Data]) ] } |
| ----------------------------------------------->
| |
| [3] EAP-Response/EAP-CREDS(Type=Provisioning) |
| { [ Prov-Data(=Creds-Info,[Creds-Data]) ] } |
| <-----------------------------------------------
| |
| |
¶
EAP-CREDS/SPP can provision symmetric secrets (e.g, username/ password, API keys, or SIM-based keys), tokens (e.g., username/ password OAuth or Kerberos tokens), or asymmetric credentials (e.g., X.509 certificates or Key Pairs). This section focuses on provisioning symmetric secrets only. The message flow is provided in Section 7.2.1¶
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 (see Section 4.3.13).¶
[ TO BE EDITED ]¶
Figure 1: SPP Message Flow for Server-Side only secrets provisioning¶
The message flow for deploying a server-side only credential (i.e., during registration or renewal) consists of only one message from the server. The flow is depicted in Figure 1.¶
In this case, the Server sends the first Provisioning message (which is also the last one), which MUST carry, the following data:¶
The Server also includes, encoded in the ('Provisioning-Data') TLV, the following data:¶
Server-side secrets' generation can be used to generate username/ password combinations, API Keys, SIM-based credentials, or tokens.¶
[ TO BE EDITED ]¶
Figure 2: SPP Message Flow for Client-Side only secrets provisioning¶
The message flow for deploying a client-side only credential (i.e., during registration or renewal) consists of the full three messages exchange. The flow is depicted in Figure 2.¶
In this case, the Server MUST include, in its first Provisioning message and encoded in the ('Provisioning-Data') TLV, the following data:¶
Notice that the Server does not include any ('Credentials-Data') TLV in its first message because the Server is not involved in the secret generation (client-side only).¶
The Peer MUST reply with its own Provisioning message where the Peer MUST encode the following data in the ('Provisioning-Data') TLV:¶
The credentials data MUST conform to the specifications the Server provided in the ('Provisioning-Params') TLV.¶
The final message is from the Server and it MUST contain (if no errors were detected), the following TLVs encoded, as usual, in the ('Provisioning-Data') TLV:¶
Client-side secrets' generation should be used with caution and an evaluation of the quality of the generated credentials MUST be performed to make sure that the security of the generated secret is adequate for accessing the network. Since evaluating the quality of a secret is quite a difficult tasks, the use of this generation mode MUST be evaluated carefully and selected accordingly to acceptable risk profiles.¶
When registering or renewing credentials and the secret generation is split between the Server (1st share) and the Peer (2nd share), the message flow is the same as Section 7.2.1.2 with the following exceptions:¶
All other parameters remain the same.¶
Co-generation of the secret is the most secure option because both parties can provide the required randomness in their own share of the secret.¶
EAP-CREDS/SSP defines the following flow of messages for requesting the provisioning of key pairs (public and private keys).¶
[ This case covers the server-side generation of KeyPair and Certificate ]¶
[ This case covers the registration of a self-signed or already available (e.g., device) certificate ]¶
This use-case is not supported. In other words, for the provisioning of Key Pairs, the ('Provisioning-Params') can not have both the peer- generation and server-generation bits set.¶
EAP-CREDS/SSP defines the following flow of messages for requesting the provisioning of credentials.¶
[ This case covers the server-side generation of KeyPair and Certificate ]¶
[ This case covers the registration of a self-signed or already available (e.g., device) certificate ]¶
[ This case covers the generation of the KeyPair on the Peer and the generation of the certificate on the Server ]¶
EAP-CREDS/SSP defines the following flow of messages for requesting the provisioning of token-based credentials.¶
[ This case covers the server-side generation of the Token and possibly associated key ]¶
[ This case covers the registration of a self-signed or already available (e.g., device) certificate ]¶
[ This case covers the generation of the KeyPair on the Peer and the generation of the Token that cointains the reference to the key on the Server ]¶
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 |
| 4 | Certificate |
| 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#10 |
| 3 | PKCS#12 |
| 4 | 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 | Data Type |
|---|---|
| 0 | Not Specified |
| 1 | EAP-CREDS-ASYMMETRIC |
| 2 | EAP-CREDS-SYMMETRIC |
Assignment of new values for new Message Types MUST be done through IANA with "Expert Review" as defined in [RFC8126].¶
| ID | Data Type |
|---|---|
| 0 | Vendor-Specific |
| 1 | Manufacturer Usage Description [RFC8520] |
| 2 | Network Access Granting System |
| 3 | Firmware Manifest |
| 4..127 | Reserved for Future Use |
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].¶
| Type | Description |
|---|---|
| 0 | Binary (Unspecified) |
| 1 | MUD File |
| 2 | TEEP Manifest |
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.¶