Subject: RE: [eap] Re: KDF Negotiation for AMSK derivation

From: "Ryan Hurst" <[email-masked]>
Date: Tue, 21 Mar 2006 10:20:20 -0800

That's a good point, one of the most elegant aspects of EAP is that it
is simply a forwarding layer, this fact gives EAP (like TCP/IP)
longevity but if we integrate crypto into it directly we put this at
risk.

We should also be mindful of the fact that once EAP directly performs
cryptographic operations it too will be subject to FIPS and possibly CC
evaluations; those who have undergone this process understand this has a
high initial and ongoing cost that every implementer would have to
assume.

>From what I can tell it just doesn't make architectural or practical
sense to make the changes necessary to support this this proposal. If
there is a desire to clarify the text of the existing documents to make
things clearer that's one thing, but if any changes will negatively
affect existing implementations and standards they should be dropped or
a covered in a new standards effort.

Ryan M. Hurst 
-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, March 20, 2006 5:38 AM
To: [email-masked]
Subject: [eap] Re: KDF Negotiation for AMSK derivation

Vidya said:

"It is a yet-to-be-defined thing and the computation is only done by the
EAP server and peer - could we just not pick a KDF and mandate it?"

One problem is that the KDF currently suggested for use in computing
AMSKs is based on SHA-1, which NIST has suggested will be deprecated by
2010.  Given the movement of the US and other governments toward the
deployment of EAP-based access control, it is important that
FIPS-certifiable EAP-based solutions continue to be available going
forward.  

Without the possibility of negotiation,  the adoption of a
soon-to-be-deprecated KDF implies that EAP itself will be deprecated by
2010.  As has been noted by others, existing EAP methods do not
negotiate KDFs either for their own use or for use in AMSK generation,
and adding this feature to existing or even new methods would be very
difficult.  For example, TLS (on which many EAP methods are based) does
not yet support KDF negotiation for its own use, let along for use in
AMSK generation. 

These problems largely evaporate if AMSKs are generated by the lower
layer, since the lower layer can then negotiate the appropriate KDF for
their generation.  No changes would be required for existing or new EAP
methods.  No changes would be required to RFC 4137.  

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

Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
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, 22 Mar 2006 05:28:59 -0800

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, March 22, 2006 4:49 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Re: KDF Negotiation for AMSK derivation
> 
> Bernard Aboba wrote:
> 
> >These problems largely evaporate if AMSKs are generated by 
> the lower layer,
> >since the lower layer
> >can then negotiate the appropriate KDF for their generation. 
>  No changes
> >would be required for existing or 
> >new EAP methods.  No changes would be required to RFC 4137. 
> >  
> >
> 
> These are good arguments. Just to clarify what you are proposing --
> are you saying that (a) we should deliver both MSK and EMSK to the
> lower layer and that (b) in addition prohibit AAA from transporting
> the EMSK?
> 
> If yes, I think I agree and maybe that's the way forward. I have
> also re-read the relevant parts of the keying framework document
> and I did not see any text changes that we would need to do.
> It already says that the EMSK is exported to the lower layer and
> that AAA transport of the EMSK is prohibited. Is there something
> else that we need?
> 
> --Jari
>

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 22 Mar 2006 07:19:56 -0800

> Sent: Wednesday, March 22, 2006 5:32 AM
> To: Salowey, Joe
> Cc: Bernard Aboba; [email-masked]
> >>Just to clarify what you are proposing --
> >[Joe] This to me sounds like a contradiction so I do not possibly see
> >how it could work.  Perhaps I am not understanding the term "lower
> >layer". 
> >  
> >
> I think we have a terminology problem. I though what Bernard was
> suggesting is that you provide the MSK and EMSK through the
> API to whatever is calling EAP. And then setting an additional
> requirement to AAA that it cannot transport one of the quantities
> out of the box.
> 
[Joe] If it is only a terminology problem that is OK, I'm not cmpletely
sure that it is. We need to clean up the terminology around lower layer.
My understanding of lower layer is it is the protocol between the EAP
Peer and EAP Authenticator where ciphering may be aplied based on keys
derived from the EAP exchange.  The endpoints of the lower layer do not
always directly invoke EAP.  

We need a different name for the "EAP caller" which is the entity that
is calling the EAP module, which may be located on the authenticator or
on a separate device such as a AAA server.