Subject: [Sipping] Minutes from SIP Privacy and Path header meeting at 51st IETF

From: "Cullen Jennings" <[email-masked]>
Date: Sat, 18 Aug 2001 15:15:44 -0700

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 [email-masked]
Ben Campbell [email-masked]
Bernie Honeisen [email-masked]
Bill Marshall [email-masked]
Brett Tate [email-masked]
Brian Rosen [email-masked]
Cullen Jennings [email-masked]
Dave Oran [email-masked]
Dean Willis [email-masked]
Diana Rawlins [email-masked]
Eric Burger [email-masked]
Flemming Andreasen [email-masked]
Henrik Gustafsson [email-masked]
Itamar Gilad [email-masked]
James Undery [email-masked]
Jayshree Bharatia [email-masked]
Jo Hornsby [email-masked]
Johan Liseborn [email-masked]
Jon Peterson [email-masked]
Jonathan Rosenberg [email-masked]
Jorgen Bjorkner [email-masked]
Kristian Kiss [email-masked]
Mary Barnes [email-masked]
Neil Deason [email-masked]
Pezza Pessl [email-masked]
Radhika R Roy [email-masked]
Robert Fairlie-Cuninchame [email-masked]
Robert Sparks [email-masked]
Rohan Mayh [email-masked]
Sasha Kuditsky [email-masked]
Souhwan Jung [email-masked]
Sunil Chotai [email-masked]

_______________________________________________
Sipping mailing list  http://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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 28 Aug 2001 11:56:50 +0300 (EEST)

> are the proxy it was destined for, then pop it off.

i was not able to attend, but i also favor the option of adding a "loose"
attribute to a route element.  defining another (path) header, which is
very similar to already existing route header can thus be avoided.

-- juha