[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Do you mean DTLS-SRTP or something else? In the former case, I'm not
sure how it works with AAA proxies.
Yoshihiro Ohba
On Sat, Jan 05, 2008 at 06:33:12PM -0800, Lakshminath Dondeti wrote:
> Isn't there a solution on the table already with DTLS proposal?
>
> Lakshminath
>
> On 1/5/2008 3:31 PM, Yoshihiro Ohba wrote:
>> 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/>