List Info

Thread: Strawman -10




Strawman -10
user name
2006-02-01 20:15:53
>It would be possible to define a particular hash
algorithm as the
>default algorithm for prf+ in
draft-ohba-eap-channel-binding for
>existing EAP methods.
>
>On the other hand, EAP methods would still need to have
a
>functionality to negotiate on use of Channel Binding if
Channel
>Binding is defined an optional functionality.  Or do you
expect lower
>layers to negotiate on use of Channel Binding in which
case Channel
>Binding would not be usable for already deployed NASes?

A lower layer can include the use of Channel Bindings in
computation of 
keys.  One example of this is IEEE 802.11r, which includes
channel binding 
parameters in the computation of keys at various levels
(PMK-R0, PMK-R1, 
etc.).  At each level of the key hierarchy, different
channel binding 
parameters are mixed in.  The end result is that the same
PTKs cannot be 
derived without agreement on the Channel Binding parameters
between the EAP 
peer and server. Note that IEEE 802.11r does not mix the
Channel Bindings 
into the key transported from AAA server to authenticator;
it does the 
mixing *afterwards*.   The advantage of this is that code on
the AAA server 
does not need to change to support Channel Bindings, and
neither do the EAP 
methods need to change.

The negotiation of the channel binding functionality can
also occur in the 
lower layer.  For example, in IEEE 802.11 different things
are done in 11r 
vs. 11i.


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

Arhives: http://lists.
frascone.com/pipermail/eap
Strawman -10
user name
2006-02-01 20:40:38
On Wed, Feb 01, 2006 at 12:15:53PM -0800, Bernard Aboba
wrote:
> >It would be possible to define a particular hash
algorithm as the
> >default algorithm for prf+ in
draft-ohba-eap-channel-binding for
> >existing EAP methods.
> >
> >On the other hand, EAP methods would still need to
have a
> >functionality to negotiate on use of Channel
Binding if Channel
> >Binding is defined an optional functionality.  Or
do you expect lower
> >layers to negotiate on use of Channel Binding in
which case Channel
> >Binding would not be usable for already deployed
NASes?
> 
> A lower layer can include the use of Channel Bindings
in computation of 
> keys.  One example of this is IEEE 802.11r, which
includes channel binding 
> parameters in the computation of keys at various levels
(PMK-R0, PMK-R1, 
> etc.).  At each level of the key hierarchy, different
channel binding 
> parameters are mixed in.  The end result is that the
same PTKs cannot be 
> derived without agreement on the Channel Binding
parameters between the EAP 
> peer and server. Note that IEEE 802.11r does not mix
the Channel Bindings 
> into the key transported from AAA server to
authenticator; it does the 
> mixing *afterwards*.   The advantage of this is that
code on the AAA server 
> does not need to change to support Channel Bindings,
and neither do the EAP 
> methods need to change.
> 
> The negotiation of the channel binding functionality
can also occur in the 
> lower layer.  For example, in IEEE 802.11 different
things are done in 11r 
> vs. 11i.  
> 

What problem is being solved by so called "channel
binding" in IEEE
802.11r?  If AP is lying to both STA and AAA server, then
how can STA
detect it?  Also what do you mean by "agreement on the
Channel Binding
parameters between the EAP peer and server"?

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

Arhives: http://lists.
frascone.com/pipermail/eap
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )