issue 357: Channel Binding Definition

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


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

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

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

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.

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

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.

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
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

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?

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


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


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

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

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

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

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
> >>
> >>
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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