Notes by Cullen Jennings (fluffy@cisco.com)
The following stuff gives the flow of the meeting and is pretty much in the order it happened. I tried to include all the main comments from the meeting. Please let me know stuff I missed or just got it wrong and I will be happy to amend, update, or clarify these notes. Thanks, Cullen
----------------------------------------------
There has been limited work and discussion on the Remote-Party-ID stuff.
UA and network proxies should be able to add one or more RPID headers.
General consensus was that you need a B2BUA to enable anonymous media.
Authentication mechanisms should do generic header authentication. Will refer this work as a requirement to the folks working on security issues.
What is the basic function of this stuff? It is a way to make anonymous calls and a way for an appropriate authority to recover your identity even if it was an anonymous call.
Need to be able to make remote party id anonymous. Need to be able to pierce this in some circumstances. Agree that you pretty much have to trust the device that did the anonymization.
Decided we should spit the current draft into two drafts - one draft that covers brief requirements and the specifications and another draft that talks about how to use it. There was some discussion of the first draft in SIP and seconds in SIPPING. Dean pointed out it was a charter item for SIP. Brian somehow gave me the strong feeling that he would manage to have them both done in SIPPING. Everyone seemed fine with that.
Need to pull security out. In an earlier conference call Mike Thomas poked holes in all the proposals to sign headers. People realize this is relatively difficult problem and agreed that it should be systematically handled for all headers by the security folks. The issue is the need to stop cut and paste attacks, so the signature needs to include things like CSEQ and Call ID. Time would be great but then you need to synchronize time between devices, which is a hard.
A fourth requirement was added at this point: need to be able to independently remove a single RPID header without affecting other RPID headers.
We went into how delegation of trust worked. Dean got everyone to believe that trust algebras were a rat hole and implementation issue. Much of it is a local policy decision. It's the usual issue of how to follow a trust chain all the way back.
Dean provided a usage example: Dean calls an anonymizer and authenticates as Dean to it. The anonymizer strips the Dean identity and on Dean's behalf sets the identity to be Cowboy and signs it. It then sends to the end party. The end party can be assured, if they trust the anonymizer, that every time they talk to Cowboy they are talking to the same person. The anonymizer anonymized the call but it also presented a different identity. This is a good thing.
Robert walked thought an example to check out how it would work. A user, A, makes a call through his company proxy, C, that then goes to some service S. A might add his own RPID. Then C might add another that says "I have no idea who this is but I guarantee that it is an employee of C" and sign it. S decides it trusts C so signs C's assertion. We quickly realized it was the usual thing and not too difficult.
Jon pointed out that we wanted a requirement that S may trust C just because there is a TLS connection between the two. There was agreement that we were not specifying how S trusted C; just the fact that it did, through whatever mechanism including something like TLS, would be adequate.
How to authenticate a header will be handed off to security group.
Started looking into Proxy Require issues.
Draft states if you get a proxy-require anonymize you can do one of two things. Can just punt and ask the proxy down the stream to do it, or you can actually do it. This introduces a fail safe vs. fail dangerous issue. Dean pointed out a case where a provider had two types of proxies, ones in the middle (soft and chewy) and ones on the trust boundary edges (hard and crunchy). I assume he was referring to a polar bear's view of an igloo. If the proxies are configured such that only the hard crunchy ones do anonymization and the soft gooey ones don't, things are OK. Now some operator makes one little slip up and a soft gooey proxy starts sending directly out of the trust boundary. Potentially the provider has just leaked out information that not only violated legal requirements but may also be unethical. I imagine he is thinking of issues like patients finding out doctors' home numbers or the numbers of women's shelters becoming public.
Some discussion on the inside proxies needed to authenticate the person anyways, so since they have done this already it may be a net saving of work if they do the privacy stuff. The issue was raised that it is very expensive to do a PKI signing of anything and we should try not to do it if it is not required. It would not be required if the call was not going out of the trust domain.
Flemming piped up and pointed out that key distribution is hard, and the difficulty of that problem may define where you want to distribute keys too and thus where you want to do the privacy stuff.
Dave made the strong argument that he does not want to do an expensive signing operation unless he absolutely has too.
We then moved on a little bit to the view that you should not make routing decisions based on the remote party ID. Jon raised the example of PSAP routing. Someone raised the example of QoS authorized routing. David mentioned you could use cookies for service authorization.
In remote party ID, here are 3 cases: No RPID RPID signed RPID signed and encrypted for privacy
Just because one proxy authenticated someone, other proxies can sign it.
If misconfiguration of all proxies never happens, then it makes sense to do the crypto stuff when passing out of the trust boundary. It is never possible to refute the argument that things might be misconfigured. Two big reservations about having the first proxy to see the request do the privacy: 1) extra work factor; and 2) most feasible solutions to this will require proxy fate sharing of proxy security since they will have the same key.
Had a proposal of if (proxy require privacy is there) and (privacy is required in this request) and (proxy is inserting a RPID header) and (proxy is signing this header) then it needs to protect the message and encrypt the appropriate information.
We came to the idea that it should be a requirement that the above method happens somewhere before crossing the trust boundary. People seemed to agree on this. Dean wanted to do it at the first possible proxy. Dave waned to do it at the last possible proxy. And Flemming's comment still stood that the key distribution scheme might have more impact on where to do it than anything else.
Bill observed that no matter where you did it, the way that "trace call" was implemented may still require you to distribute keys to all the proxies.
At this point we moved on to a completely different topic.
------------------------------------------------------ HOW TO GET OUTBOUND SERVICES FROM A NON ADJACENT PROXY
Dean got things started with an example that looked like:
Dean's home phone, D, makes a call that goes to the proxy, F, in his house (Do you think Dean has dreams of a proxy in every house or nightmares of how to work with a firewall in every house :-)) and from there it goes to main routing proxy, P, at his work which wishes to send it the service proxy, S, at his work, which will then possibly send it back to P where it will get sent to the destination he is really phoning, which is Cullen's phone C.
Just some context for people reading this: people in the meeting were working hard to present this as a generic SIP problem. The issue or at least a variant of it arrives from the 3GPP folks and how they can have the home proxies invoked when the user makes a call while roaming. So a proposal of: Req 1 - The users needs to be able to affect the routing beyond the next hop. Req 2 - Need a way to dynamically discover the identity of remote proxy and get back to the user.
A slightly peripheral topic that came up was that the phones in 3GPPP (UE in 3GPP terminology) are not trusted by the system.
Currently SIP has no constraints that the routing of a Register and other messages such as Invite be the same. Dave proposed we make this a requirement. Everyone agreed.
We started using the terminology "vector" to be the list of proxies that we needed the messages to get routed through. It got said a few times that this vector needs to be dynamically discovered. Dynamically discovered is pretty vague when you get right down to it. Folks explained specifically what this meant in the 3GPP case.
The problem of an outgoing call is different from an incoming call. The current 3GPP scheme is symmetrical but the people in the room who were more familiar with 3GPP work said this was not a requirement but just an artifact of the way they solved the problem. They do not require it to be symmetrical, but they do require it to hit a few key points.
Decided the following explicit requirement: it should not be required that the same set of proxies be traversed in both directions (i.e. in incoming and outgoing calls).
At this point we went into a more explicit discussion about how the path header works.
Consider a UE that connects to a visitor network proxy P, which goes to a visitor edge proxy I, which goes to a transit network proxy T, which goes to another transit network proxy T, which goes to a home network edge proxy I, which goes to the home service proxy S, which goes to an IP phone UA.
The goal here is to make sure all signaling goes through the visitor network proxy P and I (vampire tap 1) and through the home service proxy S (vampire tap 2). This is important because both vampires need to be able to charge a little for the call. For the call described above, the path would be S I P. (or perhaps PIS - I may have been confused on the order in the path statement, but that is irrelevant at this requirements stage). All the path is trying to do is make sure it goes through at least these hops; if it goes through others in between them, and it will, that is fine.
Dave pointed out that sleazy mobile operators may cut people out. 3GPP is ok with that - they will solve that at an SLA legal level. This led to the next explicit requirement:
Don't need the protocol to certify that the path has not been tampered with. Everyone agreed with this.
There was some discussion of whether we could use route headers to do this without breaking backwards compatibility. It seemed we could not, and the heart of the issue came down to this: when the place on path header is C, and the current proxy is A, A needs to send this somewhere that will get it closer to C, but it can not pop C off the path because it might send it to B, and if so, then B will still need to find C in the path header and send it to C. Basically paths will be popped off when the correct person receives the message, while route headers are popped off by the sender.
This led to the following proposal. We add a path header. It is a list of SIP URLs similar to the route header. The behavior of a proxy on receiving a message with a path header is: 1) check if you are the top element on the list, and if so pop yourself off; 2) look at the top element remaining on this list; and 3) treat this as if you had received this as the URI and route appropriately. Note that path headers will take precedent over route headers.
People seemed reasonably comfortable with this proposal when Dave came up with an alternative mechanism to solve the problem. Extend the route header to have each element in it indicate if normal strict routing was required or if loose routing was permitted. Now the algorithm would be, if the next hop is strict, do like normal, but if the next hop is loose, route and send like the above method but don't pop this off the route list. When you receive a message, you need to check if the top item is loose routed. If so and you are the proxy it was destined for, then pop it off.
---------------------------------------------------------------
Attendees:
Alan Johnston alanjohnston@wcom.com Ben Campbell bcampbell@dynamicsoft.com Bernie Honeisen bernhard.honeisen@nokai.com Bill Marshall wtm@research.att.com Brett Tate brett@broadsoft.com Brian Rosen brian.rosen@marconi.com Cullen Jennings fluffy@cisco.com Dave Oran oran@cisco.com Dean Willis dean.willis@softarmor.com Diana Rawlins diana.rawlins@wcom.com Eric Burger eburger@snowshore.com Flemming Andreasen fandreas@cisco.com Henrik Gustafsson henrik.gustafsson@hotsip.com Itamar Gilad itamarg@radvision.com James Undery jundery@ubiquity.net Jayshree Bharatia jayshree@nortelnetworks.com Jo Hornsby jhornsby@ubiquity.net Johan Liseborn johan@hotsip.com Jon Peterson Jon.Peterson@neustar.com Jonathan Rosenberg jdrosen@dynamicsoft.com Jorgen Bjorkner jorgen.bjorkner@hotsip.com Kristian Kiss Kristian.Kiss@nokia.com Mary Barnes mbarnes@nortelnetworks.com Neil Deason ndeason@ubiquity.net Pezza Pessl Pekka.Pessl@nokai.com Radhika R Roy rrroy@att.com Robert Fairlie-Cuninchame rfairlie@nuera.com Robert Sparks rsparks@dynamicsoft.com Rohan Mayh rohan@cisco.com Sasha Kuditsky sasha@radvision.com Souhwan Jung souhwanj@saint.ssu.ac.kr Sunil Chotai sunil.chotai@bt.com
updated 13 Dec 2001 13:23:08 -0600