Subject: RE: [Sip] The Problem with PRACK

From: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Mar 2006 17:17:29 -0600

Thanks Mike, I'm not trying to force a single-switch mentality, I'm just using features that generally require a trusted third party to route the call when the terminator is not around (like voicemail).

The fact is that it is allowed by SIP (and I don't think you're required to be a BBUA to retarget requests last I checked). So does that mean that in order to solve this problem we must depricate certain provisions in SIP?

The example you give requires the terminator's call logic (ie. how long and to whom the call should be redirected) is running on the originator's client. It should not be up to the person making the call to determine how the person they are calling wishes to have their calls routed (or even know that their calls are being routed in a particular manner). Not only that, but the recursion that is possible with a redirect scenario like this seems to me to be ill-suited to a contact header. A closer match would be a reverse history-info header (call it the back-to-the-future-history-info header) that captures the tree-like nature of the routing behavior prior to the routing occurring.

I believe Dean mentioned sending CPL back (which seems more appropriate than a back-to-the-future-history-info header). Obviously, nobody wants their screening rules sent back that says "hey, it's you calling so just route straight to voicemail because you're a pest" getting sent back to the originator. Something needs to dynamically create the CPL or there needs to be a way of obsfucating the request. That seems pretty complex just to support retargeting a request.

Finally, I there are many cases (especially in call center applications) where you don't want the originator to know how to route the request to the person that the call is being terminated to. This doesn't mean you don't want them to know with whom they are speaking, just not how to craft a request URI to get to them. I don't see how this is easily possible with a redirection model unless we start handing out temporary URLs to obsfucate where the request is going to get sent to.

It seems like Dean's saying that the originator needs to know that there's something in the middle mucking about with the routing of the call because there's no way of differentiating between a network server routing for the terminator and a MITM attack that's messing about with the routing of the call. Are we considering secure transport to the middle (SIP over TLS for example) to be enough to solve this scenario or is more needed?

Regards,
Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]]
Sent: Wednesday, March 15, 2006 2:13 PM
To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings
(fluffy)
Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat
(pkyzivat)
Subject: RE: [Sip] The Problem with PRACK

The 302 can have multiple contacts.  
The originator sends INVITE to the first contact, 
and upon no answer sends to the second AoR.

The thought is that the correct end result from user experience can
occur, 
maybe just no in the exact way, with exact node sequence as before, 
with features in exactly the same place.

I am just trying to escape a single switch mentality.
Need to re-think all the features then.

