[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Why just not use inter-realm Kerberos to establish an end-to-end SA
between EAP server and DSR-KH, and then do DSRK distribution over the
established SA? Inter-realm Kerberos works with chain of trust and
should work with the case where AAA proxies are between EAP server and
DSR-KH. The past proposal about Kerberos over RADIUS indicated by
Bernard sounds like a good solution.
Yoshihiro Ohba
On Sat, Jan 05, 2008 at 11:22:41AM -0800, Lakshminath Dondeti wrote:
> The key however is that there was no real mechanism for end-to-end security
> that 4568 might recommend and now RAI is in another iteration for key
> management for SRTP.
>
> Lakshminath
>
> On 1/5/2008 11:13 AM, Yoshihiro Ohba wrote:
>> 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/>