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

["Peterson, Jon" <[e-mail]>]

(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:[e-mail] 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:[e-mail]', 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:[e-mail]]
Sent: Thursday, April 07, 2005 2:20 PM
To: Peterson, Jon; 'Fries Steffen'; '[e-mail]'
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip