Subject: Re: [HOKEY] IETF Last Call on Walled Garden Standard for the Internet

From: "Dan Harkins" <[email-masked]>
Date: Tue, 18 Mar 2008 18:22:57 -0700 (PDT)

Hi Avi,

On Tue, March 18, 2008 3:13 pm, Avi Lior wrote:
[snip]
> I suggest we discuss the issues with deriving keys from EMSK so that
> people can make informed decisions.  Lets keep the FUD factor low.

  Good idea. Can we start with the Mother Of All Root Keys (MOARK) that
is derived from the EMSK? This seems like a particularly un-scope-able
and undefined key. It is not needed for Handover Keying; all HOKEY needed
to do was define a HOKEY-specific key from the EMSK but it didn't, it
defined a MOARK, and then a HOKEY-specific key is being derived from the
MOARK.

  Since the MOARK is really the only key being derived from the EMSK
I guess this makes for a nicely constrained discussion.

  Dan.

_______________________________________________
HOKEY mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hokey

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Mar 2008 09:45:47 -0700 (PDT)

Hello,

  My apologies for being obtuse. This Mother of All Root Keys I've been
describing is what the EMSK Key Hierarchy calls the DSRK.

  The "HOKEY key" that the ERP/ERX draft uses can be derived in one of
two ways:

    EMSK
      |
    USRK    <-- the "HOKEY key", aka rRK

or like this:

    EMSK
      |
    DSRK    <--- the MOARK
      |
   DSUSRK   <-- the "HOKEY key", aka rRK

This latter derivation is the one that will be used in practice, I believe.

  This DSRK is not properly defined and cannot be properly scoped. It
really has nothing to do with "Handover Keying" which is what HOKEY is
supposed to be working on. I believe the DSRK is problematic and the
ability to derive a DSRK should be removed from the ESMK key hierarchy
draft and the corresponding change be made to the ERP/ERX draft to remove
reference to using a DSRK to derive HOKEY keys.

  This change would also simplify the key hierarchy and remove a
"you can do it this way, or you can do it that way" option which
experience has shown is a really bad idea.

  regards,

  Dan.

On Tue, March 18, 2008 6:22 pm, Dan Harkins wrote:
> IETF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 19 Mar 2008 09:53:58 -0700

The DSRK can be scoped just as the EMSK can be scoped.

regards,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Mar 2008 10:55:45 -0700 (PDT)

> The DSRK can be scoped just as the EMSK can be scoped.

  Really? Is there any context that it can be bound to?

  Furthermore, what is the _purpose_ of this key? Why would someone choose
to derive a DSRK or choose not to derive a DSRK for some particular
hierarchy? If it's just a "some like coke while others like pepsi" kind
of argument then that's just more reason to get rid of it. Experience
from the glamor ciphers and hash algorithms in IKE shows that such
pointless options really have a deleterious affect on the standard.

  regards,

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Mar 2008 11:33:26 -0400

I agree with removing DSRK.  Let me explain one of Dan's points in a
different way.

The domain in DSRK is defined for key management domain for HOKEY, and
ERX is the only usage defined for HOKEY.  It would be very hard to
justify deriving child keys from DSRK for usages other than HOKEY,
given this situation.

Yoshihiro Ohba