| Internet-Draft | EAP-FIDO | December 2023 |
| Rieckers & Winter | Expires 9 June 2024 | [Page] |
This document specifies an EAP method leveraging FIDO2 keys for authentication in EAP.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-janfred-eap-fido/.¶
Discussion of this document takes place on the EAP Method Update Working Group mailing list (mailto:emu@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/emu/. Subscribe at https://www.ietf.org/mailman/listinfo/emu/.¶
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 9 June 2024.¶
Copyright (c) 2023 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 Extensible Authentication Protocol (EAP) [RFC3748] is a widely used standard that allows a server to authenticate a client using different authentication methods. There is a huge variety of EAP methods available, that serve different purposes and have different security implications.¶
Two common EAP methods are EAP-PEAP and EAP-TTLS [RFC5281], that both use EAP-TLS [RFC5216] to provide confidentiality of the inner authentication. This inner authentication is most commonly password-based, meaning that an attacker that manages to compromise the TLS connection can eavesdrop on the authentication and observe the password. The authentication of the server to the client within the TLS handshake thus is a vital security function of these EAP methods.¶
The operational praxis has shown that this is a common problem and possible flaw. The specification for EAP-TLS [RFC5216] does not include guidance on how to decide if a certificate is valid for this specific authentication. Instead it assumes the client has knowledge of the expected server name. Since most clients do not have this knowledge beforehand and no implicit way to determine this implicitly from other configuration, this has lead to user interfaces, where the default setting for certificate validation was set to "Do not validate". To successfully configure the validation, the users need to know the correct server name. Failure to configure this or not configuring it at all could again lead to an attacker being able to compromise the TLS connection and, as a result, also the password sent in the inner authentication. Server administrators also need to choose their server certificate based on this and need to communicate the parameters to their users.¶
There are two major issues here, that this specification wants to address. Firstly, the use of passwords as authentication method implies that the password needs to be sent to the server. If an attacker observes this exchange, they can impersonate the user at any time. Therefore, this specification uses FIDO authentication, which is based on asymmetric cryptography. With this method, even if an attacker is able to compromise the TLS connection, they cannot impersonate the user based on the observed data.¶
The second major issue is the missing implicit derivation regarding certificate validation. With EAP-FIDO, the supplicants now have a clear specification on how to decide whether or not a server certificate is considered valid for the current authentication flow. This is achieved by using the trust anchors available on most devices and a method to determine the valid server name based on implicit information of the authentication configuration.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses terminology from EAP, as well as terminology from CTAP and WebAuthn. There is some terminology that is ambiguous in the different contexts, to disambiguate it, the following terminology will be used in this document. These terms will always be capitalized as shown here.¶
Authenticator as specified by [WebAuthn], Section 4: a cryptographic entity, existing in hardware or software, that can register and later assert possession of the registered key credential.¶
a public key credential source that is discoverable and usable in authentication ceremonies where the Relying Party does not provide any Credential IDs. See [WebAuthn], Section 4¶
a public key credential source that is only usable in an authentication ceremony where the Relying Party supplies its Credential ID. This means that the Relying Party must manage the credential's storage and discovery, as well as be able to first identify the user in order to discover the Credential IDs to supply tho the EAP Supplicant.¶
The EAP-FIDO protocol comprises two phases: the TLS handshake phase and FIDO-exchange phase.¶
During the TLS handshake phase, TLS is used to authenticate the EAP-FIDO server to the client.¶
During the FIDO-exchange phase, the actual FIDO authentication is executed and the client authenticates itself to the server.¶
Once the FIDO exchange is completed successfully, the client and server can derive keying material from the TLS handshake phase implicitly.¶
During the TLS handshake phase, the client and server establish a TLS tunnel. This is done using EAP-TLS [RFC5216], [RFC9190], [RFC9427] with the modifications described in Section 4.2.4. As part of the TLS handshake protocol, the EAP-FIDO server will send its certificate along with a chain of certificates leading to the certificate of a trusted CA. The client will check this certificate using the rules in Section 4.2.5.¶
Once the TLS tunnel is established, the client and server proceed to the FIDO-exchange phase to perform the authentication of the client.¶
In this phase, the TLS record layer is used to securely tunnel information between the EAP-FIDO client and EAP-FIDO server.¶
For the FIDO-exchange phase, the client has two options, depending on the configuration and the capability of the FIDO token.¶
If the FIDO Authenticator supports Discoverable Credentials and EAP-FIDO is configured to use these for authentication, the client generates a challenge from the TLS keying material and triggers a FIDO challenge.¶
If the client is not configured to use Discoverable Credentials, the client first needs to send its username to the server. The server will answer with a list of FIDO Credential IDs and the client will attempt to use one of these keys to authenticate.¶
This section describes the preconditions and the configuration needed for EAP-FIDO, the protocol flow and the message format¶
In order to successfully perform an EAP-FIDO authentication, the server and the client have to meet some preconditions and need to have a configuration.¶
EAP-FIDO assumes that the FIDO Authenticator is already registered with the server, that is, the EAP-FIDO server has access to the public key used to verify the authenticator's response as well as the corresponding credential id.¶
On the client side, the supplicant must be configured with the Relying Party ID (see Appendix B.1, and, if Server-Side Credentials are used, with a Username.¶
The packet format for EAP-FIDO messages follows the format specified in [RFC5216], Section 3 with the following modifications:¶
The Type field is set to TODO [awaiting IANA early allocation] (EAP-FIDO)¶
Within the Flags field, the Version bits are set to the major version of EAP-FIDO. For this specification, the version is 0. Future EAP-FIDO versions MAY increase the version number.¶
In the first packet from the server to the client, the S-bit of the Flags MUST be set, indicating the start of the EAP-FIDO protocol. It MUST NOT be set in any subsequent packet.¶
Depending on the decision on the way the RPID is determined, some additional spec may be added here, see Appendix B.1.Janfred¶
The version of EAP-FIDO is negotiated in the first exchange between server and client. The server sets the highest major version number of EAP-FIDO that it supports in the V field of the flags in its Start message. In the case of this specification, this is 0. In its first EAP message in response, the client sets the V field to the highest major version number that it supports that is no higher than the version number offered by the server. If the client version is not acceptable to the server, it sends an EAP-Failure to terminate the EAP session. Otherwise, the version set by the client is the version of EAP-FIDO that MUST be used and both server and client MUST set the V field to that version number in all subsequent EAP messages.¶
Given the limited range of the V field (values 0-7), future EAP-FIDO versions MUST NOT increase the major version if there are no changes to the outer message format. Minor version updates that only affect the inner protocol flow MUST be done with means available during the TLS handshake, i.e. using Application Layer Protocol Negotiation (ALPN).¶
Each EAP-FIDO message contains a single leg of a half-duplex conversation. Since EAP carrier protocols may constrain the length of an EAP message, it may be necessary to fragment an EAP-FIDO message across multiple EAP messages.¶
The fragmentation method is described in [RFC5216], Section 2.1.5.¶
The client and server perform a TLS handshake following the specification in [RFC5216], Section 2 and [RFC9190], Section 2 with the following modifications:¶
TLS version 1.3 or higher MUST be negotiated.¶
Mutual authentication is not required. Implementations MUST support EAP-FIDO without TLS client authentication, but MAY allow it, i.e. if EAP-FIDO is used as a 2-Factor authentication method where TLS client certificates are the first factor and the FIDO authentication is the second.¶
The certificate of the server MUST be validated. The different options for validation are listed in Section 4.2.5.¶
(FIXME, depending on RPID option) The client MUST send the desired Relying Party ID for the FIDO exchange in the Server Name Indication extension.¶
(FIXME: Currently only bulletpoints, will be converted into text)¶
After the TLS handshake is completed, the client and server perform the FIDO-exchange to authenticate the client inside the TLS tunnel.¶
This section describes the message format and the protocol flow.¶
All EAP-FIDO messages in the inner authentication consist of a CBOR sequence with two elements:¶
integer to indicate the message type. Table 1 contains a list of the different message types.¶
a CBOR encoded map with attributes. A list of the different attributes, their assigned mapkey and the type are listed in Table 2.¶
| Type | Description | Sent by |
|---|---|---|
| -2 | Error | Both |
| -1 | Failure indicator | Both |
| 0 | Success indicator | Both |
| 1 | Authentication Request | Server |
| 2 | Authentication Response | Client |
| 3 | Information Request | Client |
| 4 | Information Response | Server |
| Mapkey | Type | Label | Description |
|---|---|---|---|
| 0 | UTF-8 String | Identity | User Identity (usually username) |
| 1 | UTF-8 String | Relying Party ID | See Appendix B.1 |
| 2 | Byte String | Additional Client Data | Additional Data to be signed by the FIDO Authenticator |
| 3 | Array of Byte Strings | PKIDs | List of acceptable Credential IDs |
| 4 | Byte String | Auth Data | Authdata according to [WebAuthn], Section 6.1 |
| 5 | Byte String | FIDO Signature | |
| 6 | Array of UTF-8 Strings | Authentication requirements | Sent by the server to indicate the current authentication requiremens, i.e. if user presence or user verification is required |
| 7 | Byte String | PKID | Needed to identify the credential |
| 8 | Integer | Error Code | A code describing the error |
| 9 | UTF-8 String | Error Description | An optional human-readable error description |
This message is the protected success indicator, as required by [RFC9427], Section 5.2. It is sent by the server to indicate a successful authentication. Since EAP is a strict request-response based protocol, the client needs to reply to this message, so the server can send an EAP-Success message. The client will acknowledge the reception of this packet through the acknowledgement mechanism in EAP-TLS with an EAP-TLS acknowledgement packet.¶
To achieve the compatibility with the protected success indication mechanism of other EAP methods, the attributes field of the message MUST be omitted, that is, this message is only one byte with the value of 0x00.¶
A failure indicator message signals a non-recoverable error condition for the current authentication exchange.¶
The attributes field of the message MUST contain at least the Error Code attribute and MAY contain the Error Description attribute.¶
An authentication request is sent by the server to initialize a new authentication request. With this request, the server sends along information that the client needs to perform the FIDO authentication.¶
The attributes field in the authentication request message contain the following attributes:¶
The Relying Party ID for the FIDO authentication. See Appendix B.1.¶
(Optional) Additional data to be signed by the FIDO Authenticator.¶
(Optional) A list of acceptable Credential IDs. This can be used to trigger a re-authentication of a specific credential or to provide a list of the Credential IDs for a specific user, if Server-Side Credentials are used.¶
(Optional) A list of requirements for the FIDO authentication. The possible options for this version of EAP-FIDO are "up" for requesting user presence and "uv" for requesting user verification. Clients MUST ignore any other value, to ensure forward compatibility.¶
Since this packet signals the start of a new authentication, the client MUST initialize a new authentication and MUST NOT reuse information from any previous authentication attempt, even if the previous authentication exchange was not completed. It MAY cache some data to perform sanity checks, i.e. to protect itself against misbehaving servers that try to re-initialize an authentication with the same parameters multiple times.¶
If a client has sufficient information to perform a FIDO authentication, the client sends an authentication response. The authentication response signifies the completion of one authentication. This message can be sent in response to either an Authentication Request or an Information Response.¶
The Credential ID of the FIDO Credential used to generate the signature.¶
The signed auth data as returned from the FIDO Authenticator (see [FIDO-CTAP2], Section 6.2)¶
The signature as returned from the FIDO Authenticator (see [FIDO-CTAP2], Section 6.2)¶
All three attributes MUST be present in the authentication response message.¶
If a client does not have sufficient information to perform the FIDO authentication, the client can send an information request message to the server.¶
This is the case if Server-Side Credentials are used, since the FIDO Authenticator needs the list of acceptable Credential IDs to access the actual credentials on the FIDO Authenticator.¶
With the information request the client can transmit additional information that help the server to compile this information.¶
The attributes field in the information request contains the following attributes:¶
The identity of the user (usually a username)¶
The server answers to an Information Request from the client with an Information Response.¶
This packet is used to transmit additional information to the client.¶
The attributes field in the information response can contain any attribute that is also allowed in the Authentication Request packet. If an attribute was both present in the Authentication Request and the Information Response packet, the client MUST discard the previous value(s) of this attribute that were sent in the Authentication Request and use the value(s) in the Information Response packet.¶
The Error message signals an error condition and can be sent both from client to server and vice versa. This error condition does not necessarily lead to an authentication failure, since the EAP-FIDO server may decide that the previous authentication is sufficient. (See Appendix A.6 for an example for this use case)¶
The attributes field MUST include the attribute Error Code with an error code describing the error and MAY contain an Error Description attribute with a human-readable error description.¶
The FIDO exchange phase starts with the server sending an authentication request to the client. This message is sent along with the last message of the server's TLS handshake.¶
The Authentication Request can include authentication requirements, additional client data and a list of Credential IDs.¶
The client then decides if it has sufficient information to perform the FIDO authentication. This can be done by probing the FIDO Authenticator with all information given in the Authentication Request message.¶
If the FIDO authentication is already possible at this point, the client performs the FIDO authentication process and sends an Authentication Response message with the results from the FIDO authentication to the server. This authentication flow can be used if the FIDO Authenticator has a Discoverable Credential registered for the given Relying Party ID.¶
If the client needs additional information, i.e. because it uses Server-Side Credentials and therefore needs a list of Credential IDs, the client sends an information request to the server, which includes additional information from client to help the server to fulfill the information request. In the current specification, this is namely an identifier, from which the EAP-FIDO server can perform a lookup for all registered FIDO credentials registered to this identifier.¶
Upon reception of the Information Request message from the client, the server looks up the registered Credential IDs for the given identity. Depending on the lookup, the requirements for user presence or user verification may change from the previous assumption. The found Credential IDs, and optionally also the updated authentication requirements, are then sent with the Information Response back to the client.¶
The client can now, with the additional information in the Information Response message, perform the FIDO authentication. The result of the FIDO authentication is then sent to the Server in an Authentication Response message, which includes the PKID, Auth Data and FIDO Signature from the FIDO authentication result.¶
When a server receives an Authentication Response message, it validates the FIDO data. If the FIDO authentication is successful and the FIDO key has sufficient authorization, the server sends a Success indication message to indicate the Success of the FIDO exchange phase. The client will acknowledge this packet using the EAP-TLS acknowledgement mechanism and the server sends an EAP-Success message.¶
Depending on the result of the FIDO authentication, the user presence or user verification assertions and the policy for a specific FIDO credential, the server MAY choose to trigger a second FIDO authentication with a different set of authentication requirements. This is done by sending a new Authentication Request message to the client. This message MUST include a PKIDs attribute with only the PKID of the credential used in the previous FIDO authentication process.¶
The client then triggers a new FIDO authentication process and answers with an Authentication Response message.¶
The server MUST NOT trigger a challenge with the same Credential ID and Authentication Requirements twice.¶
This section will describe the actual FIDO authentication process, that is performed between the EAP-FIDO client and the FIDO Authenticator.¶
The client will use CTAP version 2.0 or above [FIDO-CTAP2] to communicate with the authenticator.¶
The Relying Party ID (RPID) either explicitly configured, derived from the RADIUS routing realm, from the server certificate subjectAltName:DNS or sent by the server. In analogy to WebAuthn, the client needs to verify that the RPID either matches exactly the subjectAltName:DNS of the certificate or that the subjectAltName is a subdomain of the RPID. For discussion on the topic regarding the relationship RPID, SAN and RADIUS Realm, see Appendix B.1.¶
The client data is a concatenation of two items.¶
The first item is derived from the TLS keying material:¶
FIDO_CHALLENGE_TLS = TLS-Exporter("fido challenge", NULL, 32)
¶
The second item is the optional additional client data sent by the server.¶
Both items are concatenated and hashed using SHA-256. The result is the clientDataHash for the FIDO authentication.¶
This section documents several design decisions for the EAP-FIDO protocol¶
The FIDO CTAP protocol has distinct primitives for the registration and the usage of a FIDO2 credential. This specification requires that the registration of the security token has been done out-of-band, for example using the WebAuthn protocol in a browser context.¶
There are multiple degrees of freedom when registering a token with CTAP version 2. This specification recognizes the following choices at registration time, and defines how to effectuate an authentication transaction for any combination of these choices.¶
FIDO2 tokens contain a master key which never leaves the security perimeter of the token. FIDO2 tokens transact by generating asymmetric keypairs which are bound to a scope (often: a domain name, a RADIUS realm). The scoped keying material can be accessed using two different methods:¶
Server-Side Credentials: The keying material is not accessible directly, but only by providing a Credential ID that was generated during registration. Depending on the actual implementation inside the FIDO Authenticator, the Credential ID may be used as a seed to re-generate the specific key pair with the help of the FIDO Authenticator's master key. Other FIDO Authenticator implementations may store the keypair and generate a random Credential ID by which the key can be referenced. To trigger an authentication, the client must provide the correct Credential ID to the FIDO Authenticator. It is fair to assume that the number of Server-Side Credentials that a FIDO Authenticator can generate is not significantly limited, so the number of keys should not weigh in to the consideration whether or not it is worth to register a new Server-Side Credential for a given scope.¶
Discoverable Credentials: The keying material is stored on the security token itself, along with the scope for which the keypair was generated. During authentication transactions, only the scope (as configured, or as sent by the server) determines which keypair is to be used in the transaction. The key can store multiple keys for the same scope. The number of slots for Discoverable Credentials is limited, and this limit needs to be considered when deciding whether or not a new Discoverable Credential should be registered for a specific use case.¶
EAP-FIDO supports both Discoverable and Server-Side Credentials.¶
Registering a Discoverable Credential has several advantages and one disadvantage:¶
No username needs to be sent during the authentication transaction¶
The transaction requires less round-trips due to skipping the username transmission process¶
The amount of data sent from EAP server to EAP peer is significantly smaller, reducing the probability of extra roundtrips or packet fragmentation¶
The scopes of the stored credentials can be seen and enumerated by the EAP supplicant, helping the user in finding the right value for configuring the EAP realm¶
The Discoverable Credential consumes space on the FIDO Authenticator, which might be limited¶
Token registration can involve one of two levels of asserting the user presence.¶
UP (userPresence): the registration ceremony ensures that a person is present at the token while registering the device (e.g. human tissue needs to touch a physical security key while the registration transaction executes).¶
UV (userVerification): the security token registers a unique property of the user during the registration ceremony, such that it is asserted that only the exact same person can interact with the token in the future (e.g. by registering a fingerprint or facial recognition)¶
During authentication transactions, an EAP-FIDO server can request one of three levels of asserting user presence.¶
Silent (interaction with a human is not required)¶
UP (physical interaction with a person is required)¶
UV (physical interaction with the registered user is required).¶
An authentication transaction can not request a higher level than was set at registration time; i.e. a token registered in UP mode can not transact in UV mode.¶
EAP-FIDO supports all three transaction modes, and the server can signal its required minimum assertion level for each individual authentication transaction.¶
The scope of a FIDO2 key as set during the registration transaction determines the contexts in which it can be used. In EAP-FIDO, the following three notions interplay:¶
the realm of username as used in the EAP-Identity exchange ("outer ID")¶
the servername as presented during the EAP-TLS exchange by the EAP-FIDO server¶
the relyingPartyIdentifier (rpId) that is used during the FIDO CTAP client authentication phase¶
EAP-FIDO requires the registered scope to be:¶
Since there already exist EAP methods that provide a TLS tunnel and are capable of encapsulating further EAP methods, e.g. EAP-PEAP, EAP-TTLS or EAP-TEAP, the question arises, why this specification does not focus solely on the FIDO exchange as a standalone EAP method instead of re-specifying a new EAP-method that again makes use of EAP-TLS.¶
The main reason for a decision against this is the potential for misconfiguration. One of the goals for this EAP method is to provide a means to validate the server certificate using implicit configuration options. Using EAP-TTLS or EAP-PEAP would counteract this goal, since in most supplicants the configuration for the different phases of the tunneled TLS methods is done separately, so the users would have to configure the certificate check parameters manually again. Additionally, not every supplicant application may allow the code for the phase 2 exchange to access information about the phase 1 exchange, namely the server certificate parameters, which is necessary for the security of the EAP-FIDO exchange. Specifying EAP-FIDO as standalone EAP methods could therefore require modifying the EAP stack. Implementers might be tempted to re-use the insecure and error-prone configuration interfaces. To prevent this from the start, EAP-FIDO specifies an EAP-TLS based EAP method that cannot be used standalone.¶
Although this requires potentially duplicate code for supplicants that support multiple EAP-TLS based methods, the authors believe this means of specification to be more resistant against implementation errors and prevent error-prone user interfaces.¶
Note to RFC editor: Remove this section, as well as the reference to [RFC7942] before publication¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
There is one early prototype proof-of-concept implementation of EAP-FIDO into hostap (hostapd for the server side, wpa_supplicant on the client side) available. The implementation was done before the specification of this draft was finished and is therefore not compatible with any draft version (different message format, simplified message flow, missing security checks), but serves as a proof-of-concept for the overall principle of using FIDO to perform an eduroam login. The source code can be found under https://git.rieckers.it/rieckers/hostap/-/tree/eap_fido_poc_tnc23¶
TODO Security¶
This document has IANA actions:¶
With this use case, the server will send an Authentication Request containing only the Relying Party Id attribute.¶
The client can trigger the silent authentication with the Discoverable Credential stored on the FIDO Authenticator and includes the response from the FIDO Authenticator into the Authentication Response message.¶
The server can look up the Credential IDs in its database, verify the FIDO signature with the stored public key and, if the signature was valid, send a protected success indicator to the client. The client responds with an acknowledgement and the server sends an EAP-Success¶
With this use case, the server will modify the Authentication Request based on which RADIUS client (the Wifi Controller or the VPN appliance) sent the request.¶
If the WiFi appliance sent the request, silent auth is used, and the flow is identical with the previous use case.¶
If the request came from the VPN appliance (e.g. because the VPN is done via IPSEC with EAP), the server adds "uv" in the Authentication Requirements attribute, which triggers an UV action on the client's side.¶
The client triggers the authentication with the Discoverable Credential with user verification and responds to the server with the authentication data. The server verifies the signature, sends a success indication, the client acknowledges and the server sends an EAP-Success.¶
In this use case, the FIDO Authenticator does not have a Discoverable Credential for the Relying Party ID. Instead, the server has a list of Credential IDs stored for each username.¶
After the initial Authentication Request from the server, the client does not have enough data to trigger the FIDO Authentication, so it needs additional information.¶
The client then sends an Information Request message with its username.¶
The server looks up the username in its database and sends back a list of Credential IDs it has stored for this user with an Information Response message.¶
The client can now trigger the FIDO authentication with this list and responds with an Authentication Response, that includes the Credential ID that was actually used for this FIDO authentication.¶
The server can now verify the signature and client and server finalize the EAP method.¶
In this use case, different users have different authentication policies, i.e. employees are allowed to use silent authentication, but administrators need an authentication with user presence.¶
The server starts with an AuthenticationRequest and no authentication requirements or an empty array as authentication requirements. The client transmits its identity to the server in the Information Request message. Now the server looks up the user and their registered Credential IDs, and checks whether or not user presence verification is necessary.¶
If it is necessary, the server includes an authentication requirements attribute with the "up" value along with the PKIDs in the Information Response message. Since the client discards any previous attribute values, it now performs a FIDO authentication with user presence, and responds to the server.¶
It may be desired to force a user verification after a timespan, to ensure that the FIDO token is still in possession of the user. This timespan is specific for each token, so the check whether or not the token is still allowed to perform only silent authentication can only be done after the authentication has happened.¶
Given, a user has two registered token, one was verified recently and the other exceeded the verification timespan.¶
The server start with an authentication request, the client answers with an Information Request and the Identity, the server transmits the Information Response with the two PKIDs and the client performs the silent FIDO authentication with the "expired" FIDO token. After sending the Authentication Response, the server verifies the FIDO authentication and recognizes the expired FIDO token. Now the server sends a new Authentication Request with the PKID of the expired token and "uv" as Authentication Requirement. The client now performs the FIDO authentication again, this time with user verification and sends the Authentication Response to the server. The server stores the timestamp of the successful user verification in its database and sends the success indicator.¶
As with the previous example, in this case the FIDO token again have a token-specific timeout to allow silent authentication for a period of time after a successful user verification. Unlike in the previous example, this time there is a grace period that still allows a silent authentication for a while after the timer expired. The intention is to not kick out the user in the moment the timer expires, i.e. a user is currently not in the vicinity of the device at that time, but one would not want to kick out the user if it needs to reconnect due to poor wifi performance. Instead, the user may choose a convinient time to verify their identity/presence within this grace period.¶
The protocol flow is the same as the previous example, but this time the second Authentication Request from the server cannot be answered from the client, since the user is not performing the user verification. Instead, the client will send an Error message with error code TODO (FIDO authentication Timeout).¶
The server can now decide whether or not the silent authentication is still acceptable. If it is, meaning that the timeout for silent authentication has expired, but it is still in the grace period, it answers with a Success Indicator. If not, meaning that the grace period has expired too, the server will send a Failure Indicator with the appropriate error code.¶
Since EAP-FIDO uses TLS, it is possible to perform two-factor authentication directly with only EAP-FIDO. In this case, the client and server perform mutual authentication at the TLS layer.¶
The server can now determine the identity of the user based on the certificate and already look up the stored Credential IDs. With this lookup, the server can already include the PKIDs in the Authentication Request. The client doesn't need to send an Information Request, since it already has all information. It can immediately perform the FIDO authentication process and send the Authentication Response to the server.¶
Note to RFC Editor: Remove this section and all references from this section before publication.¶
Since this specification is an early draft, there are a lot of open questions that we want to get community feedback on.¶
FIDO needs a relying party ID to function. The question is how this RPID is determined and verified, there are several options that all have pros and cons.¶
The main thing is to have in mind, that there are three relevant parameters, that need to be put into a certain relationship:¶
the RADIUS realm (i.e. 'anonymous@dfn.de')¶
the RPID (i.e. 'eduroam.dfn.de')¶
the Server Certificate Name (usually subjectAltName:DNS, i.e. 'radius.eduroam.dfn.de', in the following abbreviated simply with SAN)¶
All these three parameters need to be in a pre-defined relationship to allow a simple and hard-to-mess-up-and-still-secure configuration. Both the client and the server have to agree on what the RPID is, in order for the FIDO authentication to succeed. If there is a defined relationship between the RPID and the certificate name (i.e. SAN needs to be a subrealm of the RPID), then the client needs to verify the certificate against exactly that. When does the client do that? What security implications does that bring? All these options need some thought.¶
The first option would be to just have the RPID as a configuration item, maybe with a default on the realm of the outer username. Adding a configuration option complicates the setup of the EAP method, but hopefully not too much. A misconfiguration of the RPID is also not that critical from a security standpoint. The effects of a misconfigured RPID are only a problem if the used FIDO key is also registered with a third party, in which case the third party could trick the client to connect to a bogous network.¶
If the RPID deviates from the realm, the client could send the requested RPID using Server Name Indication.¶
The second option would be to mandate that the RPID is equal to the realm portion of the username. This restricts options on how to use EAP-FIDO and may cause unnecessary difficulties in routing, if the convenient routing domain (e.g. the registered domain for a company) should not be used as RPID due to security concerns, or different RPIDs should be used under the same routing realm.¶
Since the RPID plays an important role in the decision whether or not the certificate sent by the server is to be trusted, the RPID should be determined before the TLS handshake. The server could determine the RPID based on the outer username and send it as payload in the EAP-TLS Start packet. This way, the client has a clear indication as to whether or not to trust the server certificate sent in the subsequent TLS handshake.¶
However, this opens up some security issues that are yet to be investigated, since the RPID could be modified by an on-path attacker.¶
With this option, the problem is that the client needs to cache the server certificate in order to determine if the RPID is valid. for the given certificate, unless the rules for certificate verification and RPID determination specify it otherwise. One possibility to circumvent this would be to allow the server certificate names and the RPID to deviate, but validate both against the realm of the outer username, e.g. a realm of example.com with a server certificate for radius.example.com and the FIDO RPID fido.example.com.¶
This, however, adds a whole lot more of security concerns, especially in environments with different independent divisions under the same domain suffix.¶
There are a lot of features, that have been brought up by several people at several occasions. This EAP method could include spec to address these problems. Also there may be FIDO-specific things that are not part of this specification.¶
It may be useful to directly include a way to signal in-band that an EAP configuration should be deleted.¶
The idea stems from the discussion at IETF 115 about EAP-DIE [IETF115-emu-minutes].¶
With EAP-FIDO it may be desirable to also allow for deletion of Discoverable Credentials. (Maybe residential Server-Side Credentials too?¶
Input on the need and specific way to achieve this is welcome.¶
Note to RFC Editor: Remove this section before publication.¶
draft-janfred-eap-fido-00:¶
Initial draft version¶
draft-janfred-eap-fido-01:¶
The document authors want to thank Alexander Clouter for the idea of a default authentication server name.¶