headers
Salowey, Joe | 1 Feb 2006 02:31
Picon
Favicon

RE: Strawman -10


> -----Original Message-----
> From: Rafa Marin Lopez [mailto:rafa <at> dif.um.es] 
> Sent: Tuesday, January 31, 2006 1:47 PM
> To: Salowey, Joe
> Cc: Bernard Aboba; eap <at> frascone.com
> Subject: Re: [eap] Strawman -10
> 
> 
> >>I see. But I was wondering for example in the case of standalone 
> >>authenticator : will only MSK be available to lower layer 
> as usual or 
> >>both (MSK,EMSK) now?
> >>
> >>    
> >>
> >
> >[Joe] In order to preserve mode independence the EMSK must not be
> >directly consumed by the lower layer.  The lower layer must 
> not require
> >direct access to the EMSK to function.  However, the lower layer may
> >rely upon keys derived from the EMSK.  
> >  
> >
> Then my question is what layer is going to derive keys (i.e. 
> AMSK) from 
> EMSK?   EAP layer?.
> 
[Joe] I would say the EAP layer (if there is such a thing).  If you
don't like the EAP layer then it would be something like an EMSK
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 1 Feb 2006 18:44
Picon
Favicon

Re: Strawman -10

>The channel-binding draft allows KDF to be provided by an EAP method
>while still satisfying the requirements of mode independence.

Do we really want to require EAP methods to support KDFs in order to enable 
the lower layer to generate keys from the EMSK?  That would mean that 
existing EAP methods wouldn't be usable on some lower layers.   One of the 
major advantages of EAP is the ability to support many lower layers.

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

Arhives: http://lists.frascone.com/pipermail/eap
Permalink | Reply | 10 comments |
headers
Soliman, Hesham | 1 Feb 2006 20:02

Request for expert review for EAP SAKE

Chairs, 

The name of the EAP MAKE method was changed to EAP SAKE. 
The new draft was submitted and is available at:

http://www.ietf.org/internet-drafts/draft-vanderveen-eap-sake-00.txt

The authors request that we arrange an Expert review for the 
draft in order to get allocated an EAP method type. 
Please let us know if there is anything that we need to do
in order to get the expert review started. 

Cheers,
Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

Arhives: http://lists.frascone.com/pipermail/eap
Permalink | Reply | 0 comments |
headers
Yoshihiro Ohba | 1 Feb 2006 21:02

Re: Strawman -10

On Wed, Feb 01, 2006 at 09:44:59AM -0800, Bernard Aboba wrote:
> >The channel-binding draft allows KDF to be provided by an EAP method
> >while still satisfying the requirements of mode independence.
> 
> Do we really want to require EAP methods to support KDFs in order to enable 
> the lower layer to generate keys from the EMSK?  That would mean that 
> existing EAP methods wouldn't be usable on some lower layers.   One of the 
> major advantages of EAP is the ability to support many lower layers.
> 

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?

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
Permalink | Reply | 2 comments |
headers
Bernard Aboba | 1 Feb 2006 21:15
Picon
Favicon

Re: Strawman -10

>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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yoshihiro Ohba | 1 Feb 2006 21:40

Re: Strawman -10

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Salowey, Joe | 2 Feb 2006 06:24
Picon
Favicon

RE: Strawman -10


> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba <at> hotmail.com] 
> Sent: Wednesday, February 01, 2006 9:45 AM
> To: yohba <at> tari.toshiba.com; Salowey, Joe
> Cc: eap <at> frascone.com
> Subject: Re: [eap] Strawman -10
> 
> >The channel-binding draft allows KDF to be provided by an EAP method
> >while still satisfying the requirements of mode independence.
> 
> Do we really want to require EAP methods to support KDFs in 
> order to enable 
> the lower layer to generate keys from the EMSK?  That would mean that 
> existing EAP methods wouldn't be usable on some lower layers. 
>   One of the 
> major advantages of EAP is the ability to support many lower layers.
> 
[Joe] Why wouldn't existing EAP methods be usable on some lower layers?
If the KDF is not acceptable then the EAP method probably isn't either.

Perhaps we can define an IANA registry of KDFs.  An implementation
SHOULD/MUST support a default one and MAY support others.  The lower lay
can negotiate between the supported KDFs.  The KDF function prototype
would need to have a parameter that selects the KDF to use and there
would need to be a way to query for supported KDFs.  It seems like this
could be carried in the AAA messaging if necessary.  This seems a little
complex but I think it achieves what you want.  
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Salowey, Joe | 2 Feb 2006 06:28
Picon
Favicon

RE: Strawman -10


> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba <at> tari.toshiba.com] 
> Sent: Wednesday, February 01, 2006 12:03 PM
> To: Bernard Aboba
> Cc: yohba <at> tari.toshiba.com; Salowey, Joe; eap <at> frascone.com
> Subject: Re: [eap] Strawman -10
> 
> On Wed, Feb 01, 2006 at 09:44:59AM -0800, Bernard Aboba wrote:
> > >The channel-binding draft allows KDF to be provided by an 
> EAP method
> > >while still satisfying the requirements of mode independence.
> > 
> > Do we really want to require EAP methods to support KDFs in 
> order to enable 
> > the lower layer to generate keys from the EMSK?  That would 
> mean that 
> > existing EAP methods wouldn't be usable on some lower 
> layers.   One of the 
> > major advantages of EAP is the ability to support many lower layers.
> > 
> 
> 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.
> 
[Joe] Yes, this is what we did with the original EMSK/AMSK document.
(which was incorporated into the eap-key document and then removed
again)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alper Yegin | 5 Feb 2006 13:01

Introductory material


Can anyone point me to an introductory reading material on EAP (PPT, etc.)? 

Alper

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

Arhives: http://lists.frascone.com/pipermail/eap
Permalink | Reply | 0 comments |
headers
Jari Arkko | 7 Feb 2006 14:55

Re: Strawman -10

Bernard Aboba wrote:

>> The channel-binding draft allows KDF to be provided by an EAP method
>> while still satisfying the requirements of mode independence.
>
>
> Do we really want to require EAP methods to support KDFs in order to 
> enable the lower layer to generate keys from the EMSK?  That would 
> mean that existing EAP methods wouldn't be usable on some lower 
> layers.   One of the major advantages of EAP is the ability to support 
> many lower layers.

What Joe proposes does not lead to that problem. He said "default + optional
negotiation ability in methods".

Also, lower layer usage of EAP keys != EMSK usage. All current link layers
use MSK. If the link layers want to do link-layer specific things, they 
already
can. Why would we want to introduce another quantity to do the same thing?

--Jari

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

Arhives: http://lists.frascone.com/pipermail/eap
Permalink | Reply | 6 comments |

Gmane