Review

[bernard_aboba@…]

From: ​http://www.ietf.org/mail-archive/web/emu/current/msg01353.html ​http://www.ietf.org/mail-archive/web/emu/current/msg01354.html ​http://www.ietf.org/mail-archive/web/emu/current/msg01355.html

I agree with Yaron that this document is not ready to be advanced.

Aside from whether the document is appropriate for publication on the Standards Track (I believe that Informational would be a better choice), I'd suggest that the document has a more basic problem in that it doesn't do a very good job of defining the problem it is trying to solve or demonstrating that the solution offered actually solves that problem or can be practically implemented.

For example, early on the document makes the following statement:

This document defines and implements EAP channel bindings to solve the lying NAS and the lying provider problems, using a process in which the EAP peer provides information about the characteristics of the service provided by the authenticator to the AAA server protected within the EAP method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator. "AAA Payloads" defined in [I-D.clancy-emu-aaapay] proposes a mechanism to carry this information.

However, as noted in Section 3:

In service provider networks, global knowledge is infeasible due to indirection via roaming. When a peer is outside its home administrative domain, the goal is to ensure that the level of service received by the peer is consistent with the contractual agreement between the two service providers.

Unfortunately the term "level of service" is not well enough defined here to give a good sense of what is possible and what is not. As noted above, in general the home AAA server does not have enough information to independently verify AAA attributes provided to it by roaming partners. The problem is not just lack of "global knowledge"; even if it were possible for a home AAA server to have perfect global knowledge, if that knowledge were obtained from the providers themselves (where else could it come from?) then if those providers were untrustworthy, then how could it be used in channel binding verification?

As a result, I'd suggest that some careful analysis is needed to describe in detail the threats that the "lying provider" solution really can mitigate. As noted later:

In other words, channel bindings enable the detection of inconsistencies in the information from a visited network, but cannot determine which entity is lying.

Given that it is not really possible to determine whether a provider is actually lying or not, how does the offered solution actually solve the "lying provider" problem?

The service provider attacks described in Section 3, which attempt to make the case for the utility of channel bindings are not very convincing:

1. Inappropriate billing. In this scenario, it's not clear to me how Channel Bindings would be helpful Today rates are not advertised in Beacons, and if accounting fraud is suspected, wouldn't this be best verified by computing the expected billed amounts against the actual ones, based on RADIUS accounting data?

2. Transmit power boost. Detecting inappropriate levels of transmit power seems like something beyond the capability of channel bindings (and more in the jurisdiction of regulatory agencies like the FCC). Even if the geolocation were to be transmitted along with the power measurement, detecting an inappropriate transmit power level would involve some fairly complex modeling with lots of variables (e.g. precise tower location, absorption along the line of sight, etc.).

At a minimum, I'd suggest that the document needs to come up with some more plausible service provider scenarios.

Section 5.1

The local database is perhaps the most important part of this system. In order for the EAP server or AAA server to know whether i1 and i2 are correct, they need access to trustworthy information, since an authenticator could include false information in both i1 and i2. Additional reasons why such a database is necessary for channel bindings to work are discussed in the next subsection. The information contained within the database could involve wildcards. For example, this could be used to check whether WiFi? access points on a particular IP subnet all use a specific SSID. The exact IP address is immaterial, provided it is on the correct subnet.

[BA] Is it really true that the IP address of the NAS is always immaterial? For example, couldn't a NAS lie about its IP address in order to impersonate another NAS?

During an EAP method execution with channel bindings, the goal is to transport i1 from the peer to the EAP server, and allow the system to verify the consistency of i1 provided by the peer, i2 provided by the authenticator, and the information in the local database. Upon the check, the EAP server sends a message to the peer indicating whether the channel binding validation check succeeded or failed and optionally includes all or some of the information that was used in the check. The message flow is illustrated in Figure 1.

[BA] Is it always necessary for the EAP server to provide information to the peer about why the channel binding check succeeded or failed? While this info might be helpful for debugging, it seems like there could be situations in which the AAA server just returns an Accept/Reject? indication.

If the compliance of i1 or i2 information 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. If the EAP server is otherwise configured, it MUST allow the EAP session to complete normally, and leave the decision about network access up to the peer's policy.