Mike

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Wednesday, March 15, 2006 12:38 PM
> To: Michael Hammer (mhammer); Dean Willis; Cullen Jennings (fluffy)
> Cc: [email-masked]; Francois Audet; Paul Kyzivat (pkyzivat)
> Subject: RE: [Sip] The Problem with PRACK
> 
> I don't know that I follow you suggestion in the specific 
> case I am talking about.
> 
> Take for instance Call Forward No Answer. In this case, A 
> never says that it's done with the call before it is 
> retargeted to B by the network. A and B have no idea that the 
> service even exists in the middle.
> 
> Regards,
> Brian
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2006 8:42 AM
> To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings
> (fluffy)
> Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat
> (pkyzivat)
> Subject: RE: [Sip] The Problem with PRACK
> 
> 
>  
> 
> > -----Original Message-----
> > From: Brian Stucker [mailto:[email-masked]]
> > Sent: Tuesday, March 14, 2006 11:55 AM
> > To: Dean Willis; Cullen Jennings (fluffy)
> > Cc: [email-masked]; Francois Audet; Paul Kyzivat (pkyzivat)
> > Subject: RE: [Sip] The Problem with PRACK
> > 
> > Based on your proposals below, cryptographically transparent versus 
> > redirection:
> > 
> > How would you go about addressing applications like CPL 
> that need to 
> > run timers for service logic and thus need to have some level of 
> > control over the session (not necessarily what's in the body of the 
> > messages, just where they're going) if a redirection model is used?
> > 
> > For example, without mucking about with what's inside the request, 
> > triggering off of the request URI of an INVITE to forward to 
> > destination A for X seconds and then to destination B. In 
> this example 
> > the next hop changes over time for the same request and 
> does not seem 
> > possible using redirection. This seems to preclude redirection as a 
> > general solution and drive towards requiring a proxy to be 
> > cryptographically transparent.
> 
> Is there a reason the redirect server couldn't send you to A, 
> which then redirects or Refers you to B when A is done with 
> it's part of the service?
> 
> It seems the proxy is best at directing traffic, while the 
> UAS could contain distributed feature logic.  Think of an 
> assembly line of robots, each which knows its part of the 
> process, but not necessarily the whole.
> 
> Mike
> 
> > 
> > If the proxy is transparent, then how do you go about not 
> precluding 
> > deep-packet inspection issues raised by applications such as QoS 
> > enforcement, network enforced identity or other services? 
> It seems to 
> > me that HTTPS may make a bad model in that I'm unaware of any 
> > HTTPS-based application that has a box in the middle that needs to 
> > inspect and enforce certain characteristics of the request 
> before it 
> > is handled by the final consumer of that request.
> > 
> > This seems to preclude cryptographic transparency as a general 
> > solution.
> > 
> > I'm sure either can be used effectively in many application spaces, 
> > but it does not seem that either can be used as a general 
> solution in 
> > the protocol itself.
> > 
> > Regards,
> > Brian
> > 
> > -----Original Message-----
> > From: Dean Willis [mailto:[email-masked]]
> > Sent: Tuesday, March 14, 2006 1:08 AM
> > To: Cullen Jennings
> > Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat
> > Subject: Re: [Sip] The Problem with PRACK
> > 
> > 
> > 
> > On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote:
> > 
> > > On 3/13/06 10:27 AM, "Dean Willis" 
> > <[email-masked]> wrote:
> > >
> > >> Right. But, SIPS is only required as far as the proxy 
> serving the 
> > >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even
> > just plain
> > >> unsecured UDP.
> > >
> > > I think we have a gathering amount of evidence that we want
> > to update
> > > this regardless of UDP or PRACK.
> > 
> > 
> > It's true that SIP proxies just don't work "right" with 
> SIPS as it is.
> > 
> > When people first look at the "SIPS is only valid to the serving 
> > proxy" model they assume that simply changing the 
> requirement to say 
> > that the proxy-to-UA leg must also be SIPS protected would 
> provide a 
> > satisfactory answer. It doesn't, and this requires some careful 
> > thinking.
> > 
> > What security do you mandate on the serving-proxy to UA link? TLS?  
> > TLS supports many different ciphersuites. What keeps the 
> crypto on the 
> > SP-UA link from being watered-down? Would other protections 
> like IPSEC 
> > suffice? How would you end-to-end negotiate the 
> cryptography so that 
> > the originating UA could believe that the entire chain was 
> protected 
> > to some minimal level? And how do you offer some level of 
> security to 
> > an IMS fashion-victim who is always going to be exposed to MITM 
> > attacks from his own service provider by design?
> > 
> > Personally, I think the only way SIPS really gives us the level of 
> > protection we have come to expect from HTTPS is if it is 
> used end-to- 
> > end, either by abandoning proxy-routing in favor of a 
> redirect model, 
> > or by causing the proxies to be cryptographically transparent as is 
> > done with HTTPS proxies.
> > 
> > This is an important thing to note: HTTPS proxies do NOT 
> "see inside"
> > the HTTPS stream. All they do is pass it along, unchanged, 
> to the next 
> > hop. It could actually be some other protocol than HTTP, and they 
> > don't care and can't tell. To-date, we haven't treated SIPS proxies 
> > that way, and instead presume they have access to the full 
> stream, in 
> > many cases "write access" so that they can munge various 
> header fields 
> > about.
> > 
> > --
> > Dean
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip 
> > Use [email-masked] for new developments on the application of sip
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip 
> > Use [email-masked] for new developments on the application of sip
> > 
> 

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

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 17:44:23 -0600

On Mar 15, 2006, at 5:17 PM, Brian Stucker wrote:

> The fact is that it is allowed by SIP (and I don't think you're  
> required to be a BBUA to retarget requests last I checked). So does  
> that mean that in order to solve this problem we must depricate  
> certain provisions in SIP?
>

Just because you CAN do something with SIP doesn't mean it;s a good  
idea to do it that way.

> The example you give requires the terminator's call logic (ie. how  
> long and to whom the call should be redirected) is running on the  
> originator's client. It should not be up to the person making the  
> call to determine how the person they are calling wishes to have  
> their calls routed (or even know that their calls are being routed  
> in a particular manner). Not only that, but the recursion that is  
> possible with a redirect scenario like this seems to me to be ill- 
> suited to a contact header. A closer match would be a reverse  
> history-info header (call it the back-to-the-future-history-info  
> header) that captures the tree-like nature of the routing behavior  
> prior to the routing occurring.
>
> I believe Dean mentioned sending CPL back (which seems more  
> appropriate than a back-to-the-future-history-info header).  
> Obviously, nobody wants their screening rules sent back that says  
> "hey, it's you calling so just route straight to voicemail because  
> you're a pest" getting sent back to the originator. Something needs  
> to dynamically create the CPL or there needs to be a way of  
> obsfucating the request. That seems pretty complex just to support  
> retargeting a request.

You might apply a first round of "CPL" in generating the redirecting  
response, disclosing only the part pertinent to the set of contacts  
that the specific caller might reach.

>
> Finally, I there are many cases (especially in call center  
> applications) where you don't want the originator to know how to  
> route the request to the person that the call is being terminated  
> to. This doesn't mean you don't want them to know with whom they  
> are speaking, just not how to craft a request URI to get to them. I  
> don't see how this is easily possible with a redirection model  
> unless we start handing out temporary URLs to obsfucate where the  
> request is going to get sent to.
>

Here you can redirect to a GRUU. If you REALLY need target anonymity,  
then the Contact coming back in a 200 OK would break your model  
anyhow, and you either need to use GRUU or use a B2BUA service.

> It seems like Dean's saying that the originator needs to know that  
> there's something in the middle mucking about with the routing of  
> the call because there's no way of differentiating between a  
> network server routing for the terminator and a MITM attack that's  
> messing about with the routing of the call. Are we considering  
> secure transport to the middle (SIP over TLS for example) to be  
> enough to solve this scenario or is more needed?

I don't consider "hopefully secure transitive TLS" to be all that  
satisfying. If something is changing the target of my call, I want to  
know WHO that something is and have a reason for TRUSTING it to make  
that change.

In the world of browsing, it not infrequently happens that a user  
enters a URL for shopping site A, only to have their request answered  
by shopping site B. That's usually because somebody put some malware  
in their browser to hijack their HTTP shopping sessions. We consider  
that an attack. But at least the browsers (if TLS is used) give us a  
hint about where the session connected to. If "something in the  
middle of a SIP network" is hijacking my SIP sessions, I want to know  
about it, and I REALLY want to know that my session got to where I  
wanted it to go and not to a competitor or malefactor who may have  
paid my "service provider" to re-route the request, or just hacked  
them to achieve the same result.

Consider the evolution of the mechanical phone switch -- it was  
supposedly invented because human operators had been subborned to  
divert calls from one mortuary to another competing mortuary, and the  
mortician who was losing business got mad:

http://www.technologyreview.com/InfoTech/wtr_13959,258,p2.html

We should learn from this -- TRUSTING the middlemen to do the right  
thing without VERIFYING that they have done so is likely to lead to  
one needing the services of a mortician, but perhaps getting  
something very different.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 14:58:06 -0600

Vijay directly asked me this question, which I found so compelling I  
decided I needed to share it with all of you. Please forgive me.

On Mar 16, 2006, at 9:12 AM, Vijay K. Gurbani wrote:

