Credentials Provisioning and Management via EAP (EAP-CREDS)

Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Introduction Many environments are, today, moving towards requiring strong authentication when it comes to gain access to networks. 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. 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. 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 tunneling 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.

Overview of existing solutions Currently there are many protocols that address credentials lifecycle management. In particular, when it comes to digital certificates, some of the most deployed management protocols are: Certificate Management Protocol (CMP) , Certificate Management over CMS (CMC) , Enrollment over Secure Transport (EST) , 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.

Scope Statement This document focuses on the definition of the EAP-CREDS method to convey credentials provisioning and managing messages between the client and the AAA server. Moreover, the document defines how to encode messages for the main IETF provisioning protocols. This document, however, does not provide specifications for how and where the credentials are generated. In particular, the credentials could be generated directly within the AAA server or at a different location (i.e., the Certificate Service Provider or CSP) site. Different authentication mechanisms (e.g., TLS, etc.) can be used to secure the communication between the server's endpoint and the CSP. Examples and details of how to use EAP-CREDS encapsulation mechanism with specific protocol are out of scope of this document. For more details of using EAP-CREDS method with Simple Provisioning Protocol (SPP), please refer to EAP-CREDS with Simple Provisioning Protocol (SPP) . For more details of using EAP-CREDS method with Certificate Management Protocol (CMP), please refer to EAP-CREDS withwith Certificate Management Protocol (CMP) . These two documents can be used as the template for other protocols' encapulation with EAP- CREDS.

EAP-CREDS as tunneled mechanism only EAP-CREDS requires that an outer mechanism is in place between the Peer and the Server in order to provide authentication and confidentiality of the messages exchanged via EAP-CREDS. In other words, EAP-CREDS assumes that an appropriately 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.

Fragmentation Support 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.

Encapsulating Provisioning Protocols in EAP-CREDS In order to use EAP-CREDS together with your favorite provisioning protocol, the messages from the provisioning protocol need to be sent to the other party. In EAP-CREDS, this is done by encoding the provisioning protocol messages inside the ('ProtoData') 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 ('ProtoHeaders') 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' (Done) 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 ('Params') or the ('Creds-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.

Algorithm Requirements 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.

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

EAP-CREDS Notation

EAP-CREDS Protocol 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 .

Message Flow 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.

Phase One (Required). Initialization. During this phase the Peer: and the Server exchange the information needed to select the appropriate credentials management protocol. Phase One flow is composed by only messages. In particular, the Sever sends its initial message of type ('EAP-CREDS-Init'). The Peer replies with the details about which provisioning protocols are supported, and additional information such as the list of installed credentials and, optionally, authorization data (for new credentials registration).
Phase Two (Optional). Provisioning Protocol Flow. In this phase,: the Peer and the Server exchange the provisioning protocol's messages encapsulated in a EAP-CREDS message of type Provisioning. The messages use two main TLVs. The first one is the ('ProtoHeaders') TLV which is optional and carries information that might be normally conveyed via the transport protocol (e.g., HTTP headers). The second one is the ('ProtoData'), which is required and carries the provisioning protocol's messages. The server can decide to repeat phase two again to register new credentials or to renew a separate set of credentials by issuing a new ('Provisioning') message for the new target. When no more credentials have to be managed, the Server can start phase three or simply terminate the EAP session.
Phase Three (Optional). Credentials Validation. This optional phase: can be initiated by the server and it is used to validate that the Peer has properly installed the credentials and can use them to authenticate itself. Depending on the credentials' type, the messages can carry a challenge/nonce, the value of the secret/ token, or other information. The format of the credentials is supposed to be known by the provider and the device.

Phase Transitioning Rules 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 , the 'S' (Start) 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' (Start) bit is meaningful only in messages sent by the Server. The value of the 'S' (Start) 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' (Start) bit to '1' and the 'Phase' field to the current phase number (e.g., 0x01 for phase one, 0x02 for phase two, or 0x03 for phase three). In case the first message of a phase is to be repeated (e.g., because of processing multiple credentials), the 'S' (Start) bit SHALL be set to '0' (i.e., it should be set to '1' only on the first occurrence and set to '0' in subsequent messages).

