eap Mailing List: Re: Re: issue 357: Channel Binding Definition

[Yoshihiro Ohba (yohba]

On Mon, May 08, 2006 at 09:25:44AM -0700, Lakshminath Dondeti wrote:
> Thanks Yoshi.  Still trying to understand, please see inline:
> 
> At 04:46 PM 5/5/2006, Yoshihiro Ohba wrote:
> >On Fri, May 05, 2006 at 11:01:42AM -0700, Lakshminath Dondeti wrote:
> >> 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?
> >
> >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.
> 
> 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?

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

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

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

> 
> 
> >>
> >> 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?
> >
> >It seems there are different opinions about CB data.  Please see
> >my comments below to express my opinion.
> >
> >>
> >> 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.
> >
> >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.
> 
> I think we are getting into solutions here, I am looking to scope the 
> definition.

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.

> 
> 
> >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.
> >
> >>
> >> 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?
> >
> >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.
> 
> 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?

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


> 
> regards,
> Lakshminath
> 
> 
> >Regards,
> >Yoshihiro Ohba
> >
> >
> >>
> >> Thanks in advance for any clarification.
> >>
> >> regards,
> >> Lakshminath
> >>
> >>
> >> At 09:40 AM 5/5/2006, Narayanan, Vidya wrote:
> >>
> >> >>
> >> >> >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
> >>
> >>
> 
>