Subject: Re: [Emu] Comments for draft-clancy-emu-chbind-02.txt

From: Charles Clancy <[email-masked]>
Date: Wed, 15 Oct 2008 12:56:14 -0400

Hannes,

Thanks for the comments.  I'm working on a revision that addresses the 
"fuzzy comparison" issue.  Certainly there's a cost to implementing 
channel bindings.  EAP methods already support carrying the information, 
so the only changes would be to their implementations, which could be 
done incrementally.

Having the authenticator send information to the EAP server for 
comparison doesn't work.  The authenticator could simply provide the 
same false information to both the peer and server.  The server needs 
some way to know whether the information the authenticator is sending is 
consistent with network policy.  Therefore it needs a policy database. 
If it has the policy database, it no longer needs the authenticator to 
send this information to it during every transaction.

The exact AVPs exchanged are still open for debate.  The text there is 
mostly just a place holder.  We need to know what types of things people 
thing are appropriate for validation.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> * When I have to introduce this work to our AAA server folks then they
> will obviously ask me the following question: What is the benefit and
> what does it cost? As you mentioned in the operational considerations
> section there is cost associated with updating the EAP methods, putting
> new information into the AAA server database, providing additional
> policies into the AAA server to accomplish the authorization check. Now,
> the question really is whether folks are so concerned about the attack.
> I know the Lying NAS problem but the current text isn't scary enough.
> Have you ever seen some data that this attack is a real issue? In case
> you do then it would certainly be valuable information to convey this to
> the reader. 
> 
> * Reading the operational consideration section I get the impression
> that you consider that the AAA server database is populated with
> information about the access points and what information they are going
> to send to their peers. That might be one way of doing it.
> Another way would be for the AAA client to send the same set of
> parameters to the AAA server for comparison. 
> 
> * I am not sure how this fuzzy comparison would look like and how one
> would do that in practice. Does it mean that you just compare some
> parameters? 
> 
> Incorporating channel binding information into the key derivation
> functions would, for sure, get things to break even if the operator
> running the AAA server decides not to enforce it. It is good that you
> did not go for that approach. 
> 
> *  Figure 1
> 
> I think that there is a possible information exchange missing in Figure
> 1. Shouldn't you also include an arrow between the Authenticator and the
> EAP server? 
> 
> 
> * You write: 
> 
> "
>    The server MAY send the Cost-Information AVP from the Diameter
>    Credit-Control Application [RFC4006] to the peer indicating how much
>    peers will be billed for service.
> "
> 
> To my knowledge, this is not done for network access. This may be done
> for higher layer applications but AoC isn't really something that you
> find quite often...
> 
> * IEEE 802.16
> 
> The case is somewhat different here since the access network can
> actually be authenticated. 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Charles Clancy <[email-masked]>
Date: Wed, 15 Oct 2008 13:16:53 -0400

Hannes,

Another quick comment on the value derived by operators for deploying 
channel bindings -- channel bindings will give operators the ability to 
apply detailed authorization policies to EAP-based network access. 
Right now EAP is primarily just an authentication facility, and 
authorization is based on only information about the peer.  Now 
authorization can also be based on information about the NAS, and the 
properties of the network to which the peer is connecting.

Using channel bindings, for example, an EAP server could ensure that 
certain users only connect to 802.11 networks using AES for link-layer 
security or with certain SSIDs, for example, while other users could 
connect to any network.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 16 Oct 2008 10:53:30 +0200

Hello,

another possible use case would a "home zone" feature in service
provider roaming scenarios: client sends information about which
authenticator it is connected to, auth server signals back whether this
is an authenticator which belongs to the user's own networking domain or
is roaming.

Greetings,

Stefan Winter

> channel bindings -- channel bindings will give operators the ability
> to apply detailed authorization policies to EAP-based network access.
>> Thanks for the comments.  I'm working on a revision that addresses
>> the "fuzzy comparison" issue.  Certainly there's a cost to
>> implementing channel bindings.  EAP methods already support carrying
>> the information, so the only changes would be to their
>> implementations, which could be done incrementally.
>>
>> some way to know whether the information the authenticator is sending
>> is consistent with network policy.  Therefore it needs a policy
>> database. If it has the policy database, it no longer needs the
>> authenticator to send this information to it during every transaction.
>>
>> The exact AVPs exchanged are still open for debate.  The text there
>> is mostly just a place holder.  We need to know what types of things
>> people thing are appropriate for validation.
>>
>> -- 

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473