RE: sipping-retarget (was RE: [Sip] RE: Question to Identity draft)

The idea of providing a 'Connected' header and signing it is the subject of 2.2.1 of sipping-retarget. It was in fact the strawman against which the unanticipated respondent problem was defined. Namely, 2.2.1 is concerned with the fact that impersonation is difficult to even define when it comes to response identity, because there is no concept of a unique impersonatable respondent, and consequently it is impossible for the UAC to know who is actually authorized to respond - it must assume that virtually anyone could legitimately be answering. It is possible to detect an impersonation of a particular someone; very difficult, and most likely self-defeating, to try to detect the impersonation of virtually anyone. I'm not sure how your points below (in the first part) provide us with any traction on this issue.

Regarding your flow for sipping-certs, a few comments. First of all, yes, Alice could include her certificate in an INVITE, thereby obviating 4 and 5 (and 11 and 12). I don't think sipping-certs meant to rule that out; the point is, before one sends a request, it is useful to be able to look up the cert in a repository rather than just sending an INVITE without SDP or something - the same principle clearly does not apply to receiving a request, wherein the request itself can always provide the caller's cert. 

More importantly, I think the promise of a certs-like approach lies in what happens in step 2. If the cert store has access to Bob's location service, the cert store may be able to anticipate that Alice needs to talk to Carol right now, not Bob. If that's the case, maybe sending back a NOTIFY with Bob's cert isn't the right thing to do in this instance.

The whole point of having things like SUBSCRIBE/NOTIFY in the SIP protocol is to allow the network to adapt to changing conditions in real time. If Bob is no longer the person that you're going to reach when you call Bob, and your request will only work for Bob (e.g., you're going to encrypt it with Bob's public key), the cert store should be able to tell you that this isn't going to work, and potentially give you some idea of who you will reach. To be clear, I'm not suggesting that sipping-certs provides a mechanism for this today - but I am arguing that the fundamental -approach- of sipping-certs allows for this sort of functionality, and that this could potentially eliminate surprise 493 responses.

Of course, even if a cert store has access to a location service, it may be in no position to tell you who is going to pick up the call. It may be that Bob has populated his location service with 5 different URIs, targeting any one of which might result in a completed call or not. In these cases we are in a genuine quandry. Encrypting an SDP body five different times, and including all five in a message, is no fun, let alone discovering the certificates of the five targets. This is a generic forking problem, though, and it taps into the heart of the question of whether or not redirection or retargeting is preferable architecturally. Encrypting to multiple targets has always been one of forking's known drawbacks.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:audet@nortel.com]
Sent: Tuesday, April 19, 2005 5:43 PM
To: Peterson, Jon; 'Fries Steffen'; 'fluffy@cisco.com'
Cc: 'IETF SIP List'
Subject: RE: sipping-retarget (was RE: [Sip] RE: Question to Identity draft)

OK, forget about the idea I was proposing, and instead let's 
try to achieve it using the something along the lines of the 
identity draft. 

What about the connected number information being essentially 
the same mechanism as what you have for the Calling identity, 
but provided in the response? 

