[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Lakshminath,
Thank you for the pointer to RFC 4568.
In my reading of RFC 4568, it recommends end-to-end security when the
communication path of the SDP message is routed through intermediate
systems like SIP proxies. IMO, end-to-end security (with Type 1
trust) should be the default model for any key distribution mechanism
even if hop-by-hop security is not totally prohibited for some use
cases.
Yoshihiro Ohba
On Fri, Jan 04, 2008 at 04:58:42PM -0800, Lakshminath Dondeti wrote:
> Hi Yoshi,
>
> You are on the right track by exploring the implications of hop-by-hop
> security. In the case we are talking about, it may result in billing
> inconsistencies. That we have agreed is ok in some cases and perhaps not
> ok in others. This is a reasonable conclusion as illustrated elsewhere:
> In case of SIP proxies, hop-by-hop security implies that proxies may be
> able to compromise end-to-end user data/media confidentiality. In this
> case, end-to-end security may be compromised and we have an assortment of
> techniques at the IETF to deal with the problem. The proxy model is
> allowed however. There are key distribution mechanisms (RFC 4568) which
> work with the proxy model in mind.
>
> best wishes for 2008,
> Lakshminath
>
> On 1/4/2008 4:27 PM, Yoshihiro Ohba wrote:
>> 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/>