Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt

["Dan Harkins" <[e-mail]>]

  Hi Lakshminath,

On Thu, January 10, 2008 5:23 pm, Lakshminath Dondeti wrote:
> I will try to be positive Dan :).
>
> One of the reasons I point to the old discussions and consensus
> agreements is that we have a colorful history in the IETF in going over
> things again and again, not always to improve things.  We are also not
> really perfect in our designs either.  So I am not sure really the point
> in debating things endlessly.
>
> But, I respect your insight into protocol design.  You have done this
> longer than I have and perhaps we were all wrong in the key hierarchy
> design.

  Thank you for your kind words. But I don't actually think things were
all wrong necessarily. I had an understanding that the peer would need
to authenticate "the network". I had an understanding that a 3 party
protocol would be needed to ensure that. Therefore, in my mind at least,
a key hierarchy was needed.

  But I had an epiphany in Vancouver. The peer _doesn't care_ about
authenticating "the network". He just wants service. That being the case
he doesn't care if his network access credential (that blob-of-bits that
he proves possession of to obtain network access) is shared between the
distributed entities that comprise "the network". That being the case the
key hierarchy becomes an unnecessary complexity.

  When I described this epiphany to Russ and others it came out as one
of "enterprise" versus "service provider" but I really believe the
distinction is whether the peer requires authentication of the entity
it is connecting to. If it does then I strongly believe a 3 party protocol
is needed, and a key hierarchy thefore makes sense; if it doesn't then
you don't need a 3 party protocol and you don't need a key hierarchy.

  I remember asking you in Vancouver when you thought a 3 party protocol
would be needed in HOKEY. You said, "never".

>          So, let me try another way.  Here is what is needed from the
> EMSK hierarchy.
> * to be able to derive various usage specific keys from the EMSK (by the
> way the typo was the omission of the word "directly"; we don't want to
> use the EMSK directly for reauthentication;)

  Right, we don't want to use the EMSK for HOKEY. So we can derive a
HOKEY key. Specific for allowing the peer to do handoffs. He proves
possession of the HOKEY key and he gets network access.

> * deliver domain specific keys so the domain servers can do the same thing

  Deliver the HOKEY key to the servers through normal AAA mechanisms.

> So this makes the hierarchy
>
>                  EMSK
>                /   / \
>               /   /   \
>      USRK[1..n] DSRK1  DSRK2  ...           (derived as needed)
>                    /      \
>             DSUSRK[1..m1]  DSUSRK[1..m2]

  So this makes the hierarchy

                 EMSK
                   |
               HOKEY-KEY

> There are 2 levels in the key hierarchy.  The two reasons above explain
> the two levels.

  Well you want to derive usage specific keys. That is the reason for
this key hierarchy. And the need for these usage specific keys is....
Well one of them is for handoffs. There is no justification for a
multiplicity of them though. So we have a need for one "usage specific"
key derived from the EMSK. Let's call that the HOKEY-KEY and get rid of
a whole layer of this key hierarchy. Then this DSUSRK stuff is next.

> With the above hierarchy, the USRKs are never sent out.  If there is
> dispute in billing when the rMSK is derived solely from the USRK (rRK),
> then the operator would know that the error is not due to any
> EAP-related protocols or proxies for that matter.  Likewise, if there
> are repeated billing issues associated with VisitedOperator1 and there
> is end-to-end security in delivering DSRKs, then the operator can infer
> that there are issues associated with VisitedOperator1.  Now of course,
> when proxies are involved it is not so clear.  There are strategies to
> get around that too.  For instance, the operator may program the
> smartcard in the peer to maintain usage statistics and can fetch them
> when there are such issues.  In that case again, the operator may be
> able to make inferences about where the problem is.

  But this rRK business is from a different key hierarchy defined in a
different document, right? It's _below_ the whole EMSK-USRK-DSRK-DSUSRK
tree you drew above, right? So I don't really see how that justifies
all the cruft above it.

  regards,

  Dan.




_______________________________________________
HOKEY mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hokey