> Just so that I can catch up with you -- how do you define the  
> difference
> between retargetting and re-routing?  To me, the former happens at
> the application layer (R-URIs get re-written) while the latter
> happens at the network layer (possibly routers re-routing requests,
> or applications targetting another server from a set of servers
> obtained through DNS SRV).

Retargeting is a change in the intended target of a request. In SIP,  
this manifests as a change in the request URI.

Routing is simply delivery of a request to a destination through an  
intermediary, or delivery of a request to  an intermediary that will  
get it closer to its destination. In SIP, we have the Route header  
field to describe a vector of intermediaries to visit.

In RFC 2543, every proxy operation involved retargeting. We'd pop a  
Route, change the R-URI, and move on. every proxy operation was a  
retargeting.

In RFC 3261, we introduced the concept of "loose routing", allowing a  
message to traverse a route vector without changing its request URI.  
This was a great improvement. However, in RFC 3261, "contact routing"  
is still a retargeting rather than routing -- the service proxy  
responsible for an AOR replaces the request URI with the URI  
registered as the Contact of the intended UA.

> In HTTP, the R-URIs do not get re-written (AFAIK), so the way that an
> attacker can retarget is by opening a connection to the bad site
> and sending the relative URI of the request and the rest of the
> request headers there.  In SIP, the retargetting is more visible;
> i.e., rewrite the R-URI.  Yes?

In HTTP, a proxy can deliver something to a bogus destination, or  
issue a redirect. The client sees a redirect -- no problem. This  
supports response identity, as https allows us to validate the  
credentialed identity of the responding target against the intended  
identity (the request-URI). If they don't match, we know we've been  
bogo-routed. No match, no padlock icon.

While the retargeting operation LOOKS more visible in SIP, it's  
actually completely invisible to the originating UAC. The UAC is  
never informed that the request has been retargeted, so it has no  
fixed expectation of who might answer. The strong connection-checking  
mechanism of https is therefore diluted to a hop-by-hop thing where  
you have to just hope that all the proxies played nice and that the  
request got to someplace reasonable. The set of allowable response  
identities is unbounded, and therefore very hard to validate by the UAC.

Also, the UAS has no good way of knowing where the request was  
supposed to go, and it can't even guess at how it should try and  
identify itself. This is badly broken. Not only does it break  
identity, it also keeps us from being able to send URI parameters to  
the endpoint. This means that for every parameter we might want to  
pass, we have to have a protocol extension to put it into a header  
field! Think what the HTTP specs would look like if every CGI  
parameter you might use in a perl script had to be in an RFC. Insane!

Jonathan proposed changing the contact-routing operation so that  
instead of changing the request URI, the proxy would simply add a  
Route header populated from the contact. When the request arrives at  
the UAS, the request-URI will still be the original request-URI, with  
all its identity statements and parameters intact. Voila, problem fixed.

I believe that "retargeting" must be completely eliminated as a proxy  
operation, and replaced with "redirection". In redirection, the new  
request-URI is sent back to the UAC, which then has the option of  
making a new request to that  URI. This gives the UAC a target  
identity against which to evaluate the response, greatly  
strengthening the security properties.

If we take this a step further and make the proxy operation  
cryptotransparent (like https proxies), then we have even better  
security properties, because we have a nice solid TLS connection all  
the way from UAC to UAS, giving us excellent ability to match the  
request and response identities. By cryptotransparent, we mean that  
the encrypted stream passes through the proxy without being decrypted  
and without being modified by the proxy. It might get ROUTED by the  
proxy, but not modified.

Now, there are occasions when you really want the anonymity of hiding  
behind a proxy. You don't want the correspondent node to know your IP  
address, or that it's been kicked to an alternate target. These are  
relatively rare conditions, but they do occur.

For this to work right, we need a different sort of relay mechanism.  
This is where what I call a B2BUAWM, or "back to back user agent with  
media" becomes applicable. In this model, the originating UAC  
securely establishes a communication with a UAS. The UAS then acts as  
a  UAC and establishes another independent session to the "final"  
UAS, and handles relaying the media from one session to the other.  
With sips engaged, the originating UAC KNOWS that it is talking to  
the target of its request, as it has done the whole TLS validation  
with it. This target, the B2BUAWM, knows that it is talking to the  
right "final UAS", because it too has established a proper TLS  
connection.

