Subject: RE: [eap] Strawman -10

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 1 Mar 2006 17:38:15 -0500

Madjid>>Again, why is deletion of EMSK after generation of one AMSK is a
requirements. What if we need to create multiple AMSKs and that at
multiple occassions?

Well, actually, lower layer authenticator implementation should expect 
(MSK,EMSK) in the case EAP method is executed by the standalone 
authenticator or (MSK,AMSK) in the case EAP method is executed by 
backend authentication server. If it receives (MSK,EMSK) should create 
AMSK and delete EMSK. If it receives (MSK,AMSK) , that's all, correct?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 1 Mar 2006 17:43:46 -0500

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

Madjid>> Are you saying all EMSK-AMSK generations will have to follow
the same KDF defined based on EAP method? And ruling out use of
different KDFs for different AMSKs?

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 1 Mar 2006 15:16:34 -0800

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 2:38 PM
> To: Rafa Marin Lopez; Bernard Aboba
> Cc: [email-masked]
> Subject: RE: [eap] Strawman -10
> 

[Joe] Not really, strictly speaking the lower layer shouldn't expect to
receive the EMSK as that would break mode independence.  An
architectural description should not have the lower layer receiving the
keys. From a supplicant perspective it must appear the same whether an
external EAP-Server or a collocated EAP server is used.  Now I don't
know what is going on inside your box, it could all be monolithic when a
internal EAP server is used but that shouldn't be visible to the
external world.  If I was interested in cryptographic module separation
I might not be too happy if you shared the EMSK with the lower layer.

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 1 Mar 2006 16:06:52 -0800

> Sent: Wednesday, March 01, 2006 2:44 PM
> To: Salowey, Joe; Bernard Aboba
> Cc: [email-masked]
[Joe] Yes. A single coordinated KDF definition is a robust and
deterministic way to avoid one key derivation scheme compromising other
keys derived from another scheme.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 05 Mar 2006 21:32:04 +0200

Bernard Aboba wrote:

>> The problem with the lower layer usage of EMSK is that
>> we know that its quite likely there will be some link layer
>> which gets the key generation wrong. At that point, the
>> EMSK is compromised for other link layers, too.
>
>
> What other link layers?  The document talks about "the lower layer" 
> throughout, not multiple lower layers.

True. But what we are doing in the key management framework
does also have an effect on future use of EAP. I am convinced
that we will see cross-access technology handover optimizations.
If we do not keep parts of the key hierarchy "safe" for such
extensions, we'll be in trouble later.

Anyway, -10 keeps EMSK safe, so I have no problem with the
current document.

(But there are different variations of "safe" -- your approach
and what Joe has been advocating. More on that in subsequent
e-mails.)

--Jari