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

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? 