In order for this to work, the B2BUAWM has to have the credentials to  
answer for the request-URI. I call it a "cryptoparticipant" node. It  
is credentialed and actively engaged in the cryptographic  
protections, and its presence is known to the other nodes (though  
they may not know it is a relay).

The critical security property here is that requests are ALWAYS  
either answered by a node that has credentials that match the URI of  
that request, or with a redirection that gives them a new URI to try  
instead. If a request is sent be to a different node, we need to  
change the request URI so that this critical security property is  
maintained, and we need to inform the user about this retargeting so  
that the user can provide informed consent. In most cases, no  
retargeting occurs.

Let us consider the classic case of contact routing. Alice calls Bob,  
who has three registered contacts. I'll simplify a few points, but  
believe on examination you;ll see how to make them work.

Classic model:

1) UA-A establishes TLS connection with ProxyB based on identity from  
DNS.
2) UA-A sends INVITE to ProxyB.
3) ProxyB has pre-established TLS connections with UA-B1, UA-B2, UA-B3.
4) ProxyB forks INVITE to UA-B1, UA-B2, UA-B3
5) UA-B3 responds with 200 OK to ProxyB
6) ProxyB sends 200OK to UA-A.
7) UA-A establishes TLS connection to UA-B3 and sends ACK,.

Question: How does UA-A know that UA-B3 is ok a as a correspondent?  
It trusts ProxyB to have allowed 200 OK responses only from  
correspondent nodes separately authenticated by and consequently  
trusted by ProxyB. NOte also that we have a dependency on DNS security.

More likely model, with Record-Routing:
1) UA-A establishes TLS connection with ProxyB based on DNS lookup of  
Bob's identity from R-URI
2) UA-A sends INVITE to ProxyB.
3) ProxyB has re-established TLS connections with UA-B1, UA-B2, UA-B3.
4) ProxyB forks INVITE to UA-B1, UA-B2, UA-B3 and record-routes.
5) UA-B3 responds with 200 OK to ProxyB
6) ProxyB sends 200OK to UA-A.
7) UA-A sends ACK through ProxyB to UA-B3

Note here that UA-A no longer has any cryptographic interaction with   
UA-B3. Everything is mediated by ProxyB, at least until we get to the  
media phase. If B cheats, we won't be able to tell. But ProxyB  
doesn't really have the credentials to be Bob, just to be ProxyB, and  
we learned about ProxyB's existence from DNS. Do we trust ProxyB to  
be responsible for Bob?

Even more likely model, with another proxy in front of A.
1) UA-A establishes TLS connection with ProxyA, based on configuration.
2) UA-A sends INVITE to ProxyA.
3) ProxyA establishes TLS connection with ProxyB, based on DNS lookup  
of Bob's identity from R-URI
4) ProxyA record routes and sends INVITE to ProxyB
5) ProxyB has re-established TLS connections with UA-B1, UA-B2, UA-B3.
6) ProxyB forks INVITE to UA-B1, UA-B2, UA-B3 and record-routes.
7) UA-B3 responds with 200 OK to ProxyB
8) ProxyB sends 200OK to ProxyA
9) ProxyA sends 200OK to UA-A.
10) UA-A sends ACK thru Proxy A and ProxyB to UA-B3

Note here that we're dependent on correct behavior in ProxyA and  
ProxyB. We have all the problems from the previous case, plus. If  
ProxyA makes a simple mistake in selecting ProxyB, we could be  
talking to ANYBODY. We now have a very indirect chain of trust,  
rooted in DNS having Done the Right Thing.

Alternative 1, Purest Form.
1) UA-A establishes TLS connections with UA-B1, UA-B2, UA-B3,  
selected from DNS.
2) UA-A validates that certificates presented by UA-B1, UA-B2, UA-B3  
are valid for Bob.
3) UA-A sends INVITES to UA-B1, UA-B2, UA-B3
4) UA-B3 replies with 200 OK.
5) UA-A sends ACK.