Phase One: Initialization

The following figure provides the message flow for Phase One:

| | | [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 ], | |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): ]]>

: 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, the Server sends an EAP-Request/EAP-CREDS(Type=Init) message to the Peer with the 'S' (Start) bit set to '1' and the Phase field value set to '0x01' (thus indicating the beginning of Phase One) as described in . Also, the Server MAY use one or more ('Version') TLVs to indicate the supported versions.

: The Server MAY also specify which versions of EAP-CREDS are supported by adding zero, one or more ('Version') TLVs. If no ('Version') TLV is added to the message, the Peer SHOULD assume the supported version is 1 ('0x01').

: Optionally, the Server MAY also send a ('Challenge-Data') TLV which includes chanllenge data value (usually some random value) and a specified challenge type. The Peer MUST use the specified type and use chanllenge data value for calculating the ('Challenge-Response') TLV.

[2] The Peer sends EAP-Response/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 ('Creds-Info') TLVs for each installed credentials 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 ('Creds-Info') TLV for each of them). The Peer MAY also provide the list of supported Encodings and Formats by adding one or more ('Encoding') and ('Formats') TLVs. The Peer MAY also provide the Server with information about the Peer's credentials storage by using the ('Storage-Info') TLV. When there are no available 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') 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. For example, suppose a public key hash is present in the Token, 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') 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. Also, the ('Net-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. 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 ('Creds-Info') TLV sent by the Peer (e.g., a credential is about to expire or a credential is simply missing).

Phase Two: Provisioning The following figure provides the message flow for Phase 2: | | . . . . . . . . | [N] EAP-Response/EAP-CREDS(Type=Provisioning) | | { [ Creds-Info ], [ ProtoData ], | | [ ProtoHeaders ] } | | <---------------------------------------------- | | | [N+1] EAP-Request/EAP-CREDS(Type=Provisioning)| ,---------!. | { [ ProtoData ], [ ProtoHeaders ] } | |Phase Two|_\ | ----------------------------------------------> |Ends | | | `-----------' | | EAP-CREDS Phase Two Message Flow ]]>

[1] The Server sends EAP-Request/EAP-CREDS(Type=Provisioning): The first message of Phase Two indicates that the Server is ready to initiate the selected provisioning protocol.This message contains the parameters of the selected provisioning protocol in the ('Params') (e.g., algorithm for generating credentials), the description of installed credentials in the ('Creds-Info'), the selected provisioning protocol's message data and some extra fields (e.g., transport-protocol headers) in the ('ProtoData') and its content in ('ProtoHeaders') TLVs respectively.
[2] The Peer sends EAP-Response/EAP-CREDS(Type=Provisioning): After that, the Peer sends its first message to the Server by sending the EAP-Response/EAP-CREDS(Type=Provisioning) message. This message contains the selected provisioning protocol's message data and some extra fields (e.g., transport-protocol headers) in the ('ProtoData') and its content in ('ProtoHeaders') TLVs respectively.
[N=3] The Server sends EAP-Request/EAP-CREDS(Type=Provisioning): The Server replies to the Peer's message with EAP-Request/EAP- CREDS(Type=Provisioning) messages until the provisioning protocol reaches an end or an error condition arise (non-recoverable).
[N] The Server sends EAP-Request/EAP-CREDS(Type=Provisioning): When the provisioning protocol has been executed for the specific set of credentials, the server sends a last message that MUST include the description of the provisioned credentials in a ('Creds-Info') TLV and MUST set the 'D' (Done) bit in the EAP- CREDS message header to '1' to indicates that the server does not have any more ('Type=Provisioning') messages for this credenital. The final message does not need to be an empty one, i.e. other TLVs are still allowed in the same message (e.g., the 'ProtoData' and the 'ProtoHeaders' ones).
[N+1] The Peer sends EAP-Request/EAP-CREDS(Type=Provisioning): The Peer MUST reply to the server with a ('Type=Provisioning') message that MUST have the 'D' (Done) bit in the EAP-CREDS message header set to '1', thus indicating that the credentials have been installed correctly. In case of errors, the Peer MUST include the appropriate ('Error') TLV. Also in this case, the final message does not need to be an empty one, i.e. other TLVs are still allowed in the same message (e.g., tthe 'ProtoData' and the 'ProtoHeaders' ones).

At this point, the Server can decide to provision (or manage) another set of credentials by issuing a new ('Type=Provisioning') message, or it can decide to start Phase Three by sending its first ('Type=Validate') message, or it can terminate the EAP session.

Phase Three: Validation

The following figure provides the message flow for Phase 3:

|Ends | | | `-------------' | | EAP-CREDS Phase Three Message Flow ]]> Phase three is optional and it is used by the server to request the client to validate (with proof) that the new credentials have been installed correctly before issuing the final EAP-CREDS Success message.

