eap Mailing List: Re: hopefully final changes for draft-ietf-eap-keying

[Dan Harkins (dharkins]

  11r refused to put a 3-party protocol in their draft (well one got
voted in but then in a sneaky low-down manner they removed it). Their
position was that the IETF would define a 3 party protocol for them to
use. Their position wasn't that simple key sharing would be permitted.

  We don't change laws (like the one on drunk driving) because certain
people violate them (like Lindsey Lohan). The prohibition on key
sharing is there for a good reason; let's keep it.

  Dan.

On Fri, November 16, 2007 9:05 pm, Yoshihiro Ohba wrote:
> It seems that the change came from the following IESG DISCUSS comment:
>
> https://datatracker.ietf.org/idtracker/draft-ietf-eap-keying/comment/73693/?
>
> "
>>An EAP authenticator MUST NOT share any keying material with
>>another EAP authenticator, since if one EAP authenticator were
>>compromised, this would enable the compromise of keying material on
>>another authenticator.
>
> This text needs to be fixed to allow 802.11r style key hierarchies.
> Previous text gets this correct.
> "
>
> As far as I understand 802.11r has a distributed authenticator model
> in which an authenticator may span multiple APs.  Hence I don't think
> this implies key sharing among multiple authenticators.
>
> Regards,
> Yoshihiro Ohba
>
>
>
> On Fri, Nov 16, 2007 at 04:48:46PM -0800, Bernard_Aboba [at] hotmail.com 
> wrote:
>> Forwarding for Dan.
>>
>>
>> --------------------------------------------------------------------------------
>> From: Dan Simon
>> Sent: Friday, November 16, 2007 9:10 AM
>> To: eap [at] frascone.com
>> Cc: jari.arkko [at] piuha.net; iesg [at] ietf.org
>> Subject: Re: [eap] hopefully final changes for draft-ietf-eap-keying
>>
>>
>> Having looked over the proposed changes, I share the concern about the
>> modified language relating to key-sharing.  The new language is
>> disturbingly vague-would any key-sharing among authenticators or EAP
>> servers be acceptable, as long as the shared keys have passed through a
>> key derivation step?  Since virtually all the keys in the hierarchy were
>> derived at some point, the restriction on key-sharing would effectively
>> disappear completely under the new language.
>>
>> I would propose more restrictive changes to the language, but after
>> looking at the documents of the HOKEY group (whence, as I understand it,
>> the initiative to loosen the key-sharing language emerged), I can't for
>> the life of me see any incompatibilities between their work and the
>> current language.  Perhaps someone could articulate a clear, plausible
>> example of a case where adherence to the current language significantly
>> impedes HOKEY progress-or for that matter, progress on the design of any
>> other useful protocol standard?
>>
>> So my vote would be to leave the key-sharing portion of the text from
>> -18 intact.
>>
>>                                 Dan Simon
>
>> _________________________________________________________________
>> 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
>