Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.txt (part 1)

["Hoeper Katrin-QWKN37" <[e-mail]>]

Bernard,

 

Thank you for your detailed comments.

 

It is true that channel bindings as described in the draft can
accomplish two different things in Enterprise networks and Service
Provide networks, respectively.

To what degree the "lying provider" problem can be solved heavily
depends on the kind of data available to the home network. 

This data enables the home network to verify the consistency between the
offered services and the services that were agreed on in contractual
agreements.

 

What's included in contractual agreements and which of this data can be
made available to the home network varies heavily depending on
particular implementations. For this reason the specifics of the data
are outside the scope of the draft. This is a good thing because the
channel binding protocol in this draft enables to verify WHATEVER data
is relevant & available and make sure that the data presented to a peer
is consistent with the data known to the home network.

 

The draft describes the protocol to exchange this information. Another
draft describes what containers can be used to exchange this
information.

What somebody wants to verify as part of the channel bindings is up to
the implementers. The draft only explains the two general problems it
addresses and outlines a few examples.

 

If you think the current examples are too deprived, I would like to ask
you to suggest some more "reasonable" examples that we can include.

 

Best regards,

Katrin

 

 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Bernard Aboba
Sent: Monday, December 07, 2009 9:12 PM
To: [e-mail]
Subject: Re: [Emu] Working Group Last Call for
draft-ietf-emu-chbind-04.txt (part 1)

 

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.