> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba hotmail.com]
> Sent: Thursday, March 16, 2006 8:30 PM
> To: eap frascone.com
> Subject: [eap] Re: m.getKey() and RFC 4137
>
> Narayanan, Vidya said:
>
> "I am surprised that you are willing to accept
(a)
Given how many
> legacy methods are still in use, I'd strongly vote for
(b) here. It is
> impractical to make changes to methods to accommodate
the use of
> EMSK/AMSK. As you point out, what we pick here may
depend on
> whether we
> pick (1) or (2) below - and (1) makes much more sense
to me
> for reasons
> stated below".
>
> I agree with this. Changing EAP methods to negotiate
KDFs
> would in practice
> be very difficult -- even if the industry were willing
to do
> the upgrades
> (which they probably wouldn't be). In practice, TLS
(on
> which many methods
> are based) does not support KDF negotiation for its own
use, let alone
> negotiation of KDFs to be used to generate AMSKs.
Attempting
> to convince
> the TLS WG to add support for cryptographic negotiation
for ancillary
> purposes would be an uphill battle that seems unlikely
to succeed.
>
[Joe] If anything, this statement argues for the method to
define the
KDF based on the cryptographic operations it supports.
> Jari said:
>
> "Based on this my current preference is (1). But
its a close call."
>
> I've just re-read RFC 4137, and it seems to me that
choice 2 is fairly
> well ingrained in that document.
<snip>
>
> Given this, I wonder whether the horse hasn't already
left the barn.
>
[Joe] RFC 4137 did not consider the usage of the EMSK,
therefore I don't
think the horse was ever in that barn.
>
>
____________________________________________________________
_____
> 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
|