Subject: [Sip] Response Identity

From: Cullen Jennings <[email-masked]>
Date: Fri, 21 Oct 2005 22:52:50 -0700

This is the follow-up on the collected feedback about SIP Response Identity.

Feng and I put together what seem to be some of the key questions that have
been on the list about response identity then Feng put together the start of
some analysis. I thought this looked like some interesting work that might
spark some discussion on how we should solve this problem. We would
appreciate any feedback folks care to give.

Thanks, Cullen

1. Q1 and Q1.1 is about the response identity.

   Q1: Which approach is chosen to indicate the responder's identity?

       A: the responder's identity is embedded into the response
           message directly

       B: Instead of any change on response message, the responder must
           send one additional request back to the originator AND embed
           the responder's identity into the request message, RIGHT after
           the responder sends its response.

       Analysis: 

         For A, pros:
            * no additional request or response is needed
            * works when the responder is either proxy or UA
            * relatively simple, without changing any per-dialog state

           Cons:
            * need to answer Q1.1 (see below)
            * need new development after Q1.1 (and Q3) is answered

         For B, pros:
            * no need to face Q1.1
           Cons:
            * additional trip delay for each SIP request
            * additional request and response are needed
            * when the responder is a proxy, this is unnecessary overhead
                for a proxy.
            * need the state modification for the originator and the
                responder.

   Q1.1: If A is chosen in Q1, how to embed the responder's identity
           into the response message?

      A: allow the responder's identity to be clearly specified in the
           response header AND the digest is inserted into the header by
           leveraging "Identity" defined before.

      B: allow the responder's identity to be clearly specified in the
           response header AND use AIB for carrying the responder
           identity and related digest.

      Analysis:
         For A, pros:
            * simple, quite straightforward
            * easy for proxies to check the responders identity
           Cons:
            * anonymity is impossible
            * adds yet another header that has conflicting data
              about identity

         For B, pros:
            * anonymity is possible
           Cons:
            * need to insert AIB into the message
            * anonymity may need end-to-middle support for some proxies.

         Note: Anonymity is described here with respect to A and B.
               For A, any node involved in the SIP dialog can reveal
               the responder identity by looking into the response
               header.

               For B, the responder identity can be hidden into the
               encrypted AIB into the message body. Only the desired
               node(s) with the corresponding key(s) can reveal the
               responder identity.

2. Q2.1 and Q2.2 are about the response authentication.

       Q2.1: Will TLS be deployed in EVERY single hop for each SIP
            dialog?

       A: Yes
       B: No

      Analysis:

         B is apparently the answer.

    Q2.2: If B is chosen in Q2.1, can TLS be expected to be deployed in
            EVERY single hop for each SIP dialog soon? How soon?

       A: Yes. Regardless of how soon, the community can wait and hope
            for the best.

       B: No. Response authentication needs to be enhanced inside SIP
            itself, which can be complementary to TLS when some hops
            don't have TLS.

       Analysis:
         For A, pros:
             * uniform approach through TLS
             * keep the burden from SIP

            Cons:
             * as long as one hop doesn't have TLS, the chain of trust
                 is broken
             * big risk of expecting TLS be deployed in EVERY single hop
                 soon (there are always exceptions).
             * the progress of moving to TLS in the past has been slow

          For B, pros:
              * if it can be done faster, well it would be done faster

             Cons:

              * enhancement work for SIP
              * not uniform approach anymore (even though they are
                  complementary to each other)
              * as long as one hop doesn't use the new per-hop response
                  authentication, that hop should use TLS. If not,
                  the chain of trust is broken again.
              * not clear it can be done faster than TLS at every hop

3. Q3 is relatively trivial, but it needs the clarification.

   Q3: If its related policy doesn't forbid it to reveal its identity
       for that dialog, how should the responder decide when it should
       reveal its identity back to the originator?

      A: the responder should reveal its identity as the default
           behavior.

      B: the responder must reveal its identity IF AND ONLY IF
           the request message has the new option tag in ìRequire:î
           inside its header? For example, ìRequire: responder-idî.
            
      Analysis:
         For A, pros:
            * responder identity will be available as the default
           cons:
            * may provide unnecessary responder identity in some
                scenarios
          
         For B, pros:
            * reduce the unnecessary disclosure of responder identity
           cons:
            * need to add new option tag into ìRequireî in request header

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Sun, 23 Oct 2005 20:46:02 +0100

Cullen,

In-line

John

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 22 October 2005 06:53
> To: [email-masked]
> Cc: Cullen Jennings
> Subject: [Sip] Response Identity
> 
> 
[JRE] There is an additional advantage that the same mechanism can be used
to indicate a change of identity during a dialog, as might happen if a
gateway becomes aware of changes in the other network.

>             * additional trip delay for each SIP request
[JRE] There needn't been an additional round trip delay for the original SIP
request. The original SIP request can still receive a final (2xx) response
and is then complete - response identity will occur a short time later (or
earlier, if it is sent after a 1xx response but before the 2xx response).

>             * when the responder is a proxy, this is 
[JRE] It is questionable whether response identity is needed for a request
receiving a non-2xx final response, and hence whether response identity
needs to be generated by a proxy. In draft-elwell-sip-connected-identity I
suggest that response identity (or connected identity) is important only
when a dialog is established. Thus it would never come from a proxy.

>            leveraging "Identity" defined before.
[JRE] The question is how to include the responder's identity in the
response header in a way that will be signed by the Identity header. It may
need a different header to sign it.

>             * anonymity is impossible
[JRE] An equivalent level of anonymity to that provided by the Identity
header should be possible.

>             * adds yet another header that has conflicting data
[JRE] Why would it be conflicting? The To header field is known not to
reflect reality in many cases.