Subject: RE: [eap] Strawman -10

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 1 Feb 2006 21:24:40 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, February 01, 2006 9:45 AM
> To: [email-masked]; Salowey, Joe
> Cc: [email-masked]
> 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:
http://lists.frascone.com/mailman/listinfo/eap

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 1 Feb 2006 21:28:05 -0800

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Wednesday, February 01, 2006 12:03 PM
> To: Bernard Aboba
> Cc: [email-masked]; Salowey, Joe; [email-masked]
> On Wed, Feb 01, 2006 at 09:44:59AM -0800, Bernard Aboba wrote:
> > existing EAP methods wouldn't be usable on some lower 
> layers.   One of the 
> 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)

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