Subject: RE: [Sipping] comments on draft-peterson-sipping-retarget

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Mar 2005 14:35:31 -0500

Hi Jon,

Good draft indeed.

On the topic of the establishment of the security parameters (including
the part about 493 with the certificate, and on the unanticipated 
respondent problem/"connected party"...

What if Alice was able to require that the response includes the
respondent's certificate?

So, Alice calls Bob requiring the certificate. Call is retargeted to Carol.
Carol provides her certificate in the 200.

Alice then makes a decision on proceeding with the session or not based
on Carol's certificate. "I called Bob, but Carol responded instead, and
I've got proof, do I continue or not?".

This may require of course another round of re-INVITE with the new 
encrypted body (with sRTP parameters or whatever), but it is not a
redirection.
_______________________________________________
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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Mar 2005 16:49:16 -0500

I was not in this mail, nor in my mail to Jonathan, nor in the sipping-retarget draft making any sort of proposal for a solution to the problems in sipping-retarget. Here, I was simply pointing out the fact that in the absence of retargeting, if a UAC has a direct connection to a redirect server, it can, through TLS, acquire a strong assurance of the origin of a 3xx response. This is the way SIP works today, and when you retarget, you don't have that property in SIP today. There is neither a baby nor bathwater in play, this is just a fact.

As Jonathan's note suggested, one of the root causes of the problems in sipping-retarget is the use of trapezoid routing architectures rather than triangle routing architectures. In triangle routing architectures, these problems simply don't arise. That doesn't mean that the only acceptable solutions involve banning all trapezoid architectures. But it does mean that we need to weigh very carefully the value of these trapezoid proxies against the security needs of the protocol.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, March 04, 2005 12:54 PM
> To: Peterson, Jon
> Cc: Jonathan Rosenberg; sipping
> Subject: Re: [Sipping] comments on draft-peterson-sipping-retarget
> 
> 
> 
> 
> Peterson, Jon wrote:
> > Because the 3xx response comes directly from that 
> intermediary to the UAC. The UAC can form a direct TLS 
> connection, say, to the redirecting host, and use the 
> certificate passed by TLS as the authentication of the sender 
> of the 3xx. The only reason why 3xx responses would not be 
> sent directly from the intermediary to the UAC in this 
> fashion is, of course, because of trapezoid-ish retargeting 
> architectures. 
> 
> So you are excluding even the explicit introduction of intermediaries by 
> the UAC - forcing the UAC to go direct to the proxy authoritative for 
> the target. That seems to be throwing out the baby with the 
> bath water.
> 
> Proxies that don't retarget - that are visited because of Route headers 
> - are quite valuable. It isn't going to be very appealing if every phone 
> that wants to make a call has to extablish a new TLS connection.
> 
> 	Paul
> 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[email-masked]]
> >>Sent: Friday, March 04, 2005 11:53 AM
> >>To: Peterson, Jon
> >>Cc: Jonathan Rosenberg; sipping
> >>Subject: Re: [Sipping] comments on draft-peterson-sipping-retarget
> >>
> >>
> >>
> >>
> >>Peterson, Jon wrote:
> >>
> >>
> >>>>The introduction also talks about the primary problem being 
> >>>
> >>that you 
> >>
> >>>>can't trust the intermediaries to properly retarget. 
> >>>
> >>However, if you 
> >>
> >>>>can't trust the proxies, you can't trust them to redirect 
> >>>
> >>instead of 
> >>
> >>>>retarget...
> >>>
> >>>The differences are enormous, actually, in so far as you 
> >>
> >>can actually see -which- intermediary redirects, but you 
> >>cannot determine which intermediary retargets. Because you 
> >>can see which intermediary it is, you can determine whether 
> >>or not they are actually authorized to change the target of 
> >>the request. I don't think you can be said to trust an entity 
> >>taking an action during routing the call if you don't even 
> >>know who that entity is...
> >>
> >>How is it that the UAC can *see* which intermediary redirected?
> >>
> >>	Paul
> >>
> > 
> > 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 4 Mar 2005 19:18:50 -0500

The approach you describe below is a lot like what sip-identity used to look like when it used AIBs. When Alice's request is retargeted from Bob to Carol, Carol could include an AIB proving that she, Carol, was the recipient of the call. In your approach below, though, I guess Carol includes a certificate alone, rather than an AIB, to identify herself, and the two parties use that certificate in a new INVITE or something (just as they would if a 493 were sent).
 
There are a couple of points to make about this approach:
 
- It probably has problems with self-signed certificates. Edgar the adversary could just make a self-signed certificate that says "This is Carol!". In other words, the assurance that a certificate provides in this context isn't very valuable unless the verifier has some independent reason to trust the cert. This is material because it requires us to solve the end-user PKI problem, which is widely believed to be intractable. It is hard (like, impossible) to get certificates today from certificate authorities with a subject or subjectAltName containing a SIP AoR. Avoiding any significant reliance on end-user PKI has been a primary focus of sip-identity and sipping-certs from the start.
 
