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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Apr 2005 19:09:19 -0400

(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:[email-masked] 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:[email-masked]', 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? 

At the core of these problems is the bare fact that retargeting creates an linkage, perhaps even an equivalence, between URIs which are not necessarily equivalent at all from a security and authorization perspective. These are the -hard- authorization problems inherent in the presence of retargeting which are the subject of 2.3, and I really don't see anything below that provides us with additional leverage on these problems.

So if I'm so negative on this whole 2.3 problem space, why do I keep saying that the sipping-certs model is more promising than the INVITE model when it comes to 2.3? Because a cert store is a single authoritative place where "my" certificate exists. If I am a using a different certificate for the next hour, I can PUBLISH it to that store from my new user agent. If you are subscribed to my certificate, you will receive a corresponding NOTIFY with my new certificate which you can immediately use. If I log into a new user agent and I want to use my old certificate, I can fetch my private keying material from the cert store and use it to decrypt messages I receive. My certificate is attached to "me". Contacts that are registered under my AoR may or may not be "me", and I may set up forwarding to contacts that would not have my certificate: but in a sipping-certs environment, it is unambiguous that those people are not "me" from an authorization perspective. Furthermore, these certs don't have to be signed by a CA because their authority derives from the place where you acquired them - a certificate store responsible for my namespace. Self-signed or publicly-signed, a certificate in a response to an INVITE will never have that sort of authority because it derives from some third party (the respondent) whose relationship to me is ultimately unclear.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Thursday, April 07, 2005 2:20 PM
To: Peterson, Jon; 'Fries Steffen'; [email-masked]'
Cc: 'IETF SIP List'
Subject: RE: [Sip] RE: Question to Identity draft

Hi Jon, 

Your draft peterson-sipping-retarget-00 describes very well the 
issues at hand. 

I don't view the use of INVITE as a "fetch". To me the SUBSCRIBE 
mechanism is the fetch mechanism, and it should definitively be used 
whenever it is possible. There is a very strong incentive to use 
SUBSCRIBE to fetch the certificates of the "people you know" because 
it will result in session setup in ONE round-trip (which will not be 
the case when there is a failure, as with unanticipated respondents). 

What I am saying is that there are a lot of cases where the 
SUBSCRIBE mechanism will NOT work, but where you may still have 
a need for either/both Identity and/or Privacy (encryption). We 
absolutely need to acknowlege that this will happen (and it will 
happen a lot). 

I've listed a few cases where SUBSCRIBE won't work. It boils down 
to cases where the responder is unpredictable which is extremly 
common. 

Going through the specifics of the retarging-draft regarding identity: 

- To me the logical choice for the connected party information would be 
  to use the far-end certificate (especially if we need to do encryption 
  as well). It fact, it seems to be the only choice as, as you point out, 
  it is impossible to enforce a rule that prohibits proxies from 
  retargeting in a domain it is not responsible for. 

- It seems to me that it would solve the unanticipated respondent problem 
  (2.2.1). The sender of the request would have many choices, depending 
  of the application, on what to do before sending a request: 

  - In the case of sending a request that does NOT include an encrypted 
    body, the sender needs to decide if there is any information that is 
    sensitive before it sends the request. For example, if it is a SIP 
    INVITE, it may decide that it will NOT send an SDP body (because it 
    doesn't want to advertize the information to anybody) in the INVITE 
    (which means it is doing delayed offer/answer. That particular mechanism 
    has some advantage, including avoiding a re-negotiation later on (what you 
    call the fetch). There are some cases where this makes sense. 

  - In most cases, I would say that you would use encryption (S/MIME) to 
    send the body. This means that there is no unanticipated respondent 
    problem because the unintendent respondent won't be able to decrypt 
    the body in the first place. Perhaps, we should highly recommend 
    this approach (as opposed to "depopulate the message" as above. 

  - Again, if for specific requests, it only makes sense to reach a specific 
    recipient (e.g., MESSAGE), you still have the option to rely strictly on 
    SUBSCRIBE. To me the real important use case where SUBSCRIBE is not 
    enought is INVITEs (and more importantly, for sRTP). 

  It is important to acknowledge in advance that there is no way for the 
  sender to know in advance that there will be an unanticipated responder. 
  Even if a SUBSCRIBE was successful earlier, it may still be retargeted. 

- In section 2.3, you talk about using 493. Personally, I would think that 
  a 3XX code (possibly a new one) would be more appropriate. In case of 
  forking for example, it is more likely that the forking proxy would redirect 
  than a 4XX code which would be very likely to be dropped. You talk about a 
  potential problem that the new INVITE could still be routed to a different 
  users (just like SUBSCRIBE). Why not use a URI that specifically refers to 
  a specific user as a Contact (perhaps a GRUU)? This essentially transforms 
  a retargeting into a redirection, which solves a lot of issues (the To: 
  would of course remain as per the original INVITE). 

- The second to last paragraph of 2.3 says that "This whole class of failure 
  would be preventable if Alice were able to guess who would eventually receive 
  her request." I would say that it is quite unrealistic to think that this 
  is feasible all the time. There are countless examples where this is not 
  possible, and where you would still want to know (1) who responds, and (2) you 
  may still want to do encryption. 

- In section 2.4 you talk about consent of the UAC. You are right: this is 
  absolutely crucial. My take is that the UAC could clear the session. 
  I would say that would be appropriate for INVITEs for example (keep in mind 
  that normally, the receiver wouldn't understand the SDP if it is not 
  authorized, so no harm is done). I would agree that you probably don't want 
  to do this for MESSAGE. We could also do some sort of precondition if 
  we really have to. 

- Section 5 is where I was a little puzzled... The way I read the document, 
  I was convinced the conclusion would be to use a "Connected party" approach, but 
  instead it suggests that the entities doing the retargeting would have to 
  do some new procedures. I think this is not enforceable. Even if it was enforceable, 
  it would be increadibly complicated when multiple retargeting occur. I'd much rather 
  rely on the certificate of the responder, and let the sender decide how to proceed. 

This would also allow for supporting sRTP to unanticipated respondents. 

Note: I will point out that MIKEY allows for this today because the certificates 
      can be included in the MIKEY message. Not so for SDESC. If we "pop up 2 levels" 
      the certificates to the SIP level (instead of inside MIKEY inside SDP in SIP), then 
      we could have a solution that would work for both mechanisms, allowing a UAC to 
      advertize support for both mechanism. You could use S/MIME with both mechanisms. 

_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Apr 2005 20:11:59 -0400

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:[email-masked]]
Sent: Tuesday, April 19, 2005 5:43 PM
To: Peterson, Jon; 'Fries Steffen'; [email-masked]'
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. 

> From: Peterson, Jon [ mailto:[email-masked]] 
> Sent: Monday, April 11, 2005 16:09 
> To: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; [email-masked] 
> 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:[email-masked] 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:[email-masked]', 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?

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 21 Apr 2005 19:51:28 -0400

That is certainly one of the primary cases I had in mind when I suggested that a "group cert" would sometimes work; a case where there is in fact effectively a group user agent.

Jon Peterson
NeuStar, Inc.

> I think this is largely a red herring. In many call center applications 
> it will be a requirement not to disclose the identity of the actual 
> agent - probably not even a synonym. There is a high likelihood that the 
> call center will act as a B2BUA between the caller and the agents, for 
> that reason and others. ("Your call may be monitored for quality.") So 
> there will be no retargetting as far as the caller is concerned, and no 
> identity problem.
> 
> 	Paul
>