Ericsson

FI-02420 Jorvas Finland jari.arkko@ericsson.com

Nokia Research Center

P.O. Box 407 FI-00045 Nokia Group Finland pasi.eronen@nokia.com

Internet Extensible Authentication Protocol Working Group I-D Internet Draft EAP Service Information Channel Bindings EAP is typically used in an arrangement where the actual service (such as a wireless LAN access point) is separated from the authentication server. However, EAP itself does not have a concept of a service identity or its parameters, and thus the client usually does not authenticate any information about the service itself, even when a mutually authenticating EAP method is used. This document specifies a backward compatible extension to popular EAP methods for authenticating service related information, such as the identity and type of the offered service. A common parameter name space is created in order to ensure that the same kinds of identifiers can be authenticated independent of the choice of the EAP authentication method, retaining the EAP media independence principle.

EAP is typically used in an arrangement where the actual service (such as a wireless LAN access point) is separated from the authentication server. However, EAP itself does not have a concept of a service identity or its parameters, and thus the client usually does not authenticate any information about the service itself, even when a mutually authenticating EAP method is used. However, if a method supports channel bindings as specified in RFC 3748 it becomes possible to ensure that the client, the node providing the service, and the authentication server all have the same information about this information. This does not, by itself, ensure that the information is correct, just that everyone has the same information; a service node might be providing a service that this particular node should not be providing. A method that supports authenticated service information ensures in addition that the authentication server knows this information to be correct. This document specifies a backwards compatible extension to popular EAP methods for supporting both channel bindings and authenticated service information. It does so in a media-independent manner, making it possible to run the same EAP mechanisms across different media, and introducing new information elements without affecting interoperability. This extension is intended for the verification of service information. It is not intended as a means for communicating information about parameters that EAP clients would not otherwise be aware of based on their communication with the node providing the service. This rest of the document is organized as follows. In we discuss the need for authenticated service information in more detail. discusses the design considerations and alternatives for solutions in this space. gives an overview of how our protocol operates and describes the kind of information that can be verified. We have provided only an initial list of parameters for IEEE 802.11 and IKEv2, but additional parameters can be defined through IANA. describes the extensions necessary for certain popular EAP methods. Support for other EAP methods can be added in other specifications.

EAP is run for the purposes of providing granting access to a service, such as network access. The nodes providing such services (called authenticators in EAP) typically have an identifier or identifiers, and offer a specific type of a service with an associated set of parameters. Collectively, this identifier, type and parameter information is called service information. In the Extensible Authentication Protocol (EAP) framework, different authentication methods can provide varying security properties. One such property is called "channel bindings", which is described in RFC 3748 as follows: "The communication within an EAP method of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol)." The document continues by describing the security implications of not being able to verify service information: "It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol). Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This creates a potential security vulnerability. Section 4.3.7 of describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS-Identifier , NAS-IP-Address or NAS-IPv6-Address attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol. For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id to the AAA server via the AAA protocol. In order to address this vulnerability, EAP methods may support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id , Calling-Station-Id , NAS-Identifier , NAS-IP-Address , and NAS-IPv6-Address . Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found, these SHOULD be logged; additional actions MAY also be taken, such as denying access." Unfortunately, such verification is currently not possible in popular network scenarios. For instance, in IEEE 802.11 networks a rogue operator can actually advertise the same identity (BSSID or SSID) as the local operator; the parameters advertised by the access point information are not authenticated end-to-end to the home network. There is no support is in the commonly used EAP methods for authentication of service information, and there are no alternative verification means in the IEEE 802 lower layer. For instance, rogue access points can present a different identity to the client and to the home network. Or a rogue IKEv2 gateway can claim to be a 802.11 access point to its clients, but still appear as an IKEv2 gateway towards the authentication server. There are cases where the lower layer does provide its own means of authenticating the service information. For instance, in IKE2, EAP is used together with certificate-based authentication of the responder. However, this document may be useful with proposed IKEv2 extensions like that remove the need to deploy a PKI. Also, even a lower layer that performs some kind of authentication for its service information may be unable to do so in all cases, such as distinguishing between different services offered by the nodes belonging to a group of nodes certified in the same manner. This situation is further complicated by the fact that services do not necessarily have just a single identifier, but several different identifiers of different types. For instance, an IEEE 802.11 access point could be identified by a BSSID, an IPv4 address (e.g., NAS-IP-Address), or a domain name (e.g., NAS-Identifier). Other identifiers, such as SSID, do not necessarily identify a single access point, but may be more interesting to the client (if you consider the "service" to be wireless LAN network access in some hotspot, rather than a single physical box). It is important to make a distinction between channel bindings and authenticating information related to the the pass-through authenticator. Channel bindings only ensure that the same information is available to the EAP peer and the AAA server. This alone does not prevent an authenticator from impersonating another authenticator if the AAA server blindly accepts any information received from the authenticator. To provide authentication, the AAA server has to verify that the information actually corresponds to the entity the AAA-Key is sent to.