- Even if Carol's cert were signed by a recognized CA, Edgar the adversay might get his hands on the cert (it is public, after all) and distribute it himself in a response. A cert alone provides no "proof", really; only a signature over some segment of the message (i.e. an AIB) shows that the respondent actually holds the private key material corresponding to the cert. Of course, one could argue that this doesn't matter because the cert needs to be used to encrypt the SDP in a re-INVITE, but this overlooks the possibility that Edgar would be sending an equally-damaging 3xx or 6xx response instead of a 2xx response. In these identity cases, the failure responses worry me a lot more than the success responses. Using an AIB instead of just sending the cert would resolve this.
 
- The distinction between suffering another RTT for re-INVITEs and suffering another RTT for redirections doesn't seem large to me.
 
Aside from the annoying issue of Alice's requests being undecipherable by Carol, the real problem that sipping-retarget section 2.3 begs is whether or not, from Alice's perspective, Bob and Carol are equivalent. If Alice sends a request to Bob and gets a 493 bearing a certificate, is it Bob's certificate or not? If it's not Bob's certificate, how does Alice know the 493 is not coming from an attacker trying to get a decrypted version of her request? How long should Alice use Carol's certificate when she tries to send requests to Bob before reverting back to Bob's "real" certificate?
 
Jon Peterson
NeuStar, Inc,

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Friday, March 04, 2005 11:36 AM
To: Peterson, Jon; 'sipping'
Subject: RE: [Sipping] comments on draft-peterson-sipping-retarget

Hi Jon, 

Good draft indeed.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Mar 2005 20:59:26 -0500

Hi Jon,
 
Yes, you are right: I was assuming that there would also be a signature (AIB
or whatever).
 
The distinction between the re-INVITE (which is indeed what I had in mind)
and the 493 is that it is the same session. I was under the impression that
another INVITE as a separate session (as a result of 493) could also be
retargeted, which could lead into an infinite loop of retargeting. I'm
thinking of a scenario where the URI corresponds to a group of people for
example.
 
And yes, indeed the real question is if Alice is willing to consider that
Bob and Carol are equivalent. To me, it depends on the application. If Alice
really wants to talk to Bob, then probably not. If Alice knows that Carol is
Bob's secretary and can answer for him, maybe. If Alice just wants ALL of
our conversations to be encrypted, then probably.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Friday, March 04, 2005 16:19
To: Audet, Francois [SC100:9T51:EXCH]; sipping
Subject: RE: [Sipping] comments on draft-peterson-sipping-retarget

The approach you describe below is a lot like what sip-identity used to look
like when it used AIBs. When Alice's request is retargeted from Bob to
Carol, Carol could include an AIB proving that she, Carol, was the recipient
of the call. In your approach below, though, I guess Carol includes a
certificate alone, rather than an AIB, to identify herself, and the two
parties use that certificate in a new INVITE or something (just as they
would if a 493 were sent).

- It probably has problems with self-signed certificates. Edgar the
adversary could just make a self-signed certificate that says "This is
Carol!". In other words, the assurance that a certificate provides in this
context isn't very valuable unless the verifier has some independent reason
to trust the cert. This is material because it requires us to solve the
end-user PKI problem, which is widely believed to be intractable. It is hard
(like, impossible) to get certificates today from certificate authorities
with a subject or subjectAltName containing a SIP AoR. Avoiding any
significant reliance on end-user PKI has been a primary focus of
sip-identity and sipping-certs from the start.
 
- Even if Carol's cert were signed by a recognized CA, Edgar the adversay
might get his hands on the cert (it is public, after all) and distribute it
himself in a response. A cert alone provides no "proof", really; only a
signature over some segment of the message (i.e. an AIB) shows that the
respondent actually holds the private key material corresponding to the
cert. Of course, one could argue that this doesn't matter because the cert
needs to be used to encrypt the SDP in a re-INVITE, but this overlooks the
possibility that Edgar would be sending an equally-damaging 3xx or 6xx
response instead of a 2xx response. In these identity cases, the failure
responses worry me a lot more than the success responses. Using an AIB
instead of just sending the cert would resolve this.
 
- The distinction between suffering another RTT for re-INVITEs and suffering
another RTT for redirections doesn't seem large to me.
 
Aside from the annoying issue of Alice's requests being undecipherable by
Carol, the real problem that sipping-retarget section 2.3 begs is whether or
not, from Alice's perspective, Bob and Carol are equivalent. If Alice sends
a request to Bob and gets a 493 bearing a certificate, is it Bob's
certificate or not? If it's not Bob's certificate, how does Alice know the
493 is not coming from an attacker trying to get a decrypted version of her
request? How long should Alice use Carol's certificate when she tries to
send requests to Bob before reverting back to Bob's "real" certificate?
 
Jon Peterson
NeuStar, Inc,

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Friday, March 04, 2005 11:36 AM
To: Peterson, Jon; 'sipping'
Subject: RE: [Sipping] comments on draft-peterson-sipping-retarget

Hi Jon, 

Good draft indeed.