Note that here, we have a strongly supported claim that the connected  
UA is valid for Bob. There is little dependency on correct DNS  
resolution, because if we got back a bogus target, the credentials  
wouldn't match and the attack would be detected.

Alternative 2, Redirection instead of DNS for target UA Resolution
1) UA-A selects ProxyB using DNS lookup of Bob's identity
2) UA-A establishes TLS connections with ProxyB, validating TLS  
against identity matching DNS query and "expected domain"
3) UA-A sends INVITE to ProxyB
4) ProxyB responds with a 302 list containing UA-B1, UA-B2, UA-B3
5) UA-A sends new INVITES to UA-B1, UA-B2, UA-B3, establishing TLS  
and evaluating identities of endpoints
6) UA-B3 responds with a 200 OK.

Note that while we still have a partial dependency on DNS, it's cross- 
validated by a credential that matches the proxy domain we were  
expecting to see, and the we eventually get to a node that has  
credentials for Bob (or Bob's phones). Had Bob's proxy sent us to  
Charlie, we would at least have a trackable record showing that an  
authentic proxy for Bob sent us to Charlie, and that 2) we were  
expecting to connect to Charlie as a result, and 3) We really DID  
connect to Charlie.

Now this does point us at some interesting variations. Suppose a 302  
could return not just a contact list, but a set of contacts and  
routes, that would route us through the correct "outbound" proxies  
for each of Bob's phones? And suppose those proxies were  
cryptotransparent, so that we could use TLS to validate the final  
endpoint identity? Cool, huh?

But what's cooler is we don't need to change 302 at all to make this  
work. Instead of returning a set of contacts and routes, Bob's proxy  
can return a regular Contact list, populated with instance-GRUUs  
(relative to itself) for each of Bob's contacts. The UAS responds by  
opening TLS connections through Bob's cryptotransaprent proxy, which  
applies SIP routing (not retargeting) rules to get the TLS connection  
pushed through to Bob's UAs. We now have most of the use case of  
forking, done completely securely, with all the benefits of sip- 
outbound including last-hop-proxy facilitated keepalives and  
connection reuse.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 16 Mar 2006 16:34:30 -0600

> decided I needed to share it with all of you. Please forgive me.

OK, if you insist.  Of course, question inline.

[...]

> (relative to itself) for each of Bob's contacts. The UAS responds by  
                                                        ^^^
I think you meant "UAC" +------------------------------|

> outbound including last-hop-proxy facilitated keepalives and  connection 
> reuse.

I was with you all the way until here.  So ... Bob's proxy returns
a Contact list, populated with instance GRUUs relative to itself.
We'll come back here.

As I understand it, in HTTP cryptotransparency across proxies
is obtained by upgrading a normal TCP connection from browser to
origin server through proxies to use TLS once a tunnel is set
up (rfc2817).  After the the tunnel is established, an upgrade
is requested and certs are exchanged directly between the browser
and the origin server.

Now, how does this map into our SIP case?  When Alice's UA got
a Contact list, it already had a TLS connection established
with Bob's proxy.  Over this TLS connection, it sends multiple
requests to simulate endpoint forking (let's assume you like
endpoint forking as opposed to proxy forking, which I know for
a fact that you dont' :-)). Bob's proxy now applies SIP routing
to get to Bob's UA.  Are you saying somehow that Bob's proxy will send
Alice's cert to Bob's UA and Bob's cert to Alice's UA and
have Bob and Alice do the TLS handshake to negotiate session
keys such that the proxy can now be cryptotransparent?

Or are you saying that we need an analogous method to rfc2817
such that Alice's UA establishes a TCP tunnel to each of Bob's
user agents and then an upgrade happens to cause each of Bob's user
agents to send their respective certs to Alice?

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 17:41:07 -0600

> agents to send their respective certs to Alice?

yes, that's one of the better alternatives.

--
Dean