The following considerations deserve some discussion: Retaining media independence in EAP Choosing the party (or parties) to perform the verification Communication within EAP vs. within AAA protocols These are discussed in following subsections.

An EAP-based channel binding solution can fail to retain EAP's independence from media in three ways. First, an EAP method might support channel bindings only for some media, or make the addition of parameters for new media types hard. This would make it harder for users to switch to new media.. Secondly, if channel bindings are provided only by some EAP methods, the choice of authentication methods and credentials would be limited in an environment that requires channel binding support . Thirdly, the EAP layer or EAP methods might have to interpret or understand the channel binding parameter information in some manner. This would result in a need to update EAP peer and server implementations when new media or new parameters on an existing media are developed. This draft avoids these problems by (1) defining the channel binding support simultaneously to the most popular EAP methods, (2) providing a common parameter name space across these methods in order to ensure that the same kind of information can be authenticated independent of the choice of the EAP method, and (3) treating the channel binding information as opaque data at the EAP layer and within EAP methods. Figures 1 and 2 illustrate how information is expected to be conveyed to upper layers where authorization decisions can be made.

--------+ +--------->-------+ Figure 1: Architecture ]]>

EAP layer | | | | | | | | | | | | | | | | | | | +-------------------------+--------------------------+ Figure 2: Flow of information to and from EAP ]]>

The main idea of channel bindings is to be able to verify information from two sources, such as comparing what the EAP authenticator has told the peer and the server. Different designs could implement this check at different nodes: at the peer, the server, or both. Assuming a secure exchange of opaque data through EAP, both the peer and the server can have the same information available to them, including what the authenticator has communicated over AAA to the server and what it has told the peer over the lower layer. (Note that there are vulnerabilities in both AAA and lower layer protocols; what matters, however, is that both ends see the same information. Assuming the EAP method is secure, this can be arranged.) However, the server may be in a better position to have an understanding of what roaming contracts exist, what authenticators are expected to exist and what services they should be offering. Similarly, fraud detection and policy rules are easier to arrange at a central site than in clients. Finally, server-side verification is the model already adopted in PEAPv2 PEAPv2, it makes the introduction of a general channel binding model easier for this method. As a result, it seems reasonable to assume a model where the server is in charge of the verification process.

As discussed in , the communication of the verified parameters can occur in two ways: Here the set of verified parameters is communicated end-to-end within EAP as an opaque string. Here the set of verified parameters is communicated from the authenticator (a) to the peer via the lower layer protocol and (b) to the server via the AAA protocol. In order to prevent fraudulent claims about the parameters, the AAA protocol calculates AAA-Key based on the parameters, and communicates only this key (not the current MSK) to the authenticator. As a result, the peer and the authenticator can not complete their network attachment process if there's a mismatch in the set of parameters. The overall result of both approaches is the same, but there are subtle security differences: One difference is that in the EAP approach we need to trust the server to perform the check, whereas the key-based check is implicit and "non-skippable" in the latter approach. Another difference is in the timing of the check; in conventional AAA protocols the user is considered authenticated when the RADIUS Access-Accept or equivalent message is sent. This ensures that the AAA server is aware of the result of the access request. But in the AAA-based approach a mismatch in the parameters is learned after this, and may be hard to report in a secure way. For instance, the authenticator could claim that a session was started, even if in reality the secure association protocol failed due to a mismatch. There is also a difference in terms of deployment implications. The EAP-based approach means that EAP implementations and methods have be updated. Existing credentials can continue to be used, however, and it is expected that the opaque data approach makes it possible to add new media and new parameters without additional code changes in EAP. There are no EAP updates in the AAA-based approach, but it is still necessary to add support for the new parameter communication means and AAA-Key calculation to peers, authenticators, and servers. The main difference to the EAP-based approach is that authenticators need to be changed. Because of the above considerations, this draft employs the EAP-based approach.