: NOTE WELL: Phase Three introduces a dependency on the selected hashing algorithm to provide common and easy way to check the integrity and functionality of a newly installed set of credentials.

[1] The Server sends EAP-Request/EAP-CREDS(Type=Validate)

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 ('Creds-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 in ('Challenge-Data') for the peer to calculate ('Challenge- Response'). EAP-CREDS defines the asymmetric and symmetric challenges in and others can be defined according to the specified rules. As usual, the Server MUST set, in the headers, the 'S' (Start) bit to '1' in its first message of Phase Three and the 'Phase' value shall be set to '3' (beginning of Phase Three).

[2] The Peer sends EAP-Response/EAP-CREDS(Type=Validate)

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 types', 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 . The format of the signature in the ('Challenge-Response') TLV is the concatenation of:

The signatureAlgorithm (DER encoded) which contains the identifier for the cryptographic algorithm used by the Peer to generate the signature using , , and list supported signature algorithms. Other signature algorithms MAY also be supported. The definition of the signatureAlgorithm is provided in Section 4.1.1.2 of .
The signatureValue (DER encoded) which contains the digital signature itself. The signature value is encoded as a BIT STRING and the details of how to generate the signatures' structures can be found in Section 4.1.1.3 of and referenced material.

Symmetric Secret

For any symmetric based credentials (e.g., password or Key), the response to the challenge is calculated by using the selected hash function (see ) 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 . Other types of challenges MAY be defined according to the specified procedures. 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).

EAP-CREDS Message Format The EAP-CREDS defines the following message types:

EAP-CREDS-Init
EAP-CREDS-Provisioning
EAP-CREDS-Validate

Each of these message types have the basic structure as identified in . EAP-CREDS messages contain zero, one, or more TLVs. The internal structure of the different types of TLVs is described in , while a detailed description of the EAP-CREDS message types is provided in .

Message Header The EAP-CREDS messages consist of the standard EAP header (see Section 4 of ), followed by the message payload of the EAP- CREDS. The header has the following structure: Where the Code, Identifier, Length, and Type fields are all part of the EAP header as defined in . 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 used for fragmentation instead of the message length: the message length is carried in the 'Message Length' field if Jumbo Message is indicated in the header. 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' (Start) 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 meanings of the bits in the 'Flags' field are as follows:

: Bit 'J' (Jumbo Message) - If set, it indicates the presence of the 'Message Length' field. This bit SHALL be used only when the size of the message exceeds the maximum value allowed in the 'Length' field. In this case, the 'Message Length' field is added to the message and set to the whole message size and the 'Length' field is used for the current fragment length. If not set, the 'Message Length' field is not present in the Message and the 'Length' field is used for the message size (and the 'F' (Fragment) bit MUST be set to '0').

: Bit 'S' (Start) - If set, this message is the first one of a new EAP-CREDS phase. The value of the new phase is encoded in the 'Phase' field.

: Bit 'F' (Fragment) - If set, this message is a fragment of a message. In this case, the 'Data' field is to be concatenated with all messages with the 'F' (Fragment) bit set to '1' until the message with the 'F' (Fragment) bit set to '0' that indicates the end of the message. If the message is not fragmented, the 'F' (Fragment) bit MUST be set to '0'. The use of this bit is required when the tunneling method does not provide support for messages up to 2^32 bits in size.

