Subject: Re: [Sipping] SBC and Identity Mechanisms

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Mar 2005 04:50:15 -0500

an older message, but I wanted to add something here:

David R Oran wrote:

> 
> On Feb 16, 2005, at 2:04 PM, Medhavi Bhatia wrote:
> 
>> I am thinking this is not just a privacy problem. The goal of privacy 
>> (both
>> RFC 3893 and draft-ietf-sip-identity-03) is that a caller or callee can
>> verify identity w/o relying on any intermediate party at the level of 
>> each
>> message exchanged between them. Intermediate entities could verify the
>> identity in both cases, but would need to be on this authorized list in
>> order to send messages on behalf of each party. In order for the 
>> mechanism
>> to be general, the authorized entities could be allowed to act in ways 
>> more
>> than just send a BYE. Maybe a Re-INVITE or a REFER etc (this could be an
>> application server ?). The question soon becomes, is the intermediate 
>> entity
>> allowed to modify the SDP or stream the media through a different device
>> (media server or SBC). Also, the caller or callee may only be able to put
>> certain entities in this authorized list, making the job of whoever is
>> providing such a service. Any flexibility could open ways for
>> man-in-the-middle attack (?).
>>
>> Does anyone feel strongly against this ?
>>
> What is "this"?
> That we support secure delegation to intermediaries? Sure, but it's hard.
> 
> I'll note that once you have secure delegation, it is far from clear 
> that there is any longer a need for intermediaries to modify things as 
> they fly by. They can make independent assertions via separate messages 
> (perhaps including the original message via SIPfrag or other means). 

I want to strongly concur with Dave here. This is a general principle we 
are seeing in several other places. Session policy is a great example of 
this. Instead of the network rewriting the SDP as it flies by, the 
servers in the network are composed from several distinct logical roles 
- a proxy server that does what proxies do, and an event server that 
informs clients what they should be putting in their SDP in the first place.

Another example is the app interaction framework. A server in the 
network can be constructed by combining a proxy (which receives and 
forwards the INVITE) with a UA (which sends a REFER to the endpoitns in 
the call, directing them to fetch some web content). The endpoints see a 
totally separate proxy and UA, even though they are internally connected 
within the network server.

This kind of tactic has many benefits:

1. it turns an n-way trust relationship into a series of 2-way trust 
relationships. Instead of worrying about whether that re-invite was 
modified by something in the middle, and figuring out whether it was 
allowed to do so, the thing in the middle acts as a pure UA and directly 
talks to the endpoint. That allows us to use our various security 
techniques for identifying and authorizing user agents.

2. it provides transparency. Instead of the endpoints not knowing what 
is going on inside the network, they are explicitly told. This is 
essential for diagnostics and troubleshooting. See RFC3238 (IAB 
considerations on OPES) for a related discussion.

3. it provides consent. If endpoints don't like what the network is 
going to do, they can give up their call attempt, go find another 
provider, or whatever.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP