Subject: RE: [eap] Strawman -10

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 31 Jan 2006 14:01:26 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, January 31, 2006 1:37 PM
> To: Salowey, Joe
> Cc: [email-masked]
> Subject: RE: [eap] Strawman -10
> 
> >[Joe] I must not have been clear. That was not my intent, 
> which change
> >request was this?  The EMSK must not be directly used by the lower
> >layer.  If it is then you might as well just eliminate it since it
> >serves the same purpose as the MSK.
> 
> Issue 320, which you submitted on December 1, 2005 removes 
> the prohibition 
> on lower layers obtaining the EMSK.
> 
> It is possible to say that the EMSK "must not be directly 
> used by the lower 
> layer" without prohibiting lower layer access to the EMSK.  
> So those two 
> statements are not necessarily inconsistent.
> 

[Joe] yes. From an implementation point of view it is possible, however
architecturally there needs to be separation. In a particular local
authenticator implementation the lower layer may have access to the
EMSK, however things should not be defined such that a lower layer must
have access to the EMSK. 

> For example, the lower layer could be allowed to obtain the 
> EMSK but be 
> prohibited from transporting it or using it directly.
> 
> The difference is subtle, but potentially important for 
> issues such as 
> crypto-agility.  Allowing the lower layer to obtain the EMSK 
> enables the 
> lower layer to negotiate the PRFs used in AMSK generation, 
> whereas this is 
> not possible if AMSK generation is handled in the EAP layer.  It also 
> maintains backward compatibility so that a lower layer using 
> the AMSK can be 
> introduced without requiring changes to existing EAP implementations.
> 
> As long as the EAP peer does not need to be aware of whether the 
> authenticator is configured in standalone or pass-through 
> mode, I think that 
> the requirements of mode independence have been met.

[Joe] This worries me.  It ties the key derivation to the lower layer,
which could be problematic.  A goal of the EMSK to AMSK derivation is to
contain the problem of a misbehaving lower layer to the lower layer
itself.  A lower layer that determines the key derivation algorithm
conflicts with this goal.  What happens if there are multiple AMSKs
being derived for different purposes? Who decides the KDF?   

I think I would prefer to see a default KDF specified with the
capability of an EAP method to override it with a KDF of its own.  

_________________________________________________________________
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: Tue, 31 Jan 2006 17:31:19 -0800

> From: Rafa Marin Lopez [mailto:[email-masked]] 
> Sent: Tuesday, January 31, 2006 1:47 PM
> To: Salowey, Joe
> Cc: Bernard Aboba; [email-masked]
> 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
management layer or component.  Not the lower layer. 

> >
> >  
> >
> >>Thanks.
> >>
> >>    
> >>
> >>>      
> >>>
> >>--------------------------------------------------------------
> >>--------------------------------------------------------------
> >>------------ 
> >>    
> >>
> >>>Change
> >>>
> >>>"The EMSK MUST NOT be provided to the lower layer, nor is 
> >>>      
> >>>
> >>it permitted
> >>    
> >>
> >>>to pass any quantity to the lower layer from which the 
> EMSK could be
> >>>computed without breaking some cryptographic assumption, such as
> >>>inverting a one-way function."
> >>>
> >>>To
> >>>
> >>>"The EMSK MUST NOT be provided to an entity outside the EAP 
> >>>      
> >>>
> >>server or
> >>    
> >>
> >>>peer,  nor is it permitted to pass any quantity to an 
> >>>      
> >>>
> >>entity outside 
> >>    
> >>
> >>>the EAP
> >>>server or peer from which the EMSK could be computed 
> >>>      
> >>>
> >>without breaking 
> >>    
> >>
> >>>some cryptographic assumption, such as inverting a one-way 
> >>>      
> >>>
> >>function."
> >>    
> >>
> >>>
> >>>
> >>>      
> >>>
> >>-- 
> >>------------------------------------------------------
> >>Rafael Marin Lopez
> >>Faculty of Computer Science-University of Murcia
> >>30071 Murcia - Spain
> >>Telf: +34968367645    e-mail: [email-masked]
> >>------------------------------------------------------
> >>
> -- 
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645    e-mail: [email-masked]
> ------------------------------------------------------
>