Subject: [eap] Strawman -10

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 23 Jan 2006 09:14:21 -0800

A strawman -10 draft is available, incorporating the changes from the 
proposed resolutions of issues 309 and 320:

http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-10.txt

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

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 30 Jan 2006 16:30:52 -0500

Hi Bernard

I have a question regarding draft-ietf-eap-keying-10.txt

In figure 3, EMSK seems now exported to AAA layer or Lower layer.  Is 
that correct?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 31 Jan 2006 01:45:35 -0800

>In figure 3, EMSK seems now exported to AAA layer or Lower layer.  Is that 
>correct?

The text forbidding the export was removed in Issue 320 with the following 
proposed change, so it would appear to me that the export is now allowed.

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 31 Jan 2006 10:39:54 -0500

Bernard Aboba wrote:

> The text forbidding the export was removed in Issue 320 with the 
> following proposed change, so it would appear to me that the export is 
> now allowed.

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?

Thanks.

> server or peer from which the EMSK could be computed without breaking 
> some cryptographic assumption, such as inverting a one-way function."
>
>
>
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 31 Jan 2006 09:01:44 -0800

>authenticator : will only MSK be available to lower layer as usual or both 
>(MSK,EMSK) now?

Note that the language relating to transport of the EMSK has not been 
touched so that restriction remains.

In the passthrough case, the authenticator lower layer will not receive the 
EMSK, whereas it will receive it in the standalone case.  Since the peer 
does not know which case is being run, this implies that the lower layer 
cannot derive the TSKs directly from the EMSK, but only from a quantity that 
is always available within the authenticator lower layer.

As long as the keys that the lower layer depends on are always available on 
the authenticator, this doesn't violate mode independence from the  peer's 
point of view.  I'm not sure it necessarily violates it on the authenticator 
either, as long as the EMSK is destroyed after computation of the AMSK.  If 
that is done, the end cryptographic state on the authenticator is the same 
in either the pass-through or standalone case.

One advantage of this approach is that it keeps implementation of 
cryptography out of the EAP layer.  Allowing cryptographic operations in the 
EAP layer is a problem because EAP does not  support cryptographic 
negotiation, so that negotiation of cryptographic algorithms such as PRFs 
would require changes to existing EAP methods.  By doing those calculations 
in the lower layer, instead, the Secure Association Protocol can negotiate 
the cryptographic algorithms and this problem is avoided.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 31 Jan 2006 16:43:54 -0500

Bernard Aboba wrote:

>>> following proposed change, so it would appear to me that the export 
>>> is now allowed.
>>
>>

Yes i noticed that. My thought was  that,  depending on the case, 
authenticator lower layer would receive MSK, EMSK or not. Your answers 
confirm that.

>
> In the passthrough case, the authenticator lower layer will not 
> receive the EMSK, whereas it will receive it in the standalone case.  
> Since the peer does not know which case is being run, this implies 
> that the lower layer cannot derive the TSKs directly from the EMSK, 
> but only from a quantity that is always available within the 
> authenticator lower layer.

In the case of pass-through authenticator, MSK is available, but when 
you say quantity (of EMSK I guess),  you mean any AMSK derived from EMSK?? .

>
> As long as the keys that the lower layer depends on are always 
> available on the authenticator, this doesn't violate mode independence 
> from the  peer's point of view.  I'm not sure it necessarily violates 
> it on the authenticator either, as long as the EMSK is destroyed after 
> computation of the AMSK.  

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?

> If that is done, the end cryptographic state on the authenticator is 
> the same in either the pass-through or standalone case.

About the end state,  I agree.

> cryptography out of the EAP layer.  Allowing cryptographic operations 
> in the EAP layer is a problem because EAP does not  support 
> cryptographic negotiation, so that negotiation of cryptographic 
> algorithms such as PRFs would require changes to existing EAP 
> methods.  By doing those calculations in the lower layer, instead, the 
> Secure Association Protocol can negotiate the cryptographic algorithms 
> and this problem is avoided.

This makes sense for me. Personally I think clarifying this in some 
place might be useful.

Thanks.