: Bit 'D' (Done) - This bit is used in Phase Two and Phase Three to indicate that the specific operation for the identified credential is over. For example, when multiple credentials exist on the Peer and the Server needs to manage and validate one of them. In its last message, when the provisioning protocol is done, the server sets the 'D' (Done) bit to indicate that it is done. The Peer, in its reply, sets the bit to indicate the end of provisioning for this credentials is also over. After that, the Server can continue Phase Two, transition to Phase Three, or terminate the EAP session.

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:

: 0x01 - Phase One

: 0x02 - Phase Two

: 0x03 - Phase Three

A detailed explanation of the 'Phase' and 'Flags' fields of the message headers is provided in . The Data field is the message payload. The full description of this field is provided in the next section.

Message Payload 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:

: This field is used to indicate the type of data that the TLV carries. The type of TLV determines its internal structure. The supported values for this fields are provided in the following table:

Length (uint24): This field carries the size of the value of the TLV. In particular, the overall size of a TLV (i.e., the header plus the value) can be calculated by adding the size of the header (6 octets) to the value of the Length field (i.e., the size of the TLV's value).

EAP-CREDS Supported TLVs Types

TLV Name	TLV Type	Scope/Usage
<TBD>	Action TLV	Phase Two
<TBD>	Certificate-Data TLV	Phase Two
<TBD>	Challenge-Data TLV	Phase Two, Phase Three
<TBD>	Challenge-Response TLV	Phase Two, Phase Three
<TBD>	Credentials-Data TLV	Phase Two
<TBD>	Creds-Info TLV	Phase Two, Phase Three
<TBD>	Error TLV	All Phases
<TBD>	Net-Usage TLV	Phase One
<TBD>	Profile TLV	Phase Two
<TBD>	Protocol TLV	Phase One, Phase Two
<TBD>	ProtoData TLV	Phase Two
<TBD>	ProtoHeaders TLV	Phase Two
<TBD>	Params TLV	Phase Two
<TBD>	Token TLV	Phase One
<TBD>	Version TLV	Phase One

TLV Value ( > 1 octet ): This field carries data for the identified TLV. The internal structure is determined by the TLV Type field.

The rest of this section describes the structure of the different supported TLVs and their usage in the different messages.

EAP-CREDS defined TLVs EAP-CREDS messages's payload comprises 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.

The Action TLV - Action TLV TLV Length (uint24) Fixed value (=2) Flags (uint8) Reserved ]]>

The Challenge-Data TLV - Challenge-Data TLV Length (uint24) 3 octets Challenge Type (uint8) ]]>

: This field carries the type of Challenge. In particular, the challenge type determines how the Peer MUST calculate the ('Challenge-Response'). The initial values for this field are listed in . Please refer to for a detailed explanation of how to calculate the response to the challenge for the challenge types defined in this document.

Challenge Data (> 1 octet): This field carries the data to be used as a challenge when validating newly deployed credentials.

The Challenge-Response TLV - Challenge-Response TLV Length (uint24) 3 octets Challenge Response (> 1 octet) ]]>

: This field carries the data that resulted from the use of the credentials to be validated.

The Creds-Info TLV The Creds-Info 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 ('Creds-Info') from the Peer and eventually selects the right one for renewal. The TLV structure is as follows:

TLV Type (uint8)

<TBD> - Creds-Info TLV

Length (uint24)

Provides the total length of the body of the Creds-Info TLV.

Flags (uint8)

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

CredType (uint8)

This field provides the description of the type of credential. The type of credentials are listed in

ProtoID (uint16)

This field indicates the protocol that was used to retrieve the target credential. When the TLV is used in a Request by the Server, this field is ignored. The values for this field are listed in .

IssuedOn (16 octets)

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

Where:: 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'

ExpiresOn (16 octets)

This field carries the GMT date for when this credential is to be considered expired. 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. The format is the same as the ('IssuedOn') field. When the value is not set, the field should be set to { 0x00 }.

Credentials Length (uint32)

Length (in bytes) of the Credentials value. When used with a public-key type of credentials, this is the size of the key (e.g., for an RSA 2048 bit keys, this field should carry the value of 256). When used with a symmetric secret, this field carries the size of the secret (in bytes).

