My terminology may be mixed up, but are we talking about the
base
algorithm for a PRF and not the negotiation of the full key
derivation function?
To give an example,
IKEv2's KDF (although 4306 doesn't call it a KDF) is
defined as:
prf+ (K,S) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
4307 lists the PRF base algorithms:
PRF_HMAC_MD5 1 [RFC2104] MAY
PRF_HMAC_SHA1 2 [RFC2104] MUST
PRF_AES128_CBC 4 [AESPRF] SHOULD+
We could be talking about negotiating the "KDF"
which to me means
either IKEv2's prf+ or TLS prf and so on. If we are
talking about
the underlying algorithm negotiation (which is my
preference) then we
have a choice of a hash or a cipher based PRF. Bernard's
concern
seems to be about a particular hash algorithm.
A clarification will be useful for me to follow this
discussion.
Oh, another thing here is (this came up in a discussion
between Vidya
N, Joe S and David M) whether we can just rely on the EAP
methods to
handle this. I do note the comment about existing methods
don't
support negotiation, but from my recollection they are also
all over
the place in EMSK generation also.
Finally, Bernard, I was wondering if you can provide more
details on
why lower layers can negotiate the algorithms, while it is
difficult
for even new methods? Thanks.
best regards,
Lakshminath
At 05:37 AM 3/20/2006, Bernard Aboba wrote:
>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
|