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

[Lakshminath Dondeti <[e-mail]>]

On 1/11/2008 10:06 AM, Dan Harkins wrote:
>   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.

I will respond to the rest later Dan, but this caught my attention and I 
thought I should clarify quickly:

         EMSK
        /    \
   HOKEY-KEY  DSRK
              /
            HOKEY-KEY

So, we are only debating 1-level vs. and optional 2-level key hierarchy.

regards,
Lakshminath

> 
>   regards,
> 
>   Dan.
> 
> 
> 
> 

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