Hi Dan,
I am not a MOARK expert nor a HOAKEY expert. But they way I see it is that
HOAKEY may need to export a root key around yet other applications may not.
Those it is a good idea the the real mother of root keys -- EMSK -- remain in
the EAP layer so it can be used to derive other keys that can be or may not be
exportable.
The notion of doing something to prevent temptation sounds like a religious
thing. SDOs will just derive a key and export it out.
-----Original Message-----
From: Dan Harkins [mailto:dharkins(_at_)lounge(_dot_)org]
Sent: Thursday, March 20, 2008 11:48 AM
To: Avi Lior
Cc: Dan Harkins; Jari Arkko; ietf(_at_)ietf(_dot_)org; Bernard Aboba
Subject: RE: EAP applicability (Was: Re: IETF Last Call on
Walled Garden Standard for the Internet)
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(_at_)lounge(_dot_)org]
Sent: Monday, March 17, 2008 4:52 PM
To: Jari Arkko
Cc: Avi Lior; ietf(_at_)ietf(_dot_)org; 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf