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