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

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Apr 2005 20:43:18 -0400

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:[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? 
_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Thu, 21 Apr 2005 22:30:01 -0400

Francois, 
Definitely agreed that we are converging, here. I substantially concur with
all that you say pretty much up to the last couple paragraphs.  

Good! 

If Bob is actually a group list, I would note that for certain kinds of call
center applications and so on, it actually -does- make sense for the group
to share a cert. No question, though, that for a large group like that where
a common cert cannot be used, it would be very difficult for a location
service to anticipate precisely who is going to answer.  

I most definitively agree with this paragraph.

Regarding forcing redirection in order to prevent the unanticipated
respondent problem - well, that was the proposal of sip-identity-02. At the
time, that made a lot of people very nervous, although to some degree I
think it was an overreaction (sip-identity-02 didn't propose eliminating
retargeting from SIP, it proposed limiting the cases in which an entity
which acted as an auth service would be eligible to retarget requests), I
think that conceptually there were problems with the approach. We really
don't have the fundamental apparatus in SIP to be able to make intelligent
decisions about when retargeting should and should not occur, largely
because the distinction between AoRs and other types of URIs is merely a
conceptual distinction, and not something that a location service could
distinguish programmatically.  

Actually, what I was proposing is different from what was in
sip-identity-02.

I was proposing that the unanticipated responder itself (or its
Authentication service) would do the redirection (to itself) upon receiving
the retargeted request (sip-identity-02 put that responsibility in the
redirecting proxies themselves which I want to avoid). 

In other words, if the responder (or it's authentication proxy) supports
"connected identity", it MUST use the redirection. The advantage is that
suddently, it doesn't matter if there are non-conformant retargetting
proxies in the middle. It is also much more efficient as there is only ONE
redirection ever needed. The sender could have a Required or Supported
header or something to request the connected identity.

To use your wording, we also "get to use retargeting" (or at least
retargeting where it matters) with this approach because the generic proxies
are still retargeting. It is therefore backward compatible with existing
proxies. The ultimate endpoints in the session handle the retargeting, so
there is only one retargeting. It allows the sender and responder to control
their own destiny regadless of what happens in the middle (or their
respective authentication surrogate). Also, it doesn't waste any round-trips
for establishing the session because it the S/MIME would have been rejected
anyways, so it's the same. Keep in mind here that this procedure only really
kick in when subscription failed to produced the right result because of
non-predictable retargeting.

Another thing that comes to my mind is that if using 3XX/4XX (redirection)
is not appropriate (because of HERFP for example), the unanticipated
respondent could send an UPDATE instead as a target refresh (without an SDP
Offer) before sending the final response. This works quite well for Identity
in isolation of certs (i.e., if S/MIME is not use), and seems logical to me.
(Or maybe the UPDATE should come from the sender based on reception of a
reliable provisional response including the Connected identity: need to
think about that).

If S/MIME was used, the UPDATE would be send by the responder before the
final response (presumably a 492 because the responder can't decode it) as
above (again, perhaps the 1XX followed by sender initiated UPDATE makes more
sense). It could also include a Cert in the UPDATE (or 1XX). The responder
may or may not receive the 492, as we know since it could get some other
response, but it does leave good options to the sender. If another negative
response is received from another remote UA, the sender could re-attempt the
call to the authentified unanticipated respondent, but this time encypting
the S/MIME with its cert. Another option would be for the sender to
re-INVITE to the AoR (which could fork again) but without an SDP because it
now expects nasty forking (anyways, this is just implementation details).
This paragraph is kind of messy: we might be able to find something better.

Moreover, how would a respondent 'force' a redirection, I wonder? If the
redirection actually comes from the respondent, I submit that we're no
better off in solving the unanticipated respondent problem than we are if
the respondent sends a 200, or a 604. The UAC still has no way to tell if
the response (success, failure, or redirection) is coming from an authorized
respondent.  

The respondent would have to use the same identity procedures as the sender,
i.e., the Identity and Identity-Info header. The sender can then look at
that identity header to determine if it is valid.

 Moreover, how would a respondent know that it is necessary to force a
redirection?  

Perhaps if the "To" header does not correspond to itself and if the
Connected identity was requested (as per the suggestion above to use a
Required or Supported header).

Finally, let me say a couple more things about redirection and the SUB/NOT
model. I think you and I at least agree that many of the sipping-retarget
problems start to go away if Bob's location service exposes the route target
list associated with Bob to Alice. The more information the UAC gets, the
less 'unanticpated' these respondents become. Redirection is of course one
way that the route target list can be given to the UAC for its own use.
Lately, though, I've been giving a lot of thought to what sip-events might
be able to do for us here. Assuming something like reg-event, say, or maybe
even just presence, the UAC can receive an up-to-the-minute picture of what
sorts of services and URIs are associated with Bob. Presence can provide a
menu of services, different URIs with different capabilities, associated
with a particular user from which prospective callers can actually choose.
If, when Alice subscribes to Bob's reg-events, say, she was able to see that
Carol is a potential contact for Bob, then Alice wouldn't be surprised if,
when she sent an INVITE to Bob, Carol answered. Potentially, exposing route
target sets ahead of time could let Alice even choose from among the
possible alternative contacts (to avoid people she wouldn't want to talk to
anyway). If Alice sees that Carol is a contact for Bob, Alice could even
fetch Carol's reg-event and learn that Ted is a contact for Carol, and thus
be able to anticipate Ted, and so and so forth. The interesting thing about
this approach is, of course, that we get to keep retargeting. What it
further demonstrates is that it is possible for a UAC to get the information
it needs to be able to anticipate retargeting even the UAC does not control
call routing - I think this separation is critical to retargeting advocates.
One can even imagine that presence-style policies, XCAP and so on, could be
used to govern how much information the UAC gets about Bob's contacts for
callee privacy purposes.  

Hum, I'm not completely sold on the idea, because it seems quite heavy. But
to be fair, I can see how it could work in a lot of closely integrated
environments. So I would say, why not give it a try and define those
procedures.

But... ;^)

I don't believe it will solve all the problems. I strongly believe that
ultimately, the sender and responder should be able to detect by themselves
when retargeting occurs (including with existing "legacy" proxies), and be
able to check their own identities. Who knows what the nasty network will
do.

In a way, you could view what I am proposing (or something along those
lines) as the mechanism of last resort. When not everybody in the network is
doing it's job, or when the trust and administrative domain are many.

My point here is not, of course, to make a concrete proposal, but just to
say that there are ways other than redirection that we might approach the
unanticipated respondent problem, that there are clear tradeoffs, and that
we can get some pretty interesting capabilities if we go down one path
instead of another. Ultimately, I think we still have a long road ahead of
us, in terms of understanding the problem we want to solve and understanding
what is the best approach to a solution. 

Indeed. 

The way I see it, we need to design this in a way that encourages the use of
presence/subscription, but has a fall-back mechanism for the cases where it
doesn't apply or fails. So I really don't think it is a matter of one way or
another. 

Cheers.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 21 Apr 2005 22:48:00 -0400

I think we circled that one: in some cases it is appropriate, in 
other cases it is not.

> Sent: Thursday, April 21, 2005 16:51
> To: Paul Kyzivat
> Cc: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; 
> [email-masked]; IETF SIP List
> Subject: RE: sipping-retarget (was RE: [Sip] RE: Question to 
> Identity draft)
> 
> 
> 
> 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
> > 
> 
>