[BA] I would suggest that normative language is not appropriate here. For one thing, an EAP-Failure does not actually result in the host being denied access to the network -- an Access-Reject is what accomplishes this. Also, since an EAP-Failure (or EAP-Success) may not be delivered, it doesn't make sense to rely on it. Furthermore, couldn't there be situations where rather than denying access some other action is taken, such as putting up a warning message, isolating the host in some way (e.g. filters or VLAN setting, etc.)?

Section 5.2

These checks enable the EAP server to detect lying NAS/authenticator in enterprise networks and lying providers in service provider

[BA] As noted in the previous message, these checks do not actually enable the determination of whether a provider is lying.

Checking the consistency of i1 and i2 is nontrivial, as has been pointed out already in [HC07]. First, i1 can contain any type of information propagated by the authenticator, whereas i2 is restricted to information that can be carried in AAA attributes.

[BA] Actually, i1 can only contain information that is both propagated by the authenticator *and* passed up by the host in the proper format. This requires coordination between the driver implemented on the host and the EAP method. In practice, this has been a major impediment to implementation of Channel Bindings, because without driver changes, many of the parameters desired by channel binding implementations will not be available.

Similarly, the database referred to in this section also requires a non-trivial effort to put together, comparable to the "wire map" required to support geographic location or emergency services calling.

For example, if the EAP MTU is 1020 octets, and EAP-GPSK is used as the authentication method, and maximal-length identities are used, a maximum of 384 octets are available for conveying channel binding.

[BA] This is an important point -- and one that indicates that the ability to implement channel bindings is limited on EAP methods that don't support fragmentation.

Section 6.3

If transporting data within a lower-layer's secure association protocol (SAP), this protocol MUST support transport of integrity protected data using a key known only by the EAP peer and EAP server, and not known to the authenticator. There must be mechanism whereby the authenticator can transport the protected payloads to the EAP server, either via a AAA protocol or some other means, and receive a protected result.

[BA] This paragraph does not make sense, because by definition the SAP exchange occurs between the authenticator and the peer, and therefore any keys derived in the process need to be known by the authenticator and the peer. In a number of cases (such as IKEv2), the EAP server only doesn't know the key used by the SAP, but it is an explicit design requirement that this not be possible.

This protocol MUST support exporting channel binding data to the AAA subsystem on the EAP server for validation. The SAP must have access to channel binding data required for transport to the EAP server.

[BA] The last sentence also doesn't make sense. Elsewhere in the document it says that the authenticator is not supposed to have access to the channel bindings data, but here it implies that it must have access, since the SAP is run between the peer and authenticator.

Section 7.1

7.1. Requirements for Lower-Layer Bindings

Lower-layer protocols MUST support EAP in order to support EAP channel bindings. These lower layers MUST support EAP methods that derive keying material, as otherwise no integrity-protected channel would be available to execute the channel bindings protocol. Lower- layer protocols need not support traffic encryption, since this is independent of the authentication phase.

[BA] Channel Bindings can still be used even on lower layers that don't use keying material. For example, an EAP method supporting channel bindings could be used with a wired network supporting IEEE 802.1X-2004. Since the EAP server/AAA server will still obtain i1/i2 in this situation, why should it matter whether an integrity-protected channel is in place?

Section 9.2

Additional network entities (such as proxies) might be on the communication path between peer and server and may attempt to manipulate the channel binding protocol. If these entities do not possess the keying material used for integrity protection of the channel binding messages, the same threat analysis applies as for the dishonest authenticators. Hence, such entities can neither manipulate single channel binding messages nor the outcome. On the other hand, entities with access to the keying material must be treated like a server in a threat analysis. Hence such entities are able to manipulate the channel binding protocol without being detected. However, the required knowledge of keying material is unlikely since channel binding is executed before the EAP method is completed, and thus before keying material is typically transported to other entities.

[BA]

Unless the transient EAP keys used for integrity protection are derivable from the

MSK, possession of the MSK would not be sufficient to enable an authenticator to modify the channel bindings. As a result, the only entities relevant to the threat analysis are those that possess the TEKs, not just those that possess the MSK or other derived keys.