KDF Negotiation for AMSK derivation

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:Bernard_Abobahotmail.com] 
Sent: Monday, March 20, 2006 5:38 AM
To: eapfrascone.com
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