Subject: RE: [eap] Re: issue 357: Channel Binding Definition

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 5 May 2006 09:40:48 -0700

> 
> >I think not all pieces of information associated with the 
> authenticator 
> >have to be part of EAP Channel Binding data.  I mean some 
> information 
> >such as identifier of each enforcement point can be bound locally 
> >betweeen peer and authenticator, using lower layer chanel binding 
> >provided by SAP, as long as basic information such as authenticator 
> >identity is validated using EAP Channel Binding and the valid 
> >authenticator is advertising that locally bound information.
> >

I am confused by the above - are you saying that the channel binding
data, for instance, may just be the authenticator ID (NAS ID as seen by
the server) and that any information on EPs associated with the
authenticator may be exchanged via the lower layer? How does the peer
trust that information then? At least in 802.11 networks, security of
management frames may take care of this, but I don't see this applying
to all kinds of technologies. 

> >On the other hand I think the entire EAP Channel Binding 
> data needs to 
> >be available to the peer when keying material is exported by an EAP 
> >method.  Otherwise, key scope becomes ambiguous at the time 
> of creating 
> >the keying material, which could open up some vulnerability in key 
> >management.
> 
> Right.  Maybe we could make this clearer in the document.
> 

I somewhat agree with the above - I am not disputing that the server
would have to send all channel binding data associated with a given MSK
at the time of export of the MSK. If this is a blob sent from the server
to the peer in a method, there is no issue. Only when you are assuming
the presence of that entire blob at the peer without exchanging that in
the method and arriving at a mixed key or something, this becomes a
problem, because the peer may not have a complete view. 

Vidya
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 05 May 2006 11:01:42 -0700

With apologies for interjecting in the middle of a discussion that 
seems to be concluding, I have some basic questions on Channel binding:

What are the types of CB information shared between the peer and the server?

How dissimilar might be the CB information?  In other words, are 
there different schools of thought on what might be sent, what might 
the peer and the server know about the authenticator?

How large might be the information?  In some EAP methods, it may be 
necessary to limit the size of the information.  So, if the peer has 
only a subset of the information that the server has, then it might 
make sense for the peer to send the CB info and the server to verify it.

Is all authenticated CB info exchanged between peer and server?  Or, 
does it make sense to do some of it in the method and the rest in L2 etc?

Thanks in advance for any clarification.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 May 2006 19:46:38 -0400

> What are the types of CB information shared between the peer and the server?

Section 5.11 of eap-keying draft mentions Called-Station-Id,
Calling-Station-Id, NAS-Identifier, NAS-IP-Address and
NAS-IPv6-Address.  There can be others, but it depends on each lower
layer.

> the peer and the server know about the authenticator?

It seems there are different opinions about CB data.  Please see 
my comments below to express my opinion.

> make sense for the peer to send the CB info and the server to verify it.

It should not be Kbytes of data.  It should be the same order as the
link-layer channel binding data which is mixed to generate link-layer
keys from EAP-generated keying material, or the link-layer forms a key
hierarchy, then it should the same order as the highest level
link-layer channel binding data in the hierarchy.  I don't really
think whole bunch of link-layer channel binding data of the entire
hierarchy needs to be part of EAP CB data.  This is because even
link-layer hierarchical channel binding does not use level N channel
binding data to generate level N-1 key.  Why EAP should use level N
data for CB?  Having said that I can't think of a situation where the
peer sees only subnet of EAP CB data advertised by authenticator.

Note that this argument should be generally applicable when CB is
applied to any key hiearchy including a key hierarchy between
authenticator and EAP server, if it is formed.  Section 4.3
(Hierarchical Channel Binding) of draft-ohba-eap-channel-binding-00 is
described based on this concept.

> does it make sense to do some of it in the method and the rest in L2 etc?

There is no need to exchange authenticated CB info between peer and
server, this is just redundant.  The peer sees the CB data advertised
by authenticator and the server pre-configures the same data.  The
peer and server only mix the data into keying material exported by EAP
method and the server transports it to the authenticator.  After that,
the peer and authenticator lower-layer entities verify the possession
of the mixed key using SAP.

Regards,
Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 08 May 2006 09:25:44 -0700

Thanks Yoshi.  Still trying to understand, please see inline:

>NAS-IPv6-Address.  There can be others, but it depends on each lower

Agreed that the type of information depends on the lower layer, but 
you seem to list only IDs and addresses above.  So, can it only be 
IDs and addresses?

One of the follow-up questions is whether the peer and the server 
have an identical view of the authenticator.

>peer sees only subnet of EAP CB data advertised by authenticator.

I think we are getting into solutions here, I am looking to scope the 
definition.

>of the mixed key using SAP.

I think this goes back to the question of whether the peer and the 
server see the same information about the Authenticator, or might the 
peer see only a subset of what the server might see?

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 08 May 2006 15:42:43 -0400

> you seem to list only IDs and addresses above.  So, can it only be 

Please see Jari's email in this thread on this.

> have an identical view of the authenticator.

The peer and the server needs to have an identical view of the CB
data.

> I think we are getting into solutions here, I am looking to scope the 

You may be right that this is getting into a solution space a bit, but
this kind of guidance might help lower-layer SDOs to define their CB
data.  On the other hand, if we only say that CB data contains
security and charging related information, that would be general and
less solution specific, it might not help much to answer to your
question.

> peer see only a subset of what the server might see?

I don't think the peer and server need to have the same view about the
entire information about authenticator, but they need to have the same
view about CB data the advertised by authenticator when creating
keying material due to key scoping issue.

Yoshihiro Ohba