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

[Yoshihiro Ohba <yohba@tari.toshiba.com>]

I can see two conflicting types of trust for hop-by-hop security to
work.

Type 1 trust: Trusted entities can use any keys that they have access
to, regardless of how they are distributed.

Type 2 trust: Trusted entities will not use keys distributed to others
even if they have access to the keys.

In Type 1 trust, multiple trusted entities are actually sharing keys
for use, and thus key hierarchy is not needed.  

In Type 2 trust, key hierarchy is still needed.  Also, there is no
Type 2 trust in end-to-end security.  To me, Type 2 trust is similar
to a real-world case where we need to trust how a check-in baggage
will be inspected and treated once it is checked in.  Inspectors have
the right to access to the baggage contents for the purpose of airline
security, but airline customers (need to) trust them that they will
not use the contents.

The issue seems to be which trust model (or something else) is
acceptable for us.  In my personal opinion, Type 2 trust is not
desirable from security perspective, unless AAA proxies really need to
access to the keys to improve AAA secuirty.

Yoshihiro Ohba




On Fri, Jan 04, 2008 at 11:37:43AM -0800, Dan Harkins wrote:
> 
>   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.
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> HOKEY@ietf.org
> https://www1.ietf.org/mailman/listinfo/hokey
> 
> 
> 

--
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/>