CredIDValue (> 1 octet)

The binary value of the credentials' identifier. This identifier can be the binary value of the SHA-256 calculated over the certificate, a username, or it could be a random handle. As long as the ID allows the peer and the server to uniquely (in its context) identify the credentials, the value of this field can be calculated in any way.

The Error TLV - Challenge-Response-Data TLV Length (uint24) 3 octets EAP-CREDS Error Code (2 octets) ]]>

: This field carries the EAP-CREDS error code. These code are related to the EAP-CREDS operations only and it should not be used to carry the Provisioning-Protocol specific error codes.

: The error codes supported by this specifications are listed in .

Secondary Error Code (2 octets): This field is used to convey an error at the encapsulation layer (i.e., the provisioning protocol error). For example, this field can be used to convey a transport protocol error code (e.g., HTTP status code). Do not use this field to convery EAP-CREDS specific errors.
Description ( > 1 octet): The Description field is optional (i.e., when the Description Size is set to zero) and carries information about the error that occurred. The message may or may not be used by a user or an automated process for debugging purposes.

The Net-Usage TLV - Net-Usage TLV Length (uint24) Variable Length TLV (Value must be > 2 ) Desc Format (7 bits) ]]>

: This field provide the expected data format for the Net-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 initial values for this field are listed in .

Encoding (uint8): Provides the indication of the Encoding the network usage description data is in. The allowed values for this field are listed in .
The 'U' field (1 bit): The 'URL' bit ('U') is used to indicate if the value of the Net- 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 Net-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 Net-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 . In this case, the Peer can set the Net-Usage Data field to the URL of the MUD file related to the Peer.
Net-Usage Data (octet string): 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.

The Profile TLV - Profile Identifying Data TLV Length (uint24) Length value should be >= 1 Profile Identifier (octet string) ]]>

: The Profile Identifier is used to provide indication to the other party about which profiles are supported when requesting credentials management.

: Also in this case, the data used in this field is left to be interpreted by the end-point and it is independent from the EAP- CREDS data types. This could be a raw byte value, a string, or a more complex structured data (e.g., an OID).

: An example of values for this field, an end-point could use the string representation (i.e., dotted representation) of the Object Identifier (OID) of the specific profile supported (e.g., could be defined in the Certificate Policy of the credentials' provider).

The Protocol TLV - Protocol TLV TLV Length (uint24) Fixed TLV Length value of 4. Protocol ID (uint16) ]]>

: The Protocol ID value carries the id of a supported provisioning protocol. The initial list of values for the provisioning protocol identifiers can be found in .

Version (uint16): The Version (Protocol Version) value represents the specific version of the identified provisioning protocol. When no version is specified for a protocol (i.e., either it does not support multiple versions or it does not matter), the value of this field should be set to '0x0'.

The ProtoData TLV - ProtoData TLV Length (uint24) 3 octets Headers Data (> 1 octet) This field carries the provisioning protocol's messages. ]]>

The ProtoHeaders TLV - ProtoHeaders TLV Length (uint24) 3 octets Headers Data (> 1 octet) ]]>

: This field carries the meta-data (if any) that might be associated with the transport-layer normally used with the provisioning protocol. For example, this TLV can carry the set of HTTP headers required by EST or ACME.

The Params TLV - Params TLV Length (uint24) Provides the length of the TLV (>= 6 octets) Min Length (uint16) ]]>

: Provides the minimum allowed size size for the credentials. This value has meaning depending on the context of the credentials, however sizes are always expressed in bytes.

: For example, when used with a symmetric key or a password, the ('Min Length') and ('Max Length') refer to the minimum and maximum size of the password data. The ('Algor OID') field can be omitted in this case.

: On the other hand, when referring public-key credentials, this field should carry the size of the modulus of the key. For example, for an RSA 2048 bit keys, the field should carry the value of 256. For an ECDSA that uses the prime256r1 curve, this field should carry the value of 32 and the Algor OID should be the DER representation of the specific value of the curve (i.e., the DER representation of '1.2.840.10045.3.1.7').