Something like a new "Connected header" (or perhaps Contact 
would be sufficient, I'm not sure), followed by the 
Identity and Identity-Info? The Identity-Info header could 
have something like https://biloxy.example.com. 

The unanticipated respondent problem would be easier to deal 
with because: 
- In a lot of case, Bob and Carol (the retargetter and retargettee) 
  could have the same certification authority, so Alice's decision to 
  proceed or not with the call may not require going fetching the 
  yet another certificate. 
- Maybe we have "Require: connected-identity" header if we need the 
  identity. 
- Yes, if the SDP was encrypted (because of sRTP or whatever), it would 
  cause another session to be re-established because of the 493 (or 
  other appropriate rejection code). 

Would that be a good way to solve the Connected number problem? 

Now, moving to the next problem, the encrypted SDP. 

Alice wants to call Bob and have secure media (because she is afraid of hackers 
tapping in).  In fact, she essentially wants all her media encrypted, regardless of 
who she talks too, even strangers. She does not have Bob in her contact list, as she 
is calling him for the first time. She also doesn't know Carol, his assistant to whom the 
call will be retargetted. 

In the example above, the sequence would be this: 

1 - Alice sends SUBSCRIBE to Bob to fetch his certificate because she doesn't have it. 
2 - Bob sends NOTIFY to Alice with his certificate. 
3 - Alice sends INVITE to Bob, with SDP encrypted using Bob's key, along with her Identity 
4 - Bob doesnt' have Alice's certificate, so he sends SUBSCRIBE to Alice to fetch her cert. 
5 - Alice sends NOTIFY to Bob with her certificate. 
6 - Bob retargets to Carol (forwards the INVITE to Carol). 
7 - Carol responds with 493, since she can't decode the SDP, and includes her Contact 
    and her Identity. 
8 - Alice sends SUBSCRIBE to Carol to get her cert. 
9 - Carol sends NOTIFY to Alice with her cert. 
10 - Alice sends INVITE to Alice with her Identity, encrypted with Carol's key. 
11 - Carol sends Alice a SUBSCRIBE to get her certificate. 
12 - Alice sends NOTIFY to Carol with her certificate. 
13 - Carol sends 200 OK to Alice, with SDP encrypted using Alice's key. 

This is way too complicated and will take forever to complete a call. And in my mind, 
lots (if not the majority) of calls would look like this in environments where 
unanticipated respondents are typical (which is the case for a lot of 
businesses). 

Couldn't this be avoided if not only was Identity used in both directions 
(solving the unanticipated respondent problem), and if Alice and Carol also 
included their user certificate (for the purposed of sRTP) in the INVITE and 
493? Instead of a 10 roundtrip session setup, it would be a 2 roundtrip 
session setup. 

Of course, in the case of people who know each other, Alice would have subscribed to 
Bob and Carol's certificate, so none of this would happen: it would be a 1 round-trip 
session setup. In other words, I DO like the Certs draft, and it should be used 
whenever possible. 

> -----Original Message----- 
> From: Peterson, Jon [ mailto:jon.peterson@neustar.biz] 
> Sent: Monday, April 11, 2005 16:09 
> To: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; fluffy@cisco.com 
> Cc: IETF SIP List 
> Subject: sipping-retarget (was RE: [Sip] RE: Question to 
> Identity draft) 
> 
> 
> 
> (maybe this should move to SIPPING, as this is properly about 
> sipping-retarget, but I'll leave it here for now) 
> 
> Francois, 
> 
> sipping-retarget-00 is not intended to provide a solution 
> space, if any, for retargeting problems; that is why it may 
> seem to lack anything by way of a conclusion or concrete 
> proposal. When the draft gets revised, I may try to insert 
> some more speculation about the plausible parameters for some 
> limited-scope fixes, but as it stands, the draft really just 
> shows why a lot of things won't work. 
> 
> I guess I am not convinced that the rough proposal you 
> outline below really escapes the problems detailed in 2.2.1 
> and 2.3 of sipping-retarget. The whole issue of using a 
> certificate to provide connected-party is problematic 
> because, in order for someone to rely on a cert to identify 
> the connected-party, it cannot be a self-signed cert. Issuing 
> publicly-verifiable certs to end users (with subjects of form 
> sip:jon@example.com or what have you) is known to be 
> extremely difficult from an operational perspective. Indeed, 
> if it were plausible to enroll end-users in PKIs, much of the 
> security work in email, SIP and most other Internet 
> applications would be taking a radically different form. The 
> current level of S/MIME support in SIP deployments is a good 
> indication of how well the implementation community is likely 
> to react to this appraoch. While the problems in 2.3 are 
> specific to S/MIME implementations, and thus could 
> conceivably be addressed with a solution that is predicated 
> on S/MIME, the problems in 2.2 and 2.2.1 are really generic 
> ones that need to be addressed for clients that don't support 
> S/MIME (since S/MIME is, as we all know, only a MAY in RFC3261). 
> 
> Even if there were a CA-signed certificate passed in the 
> backwards direction which could tell a UAC whom is responding 
> to their request, that doesn't make the remote side any less 
> unanticipated, nor tell the UAC whether or not it should 
> encrypt future calls to the original Request-URI with this 
> certificate, nor tell the UAC how to deal with multiple 
> responses that contain different certificates, and so on. 
> 
> Regarding your suggestion to encrypt or withhold SDP, how 
> would you ever decide it is safe to provide SDP in an INVITE, 
> if essentially it is possible for any INVITE to be 
> retargeted? That is tantamount to always requiring a 
> two-phase INVITE. When you encrypt the SDP body initially, at 
> least that only results in a two-phase handshake for SIP when 
> retargeting has occurred, but in either case this is a 
> definite liability. Whenever there is a possibility of a 
> two-phase handshake, there is a possibility that the 
> certificate you acquire in the first phase will not work for 
> the second phase, unless you change the target URI for the 
> request (like you suggest below, using a GRUU or something). 
> However, changing the target URI for the request may be 
> self-defeating. If I am trying to call you, and I get 
> retargeted to Steffen, and Steffen provides me his 
> certificate... and then you become available before I send 
> the second phase INVITE... what is the desired effect? Am I 
> actually trying to contact you or Steffen? If I'm trying to 
> talk to you, why am I encrypting my message with Steffen's 
> certificate? But of course I may not even know the 
> difference, if any, between "you" and the URI to which I have 
> been retargeted. If I'm trying to send an INVITE to you, and 
> I get back a 493 with a certificate for something really 
> opaque, like 'sip:user51@example.com', how am I supposed to 
> understand that? Is that URI a pseudonym for you, or does it 
> represent someone else? Do I want to encrypt my message with 
> that certificate or not? Do I want to use that certificate in 
> the future when I try to contact you? 