RE: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  Hi Avi,

  I agree that simply removing the MOARK (aka the DSRK) will not prevent
EMSK misuse but it will remove a large temptation to misuse. The sole
purpose I can see in the DSRK is to get around the fact that we do not
export the EMSK. If there are valid reasons to not export the EMSK then
those reasons apply equally to the DSRK and it should be eliminated. If
there are no valid reasons to not export the EMSK then let's just export
it and then the need for the DSRK goes away. Either way the DSRK should
be eliminated.

  If WiMAX wants constructive instruction from the IETF I suggest it
make a request through the 802.16 liaison to IETF.

  regards,

  Dan.

On Thu, March 20, 2008 7:58 am, Avi Lior wrote:
> FYI. In WiMAX we derive keys directly from EMSK.  We don't use the MOARKs
> ;-)
>
> It maybe a good idea or a bad idea -- we haven't had a chance to look at
> it because we did our stuff before the MOARK was conceived. We did align
> at one point with Joe's draft.
>
> I am not sure whether defining a MOARK is the root of all evil.  It maybe
> a good idea to derive keys from it in general or it maybe a good idea for
> HOAKEY to derive its keys from it.
>
> Simply removing MOARK is not sufficient to prevent the EMSK to be
> missused.  I think we need to provide the text to describe the pitfalls of
> EMSK missuse.
>
> Also to note, in WiMAX the keys we derive from EMSK are for MIP and other
> network centric applications such as over the air provisioning.  I don't
> want to give the impression that in WiMAX we are using the EMSK for
> anything and everything.  At the same time, I don't want to give the
> impression that that is all that WiMAX will use the EMSK for in the
> future.  To be sure it is very tempting indeed to have a source of keying
> material that is known at the mobile and at the network.  That is why I
> look forward to *constructive* instructions from the IETF.
>
>
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:dharkins@xxxxxxxxxx]
>> Sent: Monday, March 17, 2008 4:52 PM
>> To: Jari Arkko
>> Cc: Avi Lior; ietf@xxxxxxxx; Bernard Aboba
>> Subject: Re: EAP applicability (Was: Re: IETF Last Call on
>> Walled Garden Standard for the Internet)
>>
>>
>>   Hi Jari,
>>
>> On Thu, March 13, 2008 8:49 pm, Jari Arkko wrote:
>> > Avi,
>> >
>> >>> For what it is worth, this ex-EAP co-chair also thinks
>> that the use
>> >>> of EAP keys for applications is a very bad idea.
>> >>>
>> >>
>> >> Why?
>> >>
>> >
>> > For a number of reasons. Take this from someone who has
>> actually tried
>> > to do this in the distant past and has realized that it was
>> a bad idea.
>> >
>> > But first let me clarify that I'm not criticizing HOKEY for
>> EAP keys
>> > in any way; HOKEY is a fine application for EAP keys. The document
>> > that started this thread can be fixed by better IANA and
>> applicability
>> > sections. I've also changed the subject to reflect the new topic.
>>
>>   Actually I think it's a little more technical than
>> editorial. This problem is due to the fact that HOKEY is
>> extracting a key derived from the EMSK and making that "The
>> Mother Of All Root Keys" (MOARK), which can be used to derive
>> all keys for all purposes to solve all problems in the world.
>>
>>   The document can be fixed by removing the MOARK from the
>> draft and having HOKEY define a _HOKEY-specific_ key derived
>> from the EMSK. That HOKEY-specific key is used for HOKEY and
>> HOKEY only. If some other key usage is needed then it can
>> define another way to extract it's needed keying material
>> from the EMSK, and hopefully that process would be done in
>> the IETF (at least the chances are greater that it would be
>> done in the IETF if it's based on the EMSK and not the MOARK).
>>
>>   This has the added benefit of simplifying the key hierarchy.
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>>
>


_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]