The basic idea in this extension is that the EAP peer sends the EAP server a statement that it going to accept service from an access device associated with particular set of identifiers and other information. In order to protect this statement, an EAP method needs to be able to pass data from the EAP peer to the EAP server, and be able to protect this exchange using keys known only them and not the access device. The Transient EAP Keys (TEKs) can be used for this purpose, as these keys are only known to the EAP endpoints and not communicated to the access device. After receiving this information, the EAP server can compare the information provided from the EAP peer to the information it has received directly from the access device. If the information does not match, the access device has provided different information to the peer and to the AAA protocol. This is disallowed, and the authentication MUST be terminated in this case. In order to provide a generic solution where any EAP method can be used on a given lower layer, the same format is used for the exchanged information. This format consists of Tag-Length-Value triplets with IANA managed tag space. The parameter information is sent along the other messages in an EAP method. When mismatching information is received from EAP and authenticator, authentication MUST be terminated. The exact message sequences depend on the used EAP method, but Figure 1 shows a typical sequence.

Peer Authenticator Server | | | | 802.11 attachment | | |<------------------------>| | | | | +----------------------+ | | | Information received | | | | at this point is | | | | not authenticated | | | +----------------------+ | | | | | | EAP Identity Request | | |<-------------------------| | | | | | EAP Identity Response | | |------------------------->| | | | RADIUS Access-Request | | |------------------------->| | | | | | +----------------------+ | | | Server authenticates | | | | the RADIUS request | | | +----------------------+ | | | | | RADIUS Access-Challenge | | EAP TLS Start |<-------------------------| |<-------------------------| | | | | +-----------------------+ | | | Peer sends the | | | | authenticator's info | | | | to the server in EAP | | | +-----------------------+ | | | | | | EAP TLS C-Hello + id. | | |------------------------->| | | | RADIUS Access-Request | | |------------------------->| | | | | | +-------------------------+ | | | Server can now verify | | | | that the information | | | | is what was expected | | | +-------------------------+ | | | | | RADIUS Access-Challenge | | EAP TLS S-Hello . |<-------------------------| |<-------------------------| | | | | +-------------------------+ | | | Peer learns here that | | | | the information was | | | | verified (EAP continues)| | | +-------------------------+ | | | | | | | | | EAP TLS Finished | | |------------------------->| RADIUS Access-Request | | |------------------------->| | | | | | RADIUS Access-Challenge | | EAP TLS Finished |<-------------------------| |<-------------------------| | | | | | | | | EAP TLS | | |------------------------->| RADIUS Access-Request | | |------------------------->| | | | | | RADIUS Access-Accept + | | | AAA-Key | | EAP Success |<-------------------------| |<-------------------------| | | | | +-----------------------------+ | Authentication is completed | | when the authenticator | | proves it knows the AAA-Key | +-----------------------------+

Zero or more parameters are sent from the peer to the server. Each parameter is of the format explained in the next section.

Nodes supporting this extension pass parameters in the following format:

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Res | Parameter Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Value . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The meaning of the fields is described as follows: The authenticated information flag. Value of zero means that the information is claimed by the service, but the EAP server is unable to tell whether the information is correct or not (i.e., this corresponds to channel bindings without authentication). Value of one means that the EAP server knows that the service is authorized to claim this ("authenticated service information"). A 3-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. A 16-bit field that specifies what parameter is being communicated. A 12-bit field that indicates the length of the Value field, in bytes. The actual parameter value. The interpretation of this value depends on the Parameter Identifier field. The EAP or the EAP method layer SHOULD NOT attempt to interpret the information beyond this format. In other words, the Parameter Identifier and Value fields are interpreted as opaque data in order to ensure EAP media independence. EAP implementations SHOULD pass the information to higher layers that are in charge of authorization decisions, such as AAA server authorization logic. The encapsulation of this sequence of parameters is EAP method dependent.

These parameters are for any type of nodes and lower layers. The Service Type parameter MUST be supported by all nodes conforming to this specification, and MUST be the first parameter in all messages containing a sequence of parameters defined here.

The Parameter Identifier for this parameter is 0, and the Value is a 32-bit integer, represented in network byte order. The following values have been currently defined: IEEE 802.11 IKEv2 The 'A' flag MUST always be set with the Service Type parameter. The receiver SHOULD fail the authentication if the Value field is either not recognized by it or is not the same one for which it thinks access is being provided.

The Parameter Identifier for this parameter is 1, and the Value is an UTF-8 encoded string describing the human readable name of the service provider. As EAP is used primarily for network access, this is typically the name of the access network provider.

The Parameter Identifier for this parameter is 2, and the Value is an ASCII string of at most 3 characters, conforming to the ISO 3166 country code.

All the following parameters MUST be supported when IEEE 802.11 is accepted as a Service Type.

The Parameter Identifier for this parameter is 3, and the Value is an octet string containing the Service Set Identifier (SSID).

