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:
a. 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?
b. 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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
