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

["Dan Harkins" <dharkins@lounge.org>]

  Hi Lakshminath,

On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
[snip]
> Hi Dan,
>
> I am trying to understand the direction of the discussion here:
>
> When there is end-to-end security, it appears that we have agreement
> that a key hierarchy is necessary.

  No, that's not what I'm saying.

> When there is hop-by-hop security, you are making the argument that the
> DSRK hierarchy is not necessary and that we can use other techniques to
> make things work.  Isn't it simpler to have the same key hierarchy
> irrespective of the protection policies in the AAA network?  Besides,
> the different DSRKs would allow the peer to help the home network verify
> the accounting information, for instance.

  We have to deal with the system holistically and not dissect it into
parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
to one part or the other. The issue is what is the threat model for the
holistic system?

  If proxies are permitted, and they are, then the problems they introduce
have to be accepted. We have consensus to do that. It is my contention
that the key hierarchy attempts to address those problems that we have
already accepted into our system due to proxies so I feel the key
hierarchy is an unnecessary complexity.

  Of course I may be all wrong. If someone could just tell me exactly
what problem will completely go away by having this key hierarchy I would
greatly appreciate it. Can you tell me?

> We talked about the reasoning for the DSRK hierarchy for a long time and
> achieved consensus.  I understand that you are bringing up these
> questions again with the hop-by-hop security model in mind.

  The goalposts have moved. The discussion about the key hierarchy was
held back when we were still arguing over a 3 party protocol. That was
when disclosure of keys to people who are not the intended recipient
was a problem we were going to address. But I have come to the realization
that the working group is not interested in a protocol that could not work
in the presence of proxies and that the working group now feels that that
problem is not something that needs addressing.

  I believe that the problems that proxies introduce are the same ones that
arise when a key is shared between domains. The key hierarchy addresses the
latter but not the former. Since WG consensus is that the former is not
something that needs addressing I question why the latter needs addressing.

  A counter example would go a long way to justifying the key hierarchy.
Do you have one?

>                                                              Personally,
> I find it instructive to think about the implications of putting trust
> in proxies.  We discussed that in Vancouver and noted that billing
> inconsistencies may be the result.  If an operator is willing to handle
> those through non-protocol means (and that's what many do today), we
> should continue to allow that model of operation.

  I'm not saying we shouldn't allow that model of operation. In fact,
I am acknowledging that the WG has consensus to allow it.

  What I am saying is that by allowing that model of operation we are
agreeing to not address the problems it introduces. And that being the
case the key hierarchy becomes extraneous, an unnecessary complexity
that we should just do away with.

> best wishes for the new year,
> Lakshminath

  Thank you very much! I hope you have a great 2008.

  Dan.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>