The Parameter Identifier for this parameter is 4, and the Value is a 6-octet string containing the BSSID.

All the following parameters MUST be supported when IKEv2 is accepted as the Service Type.

The Parameter Identifier for this parameter is 14, and the Value is the IP address of the node who acted as the responder for this IKEv2 EAP exchange. The Value is either 4 or 16 bytes depending on whether IPv4 or IPv6 is used.

The Parameter Identifier for this parameter is 16, and the Value is an octet string containing the IKEv2 initiator identity payload (IDr).

This section describes an initial set of extensions to some current EAP methods so that they can be transport the parameter information. The extensions are optional and backwards compatible, so that, where allowed by policy, EAP peers without these extensions can still contact EAP servers with these extensions and vice versa. The default policy SHOULD be that such usage is allowed.

A TLS extension is added to the EAP TLS client_hello/server_hello messages. The extension type of the extension is EAP Service Information and it has the number < To Be Assigned By IANA >. The extension contains a sequence of parameters, followed by each other. The extension sent in the server_hello message SHOULD contain zero parameters, and is only used to confirm that the server supports this specification. As discussed in RFC 3546, when these extensions appear in a client hello message, they are ignored by old server implementations. The lack of this extension in the authenticator's server hello response SHOULD be taken as an indication that the authenticator does not support the mechanisms defined in this document. The authenticator MUST NOT use this extension unless the client provided the same extension in its own hello message, as per RFC 3546 the client is required to terminate the TLS session otherwise. The client_hello/server_hello messages are included in MACs in the TLS Finished messages, which ensures that modifications will be detected. The following sequence illustrates the operation of the EAP TLS protocol with this extension:

Peer Authenticator | | | PPP EAP-Request/ | | EAP-Type=EAP-TLS | | (TLS Start) | |<---------------------------------------------------------| | | | PPP EAP-Response/ | | EAP-Type=EAP-TLS | | (TLS client_hello + extension) | |--------------------------------------------------------->| | | | PPP EAP-Request/ | | EAP-Type=EAP-TLS | | (TLS server_hello + extension, | | TLS certificate, | | [TLS server_key_exchange,] | | [TLS certificate_request,] | | TLS server_hello_done) | |<---------------------------------------------------------| | | | PPP EAP-Response/ | | EAP-Type=EAP-TLS | | (TLS certificate, | | TLS client_key_exchange, | | [TLS certificate_verify,] | | TLS change_cipher_spec, | | TLS finished) | |--------------------------------------------------------->| | | | PPP EAP-Request/ | | EAP-Type=EAP-TLS | | (TLS change_cipher_spec, | | TLS finished) | |<---------------------------------------------------------| | | | PPP EAP-Response/ | | EAP-Type=EAP-TLS | |--------------------------------------------------------->| | | | PPP EAP-Success | |<---------------------------------------------------------| | |

This works the same way when resuming session. Note that the parameters can change from the initial authentication.

In PEAPv2, the Connection-Binding TLV is used to carry parameter objects. One Connection-Binding TLV for this purpose is exchanged in each direction, containing all the parameters that need to be exchanged. The Connection-Binding TLV carries a set of PEAPv2 TLVs. The transport of parameters for the purposes of this document takes place through the PEAPv2 Service Information Parameter TLV defined in the following:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of this TLV are as follows: 0 - Optional TLV. Reserved, set to zero (0). < To Be Assigned By IANA > Length of the TLV. The parameter in the format described in .

For EAP-AKA, a new attribute AT_SERVICEID is added to the EAP-Request/AKA/Challenge message. The format of the AT_SERVICEID attribute is shown below:

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_SERVICEID | Length | Actual data length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Parameters... . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of this attribute are as follows: < To Be Assigned By IANA > Length of the attribute. This field specifies the length of the following field in bytes, because the length of the parameter must be a multiple of 4 bytes, the sender pads the data with zero bytes when necessary. The parameters in the format described in . The following sequence illustrates the operation of the EAP-AKA protocol with this extension:

