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.

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> Sent: Wednesday, April 06, 2005 12:39
> To: Audet, Francois [SC100:9T51:EXCH]; Fries Steffen; fluffy@cisco.com
> Cc: IETF SIP List
> Subject: RE: [Sip] RE: Question to Identity draft
> 
> 
> 
> I agree that the problems you describe below are all 
> retargeting problems. The retargeting draft 
> (peterson-sipping-retarget-00 Section 2.3) notes that this 
> problem applies to the RFC3261 INVITE-like certificate 
> exchange mechanism. All in all, though, I'm pretty sure that 
> these sorts of problems are more tractable in a 
> SUBSCRIBE-like model for certificate acquisition than they 
> are in an INVITE-like model for certificate acquisition.

[rest trimmed]