Max 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.
Algorithm (uint8): Provides the indication of the algorithm used for the generation of the credentials. The allowed values for this field are listed in .
Flags (uint8): 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 pass-phrases that use the full 8-bit character set (on client and server) to maximize the secret's search space.
Object Identifier (binary; > 1 octet): Provides the indication of additional parameters that are needed to be encoded for the credentials. This value is used only when the credentials use public-key cryptography - this field carries additional information about the generation algorithm to be used. We provide some useful values that can be used as reference:

Object Identifiers Examples

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

The Token TLV - Token TLV TLV Length (uint24) Provides the length of the TLV (> 3 octets) Token Type (uint8) ]]>

: Provides the indication of the type of credentials. The allowed values for this field are listed in .

Encoding (uint8): Provides the indication of the Encoding the credentials are in. The allowed values for this field are listed in .
Value (octet string): This field carries the data for the credentials.

The Version TLV - Version TLV TLV Length (uint24) ]]>

: Provides the length of the TLV. The field has a fixed value of 1.

Version (uint8): 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).

EAP-CREDS Messages This section describes each message and what TLVs are allowed or required. EAP-CREDS defines the following values for the Message Type (Type): EAP-CREDS Message Types

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 The EAP-CREDS-Init message type is used in Phase One only of EAP- CREDS. The message flow is depicted in . This message supports the following TLVs: Version, Protocol, Creds-Info, and Error.

EAP Server's Init Message 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' (Start) bit to '1' (Start) and the headers' 'Phase' value to '1' (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 implicit 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.

EAP Peer's Init Message 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 'Creds-Info' TLV). The Peer MAY include authorization data when registering new credentials (e.g., an authorization token or a device certificate) via the ('Token') and ('Challenge-Response') TLV. The Peer MUST include one ('Creds-Info') TLV for each credential the Network is authorized to manage. Typically, a Peer will include only one ('Creds-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 ('Creds-Info') TLV - leaving the Server with the only action possible: Registration. In this case, the Peer SHOULD include authorization information via the ('Token') TLV as described in . Additionally, the Peer can add the ('Profile') TLV to indicate a preferred profile for the credentials.

Bootstrapping Peer's Trustworthiness When the Peer does not have any valid credentials for the Network that it is authenticating to, it does not provide any ('Creds-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 mechanism 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') 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 The EAP-CREDS-Provisioning message type is used in Phase Two only of EAP-CREDS. The message flow is depicted in . This message type supports the following TLVs: Protocol, Profile, Creds- Info, ProtoHeaders, ProtoData, Token, 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' (Start) bit MUST be set to '1' (Start) and the 'Phase' value set to '2' (Phase Two begins).

: NOTE WELL: After the initial message, the only TLVs that are allowed in messages coming from the server are the usual ('ProtoHeaders') ('ProtoData'), and ('Error').

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 ('ProtoHeaders') and ('ProtoData') 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 The EAP-CREDS-Validate message type is used in Phase Three only of EAP-CREDS. The message flow is depicted in . This message type supports the following TLVs: Protocol, Creds-Info, ProtoHeaders, ProtoData, Token, 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 ('Creds-Info'), a ('Challenge-Data'), and the ('Phase') fields in a EAP-Request/EAP- CREDS(Type=Validate) message. The ('Phase') field should carry the '1' value for the 'S' (Start) bit (Start) and the number '3' for its value (Phase Three begins). 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-Data') 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 include the ('Phase') field with the 'S' (Start) bit set to '0' (end of phase) and the value set to '3' (Phase Three ended). 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).

Error Handling in EAP-CREDS This section provides a description of the error handling by using the CREDS-Error-TLV in a CREDS message. <TBD>

IANA Considerations This document uses a new EAP type, EAP-CREDS, whose value (TBD) MUST be allocated by IANA from the EAP TYPEs sub-registry 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 . 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.

Provisioning Protocols EAP-CREDS Inner Protocol Identifiers

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 .

Token Types Token Types in ('Token') TLV

Token Type	Description
0	Unspecified
1	JWT
2	Kerberos
3	OAuth
4	Certificate
200..254	Vendor Specific