Peer Authenticator | EAP-Request/Identity | |<------------------------------------------------------| | | | EAP-Response/Identity | | (Includes user's NAI) | |------------------------------------------------------>| | | | +------------------------------+ | | Server runs UMTS algorithms, | | | generates RAND and AUTN. | | +------------------------------+ | | | EAP-Request/AKA-Challenge | | (AT_RAND, AT_AUTN, AT_MAC, AT_SERVICEID) | |<------------------------------------------------------| | | +-------------------------------------+ | | Peer runs UMTS algorithms on USIM, | | | verifies AUTN and MAC, derives RES | | | and session key | | +-------------------------------------+ | | | | EAP-Response/AKA-Challenge | | (AT_RES, AT_MAC, AT_SERVICEID) | |------------------------------------------------------>| | | | +--------------------------------+ | | Server checks the given RES, | | | and MAC and finds them correct.| | +--------------------------------+ | | | EAP-Success | |<------------------------------------------------------|

The AT_SERVICEID attribute from the server to the peer is empty, and is only used for capability detection. A peer MUST NOT send a AT_SERVICEID attribute if no such attribute was seen from the server previously. In this case, the peer MAY disconnect if its policy requires the channel binding support. Note that the AT_SERVICEID attribute is used also in the EAP-Request/AKA/AKA-Reauthentication message, and that the set of parameters exchanged in this case may differ from those agreed upon earlier in the initial authentication. The use of the AT_SERVICEID attribute is backward compatible, because existing implementations ignore unknown parameters.

For EAP-SIM, a new attribute AT_SERVICEID is added to the EAP-Request/SIM/Challenge message. The format of the AT_SERVICEID attribute is as shown for EAP-AKA. The following sequence illustrates the operation of the EAP-SIM protocol with this extension:

Peer Authenticator | | | EAP-Request/Identity | |<---------------------------------------------------------| | | | EAP-Response/Identity | |--------------------------------------------------------->| | | | EAP-Request/SIM/Start | | (AT_VERSION_LIST) | |<---------------------------------------------------------| | | | EAP-Response/SIM/Start | | (AT_NONCE_MT, AT_SELECTED_VERSION) | |--------------------------------------------------------->| | | | EAP-Request/SIM/Challenge | | (AT_RAND, AT_MAC, AT_SERVICEID) | |<---------------------------------------------------------| | | +-------------------------------------+ | | Peer runs GSM algorithms, | | | verifies AT_MAC and derives | | | session keys | | +-------------------------------------+ | | | | EAP-Response/SIM/Challenge | | (AT_MAC, AT_SERVICEID) | |--------------------------------------------------------->| | | | | | EAP-Success | |<---------------------------------------------------------| | |

As with EAP-AKA, the AT_SERVICEID attribute must be passed also in the EAP-Request/SIM/SIM-Reauthentication message. Similarly, the AT_SERVICEID attribute from the server to the client is empty and only used for capability detection.

The implications of being unable to verify service information have been described in Section 7.15 of RFC 3748 . These include vulnerabilities related to compromised access points or fraudulent service providers. When properly used, the mechanism provided in this document removes these vulnerabilities. The mechanism is generic and not tied to any specific EAP method or use of EAP over a specific link layer, and as such can be expected to be more easily deployed as alternative suggestions such as those described in PEAPv2 or EAP FAST. Authenticating the service information may complicate operation in some deployment scenarios, since it requires that the AAA server is able to authenticate the expected kinds of information. For instance, RADIUS is often deployed in situations where the only authenticated information related to the RADIUS client is the IP address; other information may be present in the Access-Request message (such as BSSID/SSID in the Called-Station-Id attribute), but this is simply claimed information not authenticated information. Where such information is not available, some vulnerabilities still remain. In the deployment phase, it is possible that clients and servers do not get support for the mechanism described in this document at the same time. It is a policy decision to accept an EAP exchange from a party that does not support this mechanism. This decision is protected from a bidding down attack by a man-in-the-middle, because EAP methods have integrity protection for the exchanged messages. Therefore, the removal or modification of the parameter block would be detected.

This document requests an IANA allocation of TLS Extension type for EAP Service Identity (see ). This document requests an IANA allocation of a PEAPv2 TLV type number for the Service Identity Parameter TLV (see ). This document requests an IANA allocation for the attribute type number AT_SERVICEID in the and protocols (see and ). The same value should be allocated for both protocols.

New Parameter Identifier values can be defined through Specification Required. The following values have been currently allocated: Service Type Service Provider Country Code 802.11/SSID 802.11/BSSID IKEv2/Responder Address IKEv2/IDr New Service Type values can be defined through IETF Consensus. The following values have been currently allocated: IEEE 802.11 IKEv2 Values in other enumerated parameters can be defined through First Come, First Served. However, this extension is intended only for the verification of service information. Its use for communicating other information not already known by the EAP client (such as for service discovery) is discouraged.

The authors would like to thank Bernard Aboba, Yoshihiro Ohba, Mohan Parthasarathy, Hannes Tschofenig, Joe Salowey, Glen Zorn, and David Mariblanca for interesting discussions in this problem space.