Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
Extracted elements (30)
A local database at the EAP/AAA server is essential because a lying authenticator could include false information in both i1 (sent to peer) and i2 (sent to AAA server), making consistency checks between i1 and i2 alone insufficient to detect the attack. The database provides trusted ground-truth for comparing received information.
EAP channel bindings differ from RFC 5056 channel bindings: RFC 5056 binds layers of a session together, while EAP channel bindings verify the accuracy of information advertised to an EAP peer by an authenticator during EAP execution. The term 'channel bindings' was independently adopted for both concepts before the conflict was discovered.
The plaintext exchange approach (rather than encoding channel-binding info directly into key derivation) was chosen because it allows policy-based comparisons rather than requiring bitwise equality, facilitates debugging and incremental deployment, and does not require extensive revisions to existing EAP methods. Consistent canonicalization required for key-derivation inclusion would likely cause significant deployment problems.
Channel bindings via the secure association protocol (rather than within the EAP method) can work even with EAP Re-authentication Protocol (ERP, RFC 5296), where previously established EAP keying material is used without executing any EAP method during re-authentication. This approach requires changes to NASes and secure association protocols but avoids the need to update EAP methods.
The scope of verifiable channel-binding information differs between enterprise and service provider (roaming) deployments. In enterprise networks, specific NAS properties (MAC address, SSID, VLAN) can be verified. In roaming cases, the home server typically only has access to information from roaming agreements, and AAA proxies may obscure or modify NAS-specific attributes.
A given NSID MUST NOT appear more than once in a channel-binding data or channel-binding response; all NS-Specific data for a particular NSID must be consolidated into one set of (NSID, Length, NS-Specific) fields.
Channel bindings MUST be transported with integrity protection based on a key known only to the peer and EAP server. Channel bindings SHOULD be confidentiality protected using a key known only to the peer and EAP server.
If confidentiality cannot be provided by the transport, private information (including peer identities) MUST NOT be sent as part of the channel-binding information.
If i1 or i2 does not comply with policy, the EAP server MUST NOT list information that failed to comply in the set of information used to perform channel binding. The EAP server SHOULD indicate channel-binding failure in this case.
If the compliance of i1 or i2 with the authoritative policy source is mandatory and a consistency check failed, then after sending a protected indication of failed consistency, the EAP server MUST send an EAP-Failure message to terminate the session.
In a success response (code 2), attributes that the server was unable to check or that failed to validate MUST NOT be returned. For failure (code 3), the server SHOULD include attributes that were successfully validated.
In order to establish the trust relationships required for channel binding, an EAP method MUST provide: mutual authentication between peer and server; derivation of keying material including an integrity-protection key known only to peer and EAP server (not the authenticator); and transmission of channel-binding request and result over integrity-protected channels in both directions.
Lower-layer protocols MUST support EAP and MUST support EAP methods that derive keying material in order to support EAP channel bindings. The EAP Lower-Layer attribute MUST be included in i1 unless an attribute specific to a particular lower layer is already included in i1.
Peers MUST treat unknown codes as channel-binding failure. Peers MUST ignore differences between attribute values sent in channel-binding data and those in the response. Peers and servers MUST ignore attributes in fields with an unknown NSID. Peers MUST ignore attributes in a response not present in the channel-binding data.
The transport protocol carrying channel-binding information MUST support end-to-end (peer-to-server) message integrity protection to prevent the adversarial NAS or AAA device from manipulating the transported data. The transport SHOULD provide confidentiality.
When transporting channel-binding data within an EAP method, the method MUST be able to carry integrity-protected data from the EAP peer to server and from EAP server to peer. EAP methods MUST exchange channel-binding data with the AAA subsystem hosting the EAP server and MUST be able to import channel-binding data from the lower layer on the EAP peer.
Channel-binding information exchanged between peer and server must always be integrity protected, but may not be encrypted. If channel-binding messages contain peer or network entity identifiers, failure to encrypt them violates the privacy properties of the EAP method. If encryption is unavailable, private information MUST NOT be sent as part of channel-binding data.
Channel-Binding Codes: 1 = channel-binding data from client, 2 = channel-binding response success, 3 = channel-binding response failure. Code 0 is reserved. Values range 0–255 and require Standards Action for new registrations.
Namespace Identifiers (NSIDs): 1 = RADIUS namespace, 255 = reserved for private use. Values 0–255 require IETF Review for new registrations; 0 is reserved.
The channel-binding protocol uses two information streams: i1, the unauthenticated network information presented by the authenticator to the peer (e.g., SSID, network identity, offered services), and i2, the AAA attributes provided by the authenticator to the AAA server. The EAP server checks i1 from the peer against i2 and a local database to detect inconsistencies.
A new 'EAP Lower Layers' sub-registry is created under the IANA EAP Numbers registry. Registration requires Expert Review to prevent duplicate entries. Initial values: 1=Wired IEEE 802.1X, 2=IEEE 802.11 (no-pre-auth), 3=IEEE 802.11 (pre-auth), 4=IEEE 802.16e, 5=IKEv2, 6=PPP, 7=PANA (no pre-auth), 8=GSS-API, 9=PANA (pre-auth).
A new IANA registry 'Extensible Authentication Protocol (EAP) Channel Binding Parameters' is created with two sub-registries: 'EAP Channel-Binding Codes' (values 0–255, Standards Action required, 0 reserved, initial values 1–3 defined) and 'EAP Channel-Binding Namespaces' (values 0–255, IETF Review required, 0 reserved, initial values 1 and 255 defined).
A new RADIUS attribute EAP-Lower-Layer with code 163 is registered in the IANA RADIUS Types registry to carry information about which EAP lower layer is used for the current EAP authentication.
Bid-down attacks: an attacker including the NAS SHOULD NOT be able to prevent a peer and server who both support channel bindings from using them. However, EAP success messages are not integrity protected, and the NAS can always generate one, making it difficult for peers to distinguish a non-channel-binding server from an attacker injecting a success indication.
If an EAP server validates a channel-binding attribute (such as a username) that was guessed by the authenticator in i2 and fails when it mismatches the peer's i1, the server inadvertently confirms the authenticator's guess, creating a privacy oracle. Similar exposures arise whenever one party can guess channel-binding information provided by another.
The trust model assumes peer and EAP server are honest while the authenticator may be malicious. The server trusts channel-binding info from the peer reflects what the authenticator advertised; the peer trusts the server's channel-binding result; and the server trusts its local database. If any of these trust relationships are violated, channel binding cannot be provided.
When channel binding is added to tunnel EAP methods, existing cryptographic binding does not typically provide the mutual authentication required for channel binding because the MSK from the inner method is often accessible to the authenticator, which can use it to control channel-binding parameters. Server certificate validation with name checking can provide the required mutual authentication instead.
Channel-binding data and responses begin with a one-byte Code field, followed by one or more groups of: a two-octet Length (network byte order, not including NSID and length octets), a one-octet NSID (namespace identifier), and NS-Specific data. The format allows multiple namespaces to be concatenated in a single message.
RADIUS AVPs in the channel-binding namespace are encoded as: one-octet attribute type, one-octet length (including type and length octets; minimum legal value is 3), followed by the value. Attributes are concatenated to form the namespace-specific portion of the packet.
The EAP-Lower-Layer RADIUS attribute has Type 163, Length 6, and a 32-bit unsigned integer value in network byte order indicating the EAP lower layer in use. It may be sent by the NAS to the RADIUS server in an Access-Request or Accounting-Request.