Internet DRAFT - draft-xu-yang-retargeting-security

draft-xu-yang-retargeting-security





   SIP WG                                                               
   Internet Draft                                              Xu. Yang 
   Document: draft-xu-yang-retargeting-security-         Sonus Networks 
   00.txt 
   Expires: November 2007                                      May 2007 
    
    
       Retargeting Security in the Session Initiation Protocol (SIP) 
                 draft-xu-yang-retargeting-security-00.txt 
    
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   This Internet-Draft will expire on Oct, 2007. 
    
Copyright Notice 
    
   Copyright (C) The IETF Trust (2007). 
 
Abstract 
    
   As a SIP request is processed along its route to the destination, the 
   initial request-URI can be altered without callers’ notice or 
   consent. The caller may concern both the final call recipient’s 
   identity and the authorities of the SIP intermediaries that alter the 
   request-URI. Especially when the caller does not know the final call 
   recipient, simply giving his/her identity to the caller will not help 
   the caller to decide the legitimacy of the call. Without a secure 
   retarget mechanism, the end-to-end security of SIP cannot be 
   guaranteed. This document proposes a security mechanism to provide 
 
 
Yang                   Expires - November 2007               [Page 1] 
                         Retargeting Security                 May 2007 
 
 
   the caller with credentials of SIP intermediaries that retarget a 
   request and the final recipient’s identity through response.  
    
    
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [i]. 
       
   Related response: final responses that define the security attributes 
   of existing or future dialogs. The related responses include the 2xx 
   response that carries the callee’s identity, the 3xx response that 
   carries the callee’s new contact addresses, and the 496 or 493 
   response that carries the security key for future dialogs. 
        
    
Table of Contents 
    
   1. Introduction...................................................2 
   2. Definitions....................................................4 
   3. Overviews of solution..........................................4 
   4. Behavior.......................................................5 
      4.1 User Agent Behavior........................................5 
      4.2 Proxy Behavior.............................................5 
      4.3 Redirector behavior........................................6 
   5. Criteria for recording and checking request-URI changes........7 
   6. Formal Syntax..................................................7 
   7. Message Examples...............................................8 
   8. IANA considerations...........................................13 
      8.1 Header....................................................13 
      8.2 Optional Tag..............................................13 
   9. Security Considerations.......................................13 
   References.......................................................14 
   Acknowledgments..................................................14 
   Author's Addresses...............................................14 
   Intellectual Property and Copyright Statements.................. 15 
    
1. Introduction 
    
   As a SIP request is processed in intermediaries, the initial request-
   URI can be altered with one or more targets identified via location 
   service. This process, so-called Retargeting, is often done without 
   callers’ notice or consent. Since the current standards do not 
   provide a mechanism for a UAC to constrain or authorize SIP 
   intermediaries as what should be performed, and to authenticate the 
   final call recipient’s identity through SIP response, the UAC does 
   not know where a request goes, how a request reaches a particular UAS 
   and who this UAS is [5].  
 
 
Yang                   Expires - November 2007               [Page 2] 
                         Retargeting Security                 May 2007 
 
 
    
   In some circumstance, users are more interested in how a request 
   reaches a particular UAS, e.g., when Alice calls Bob and Bob 
   redirects calls to Carols, Alice wants to make sure that it is Bob 
   that designated the delegation agent. It is also useful in the 
   calling center when a call is redirected to a special handling agent, 
   especially when the agent is outside the original domain. The UAC can 
   determine the URI that a request has eventually reached and determine 
   whether the chain of trust is broken during request retargeting, 
   e.g., the request is retargeted in some suspicious domains. 
    
   Although connected identity [2] has proposed to use mid-dialog 
   requests, e.g., an UPDATE method or re-INVITE method, to transfer the 
   updated calling and called party’s identity based on RFC4474, several 
   issues are still not resolved.  
    
   (1) The response identity problem. The handling of responses such as 
   ‘493 Undecipherable’ and 3xx is fraught with risks if the identity of 
   the sender of the response cannot be identified. Consider the 
   following scenario mentioned in [5]: If Alice's request to Bob is 
   retargeted to Carol and Carol does not possess the private key 
   corresponding to Bob's public key, she would send some sort of 
   failure response code (perhaps a 493 Undecipherable). According to 
   the manner suggested in RFC3261, Alice might re-initiate the session 
   using Carol’s certificate received in the body of 493 response. Here, 
   Alice has no way of knowing if Carol is actually an attacker who 
   sends a 493 in order to bid-down the security for the ensuing RTP 
   session. 
     
   (2) If sometimes (1) can sometimes be avoided with connected identity 
   [2], it means more rounds of message exchange. For example, a session 
   only consists of an INVITE and a 3XX, or a MESSAGE with encrypted 
   message body, [2] seems over weighted. 
      
   (3) If the target is redirected to an unknown domain, then secure 
   retargeting is more important because of the unanticipated respondent 
   problem, and the caller more trust the initial call recipient’s 
   domain and its retargeting process than the new respondent. 
       
   Other cases such as in the session border controller scenario, where 
   a UA cannot differentiate malicious man-in-the-middle attack and 
   legitimate SBC, the secure retargeting helps to distinguish these 
   cases if required.   
       
   To achieve end-to-end security, we feel that the response identity 
   problem cannot be omitted, and it has to be solved with the secure 
   retargeting. It is essential for the protocol to provide a mechanism 
   to feed the caller with (1) the retargeting information, (2) the 
   credential of the intermediate server that retargets a request to a 
 
 
Yang                   Expires - November 2007               [Page 3] 
                         Retargeting Security                 May 2007 
 
 
   different Request-URI, and (3) the final recipient identity. This 
   document proposes such a mechanism.  
    
    
2. Definitions 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119. 
       
   Related response: final responses that define the security attributes 
   of existing or future dialogs. The related responses include the 2xx 
   response that carries the callee’s identity, the 3xx response that 
   carries the callee’s new contact addresses, and the 496 or 493 
   response that carries the security key for future dialogs. 
 
    
3. Overviews of solution 
    
   The fundamental functionality provided by the secure retargeting 
   mechanism is the ability to collect credentials of intermediate 
   servers that retarget requests and capture the associated request-URI 
   change. The original request-URI, modified request-URI and the 
   Identity of the server that does the request-URI modification are 
   recorded in a new header for SIP messages: Target-Info. The signature 
   used for validating headers including the Target-Info header is 
   conveyed in the Identity header, and the reference to the certificate 
   of the signer is conveyed in the Identity-Info header, as described 
   in RFC 4474. An additional index parameter is added to each of the 
   above header to group related information for a single retargeting 
   server. 
       
   In applications that concentrate on sending callers target change for 
   successfully established dialogs, the Target-Info header is added to 
   2xx, 3xx and responses that would change the secure attribute of a 
   future dialog, such as the 496 and 493 responses. In this 
   specification, these responses are called related responses. 
       
   If a caller wants intermediaries to provide credentials of 
   retargeting on related responses, she/he MUST insert a new option tag 
   “target-info” in the request to initiate a session.     
       
   To shield the network configuration and reduce computation overhead, 
   proxies on the border of a trusted network SHOULD eliminate 
   intermediate retargeting process information for routing and other 
   purposes. There, the Authentication Service proxy SHOULD be logically 
   configured on the network border. When the Authentication Service 
   proxy received an incoming request with “target-info” in the 
   Supported header and the related response indicating that request-URI 
 
 
Yang                   Expires - November 2007               [Page 4] 
                         Retargeting Security                 May 2007 
 
 
   is changed within the trusted network, the proxy MUST insert Identity 
   and Identity-Info headers in the response before forwarding the 
   response to an untrusted network. Given secure connections exist 
   between trusted network elements, the proxy SHOULD merge multiple 
   Target-Info headers inserted within the trusted network into a single 
   Target-Info header, which only records the last changed request-URI 
   and the original request-URI received by the trusted network. 
    
    
4. Behavior 
    
4.1  User Agent Behavior  
    
   When issuing an INVITE request, a UAC that wishes to learn the 
   intermediate target change MUST include a “target-info” option tag in 
   the Supported header filed. 
       
   When receiving a response with Target-Info, Identity and Identity-
   Info header, the UAC inspects the signature in the Identity headers 
   and validates related header fields and the message body.  
    
   Since each Target-Info provides an old and changed request-URI, and 
   the last Target-Info provides the identity of the sender of the 
   response, the Target-Info headers can form a trace of request-URIs 
   when request is routed to the destination. For adjacent Target-Info 
   pairs, the changed request-URI in the prior Target-Info MUST equal to 
   the old or current request-URI in the next Target-Info.  
       
   The criteria for judging a request-URI change or for detecting a 
   missing request-URI change segment are specified in section 6. 
    
4.2 Proxy Behavior  
    
   For proxies that do not retarget requests, no behavior change is 
   required. 
    
   The following is the behavior of a proxy that has performed or is 
   about to perform retargeting. 
    
   When a proxy server receives a request with a “target-info” option 
   tag in the Supported header filed, if the proxy server is about to 
   change the request-URI but is not able to provide authentication 
   service for the future related response, the proxy SHOULD return a 
   420 ‘Not Supported’ response. If the authentication service is 
   provided in a centralized server, the proxy MUST be able to create a 
   secure connection with the central authentication service. 
    
   When a proxy server receives a redirect response, before retargeting 
   the request to the request-URI extracted from the contact header, the 
 
 
Yang                   Expires - November 2007               [Page 5] 
                         Retargeting Security                 May 2007 
 
 
   proxy server MUST first verify whether the redirect response is 
   directly received from a trust domain, or whether the contact header 
   of the response is verifiable from the Identity and Identity-Info 
   header. Here, the proxy delegates the process of authentication of 
   the response to the caller. A proxy server MUST not forward any 
   related response that comes from an untrust domain and does not have 
   an Identity and Identity-Info header. 
    
   If the response comes from an untrust domain but has an unverifiable 
   Identity and Identity-Info header, the proxy SHOULD forward the 
   response upstream to the caller. If the response is a result of 
   retargeting performed at the proxy, the proxy MUST insert a Target-
   Info header, and then use the domain key to sign the hash of the 
   canonical string generated from certain components of the response 
   before forwarding. 
    
   If the proxy performs a sequential or parallel search, the proxy 
   SHOULD exhaust verifiable contact headers first. 
    
   If several proxies within a trust domain perform retargeting, then 
   each of these proxies SHOULD insert a separate Target-Info header. If 
   network privacy is enforced, e.g., when the consent framework [3] 
   conceals the detailed user location, the border proxy MUST omit 
   privacy sensitive request-URI changes within the domain. In a 
   transition domain, only the original request-URI received by the 
   domain and the last changed request-URI when the request left the 
   domain are kept in the Target-Info header. In the destination domain, 
   only the original request-URI received by the domain is left in the 
   Target-Info header. While security always causes overhead, the proper 
   network configuration can significantly reduce it. Centralized 
   authentication service on a border proxy is one example. 
    
   The Target-Info header MUST be signed before sending the related 
   response out of the trust domain. 
    
4.3 Redirector behavior  
    
   If the redirect service only serves the proxy in the trust domain, 
   then there is no behavior change. 
    
   Otherwise, when a redirector receives a request with the “target-
   info” option tag in the Supported header filed, it SHOULD insert a 
   Target-Info, Identity and Identity-Info header for the redirect 
   response, or do so through an authentication service. If the redirect 
   service only serves the proxy in the trust domain, then there is no 
   behavior change. 
       
   Otherwise, when a redirector receives a request with the “target-
   info” option tag in the Supported header filed, it SHOULD insert a 
 
 
Yang                   Expires - November 2007               [Page 6] 
                         Retargeting Security                 May 2007 
 
 
   Target-Info, Identity and Identity-Info header for the redirect 
   response, or do so through an authentication service.  
    
    
5. Criteria for recording and checking request-URI changes 
    
   The criteria of justifying a request-URI change depend on the 
   request-URI scheme and the portion of the request-URI involved in a 
   change.  
       
   If a GRUU [4] request-URI is used, each request-URI change MUST be 
   recorded. 
       
   If the tel URI scheme is used, adding or deleting international or 
   area code MAY be considered as a target change.  
       
   The username change in a sip URI MUST be considered as a target 
   change. 
       
   In the same trust domain, the host portion of a request-URI may be 
   changed several times. In the destination domain, the host portion of 
   a request-URI is often detailed to a specific host address. As 
   specified in section 4, the authentication service MAY choose to 
   conceal such detailed retargeting information. In the same trust 
   domain, only receiving last modified host portion of the request-URI 
   is recorded. In the destination domain, only the receiving user name 
   and host portion of the request-URI is recorded. 
       
   The user’s involvement MAY be required for some ambiguous target 
   change. The UA can list suspicious target changes via GUI. 
    
    
6. Formal Syntax 
    
   The Target-Info header carries the following information, with the 
   mandatory parameters required. 
       
   target change: A mandatory parameter contains either the current 
   target or a pair of targets that reflect the target change. 
       
   retarget-server: A mandatory parameter captures the server name that 
   performs the retargeting. 
       
   index: A mandatory parameter that groups related Target-Info, 
   Identity and Identity-Info headers. The index starts at one. Each 
   subsequent index increases by one.  
       
      Target-Info=“Target-Info” HCOLON (target-change|current-target) 
   COMMA retarget-server COMMA index 
 
 
Yang                   Expires - November 2007               [Page 7] 
                         Retargeting Security                 May 2007 
 
 
       
      target-change=previous-target COMMA changed-target COMMA index  
      previous-target = “previous” EQUAL request-URI 
      changed-target = “changed” EQUAL request-URI 
       
      current-target = “current” EQUAL request-URI 
       
      retarget-server= “server” EQUAL name-addr 
       
      index = “index” EQUAL 1*DIGIT 
       
      request-URI = name-addr 
       
   The Identity and Identity-Info header defined in RFC 4474 are also 
   updated with the additional index parameter. 
       
      Identity = "Identity" HCOLON signed-identity-digest COMMA index 
       
      Identity-Info = "Identity-Info" HCOLON ident-info *(SEMI ident-
   info-params) COMMA index   
       
   The signed-identity-digest is a signed hash of a canonical string 
   generated from certain components of a SIP response. To create the 
   content of the signed-identity-digest, the authentication service 
   MUST use the elements of a SIP message placed in a bit-exact string 
   specified in RFC 4474, and the added Target-Info header specified in 
   this document, separated by a vertical line, “|” or %x7C, character: 
       
   digest-string = digest-string = addr-spec "|" addr-spec "|" callid 
   "|" 1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|" message-body 
   “|” Target-Info 
       
   The Target-Info above refers to the local added Target-Info 
    
    
7. Message Examples 
    
   It is expected that most retargeting happen in destination domain, in 
   which the authentication service signs and forwards the response from 
   the final call recipient back to the caller. 
       
   In the following example, we describe a simple case when UA Alice 
   initiates an INVITE to Bob and the INVITE is redirected in the 
   destination domain. We assume the destination proxy, the destination 
   redirector, and the final call recipient Bob are all in the same 
   trust domain. 
    
    
    
 
 
Yang                   Expires - November 2007               [Page 8] 
                         Retargeting Security                 May 2007 
 
 
       
                                    trust domain 
                   ------------------------------------------------ 
       
      UA               Proxy      Redirector             UA 
      :Alice       :destination  :destination:   Bob@home.destination 
       
        ----- F1-----> 
                         ------ F2 -----> 
                         <----- F3 ------ 
                                         ------- F4 ------> 
                         <------------ F5 ----------------- 
        <----F6 ------ 
             
       
       
       
   F1: UA Alice -> Proxy destination 
       
   INVITE sip:bob@destination.com SIP/2.0 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
   Call-ID: a84b4c76e66710 
   CSeq: 314159 INVITE 
   Max-Forwards: 70 
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Supported: target-info 
   Contact: <sip:alice@pc33.atlanta.source.com> 
   Content-Type: application/sdp 
   Content-Length: 147 
    
   v=0 
   o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com 
   s=Session SDP 
   c=IN IP4 atlanta.example.com 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 
       
    
   F2: Proxy destination -> Redirector destination 
       
   INVITE sip:bob@destination.com SIP/2.0 
   Via: SIP/2.0/UDP proxy.destination.com;branch=z9hG4bKnashds8 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
   Call-ID: a84b4c76e66710 
 
 
Yang                   Expires - November 2007               [Page 9] 
                         Retargeting Security                 May 2007 
 
 
   CSeq: 314159 INVITE 
   Max-Forwards: 70 
   Supported: target-info 
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Contact: <sip:alice@atlanta.source.com> 
   Content-Type: application/sdp 
   Content-Length: 147 
       
   v=0 
   o=Alice 2890844526 2890844526 IN IP4 atlanta.example.com 
   s=Session SDP 
   c=IN IP4 atlanta.example.com 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 
       
    
   F3: Redirector destination 
       
   Since both the destination proxy and redirector are in the same trust 
   domain, no security-retargeting headers are generated. Otherwise, the 
   redirector MUST insert security-retargeting headers and the proxy 
   MUST verify these headers before retargeting the request to contact 
   addresses specified in the returned 3xx response.   
       
   302 Temporally Moved 
   Via: SIP/2.0/UDP proxy.destination.com;branch=z9hG4bKnashds8 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
   Call-ID: a84b4c76e66710 
   CSeq: 314159 INVITE 
   Max-Forwards: 70 
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Contact: <sip:bob@home.destination.com> 
   Content-Type: application/sdp 
   Content-Length: 0 
       
    
   F4: Proxy destination -> UA Bob 
       
   The destination proxy changes the request-URI to 
   bob@home.destination.com. 
        
   INVITE sip:bob@home.destination.com SIP/2.0 
   Via: SIP/2.0/UDP proxy.destination.com;branch=z9hG4bKnashds8 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
 
 
Yang                   Expires - November 2007              [Page 10] 
                         Retargeting Security                 May 2007 
 
 
   Call-ID: a84b4c76e66710 
   CSeq: 314159 INVITE 
   Max-Forwards: 70 
   Supported: target-info  
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Contact: <sip:alice@atlanta.source.com> 
   Content-Type: application/sdp 
   Content-Length: 147 
       
   v=0 
   o=Alice 2890844526 2890844526 IN IP4 atlanta.example.com 
   s=Session SDP 
   c=IN IP4 atlanta.example.com 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 
       
    
   F5: UA Bob -> Proxy destination 
       
   200 OK SIP/2.0 
   Via: SIP/2.0/UDP proxy.destination.com;branch=z9hG4bKnashds8 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
   Call-ID: a84b4c76e66710 
   CSeq: 314159 INVITE 
   Max-Forwards: 70 
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Contact: <sip:bob@home.source.com> 
   Content-Type: application/sdp 
   Content-Length: 147 
       
   v=0 
   o=Alice 2890844526 2890844526 IN IP4 atlanta.example.com 
   s=Session SDP 
   c=IN IP4 atlanta.example.com 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 
       
    
   F6: Proxy destination -> UA Alice 
       
   Assume secure communications exist between the destination proxy and 
   UA Bob and the destination proxy verifies UA Bob’s identity through 
   HTTP change and response. Also assume that the privacy policy allows 
   the proxy to disclose the user location information to the caller.  
         
 
 
Yang                   Expires - November 2007              [Page 11] 
                         Retargeting Security                 May 2007 
 
 
   200 OK SIP/2.0 
   Via: SIP/2.0/UDP proxy.destination.com;branch=z9hG4bKnashds8 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
   Call-ID: a84b4c76e66710 
   CSeq: 314159 INVITE 
   Target-Info: previous=bob@destination.com, 
   changed=bob@home.destination.com,current=bob@home.destination.com, 
   server=proxy.destination.com,index=1 
   Identity:”ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0
   SsSAaifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
   FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=”, index=1 
   Identity-Info: <https://desination.com/destination.cer>;alg=rsa-sha1, 
   index=1 
   Max-Forwards: 70 
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Contact: <sip:bob@home.source.com> 
   Content-Type: application/sdp 
   Content-Length: 147 
       
   v=0 
   o=Alice 2890844526 2890844526 IN IP4 destination.com 
   s=Session SDP 
   c=IN IP4 destination.com 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 
       
   If assume that the privacy policy does not allow the proxy to 
   disclose the user location information to the caller, F6 should look 
   like this: 
       
    
   F6: Proxy destination -> UA Alice  
    
   200 OK SIP/2.0 
   Via: SIP/2.0/UDP proxy.destination.com;branch=z9hG4bKnashds8 
   Via: SIP/2.0/UDP pc33.atlanta.source.com;branch=z9hG4bKnashds8 
   To: Bob <sip:bob@destination.com> 
   From: Alice <sip:alice@atlanta.source.com>;tag=1928301774 
   Call-ID: a84b4c76e66710 
   CSeq: 314159 INVITE 
   Target-Info: current= bob@destination.com, 
   server=proxy.destination.com,index=1 
   Identity:”ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0
   SsSAaifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
   FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=”, index=1 

 
 
Yang                   Expires - November 2007              [Page 12] 
                         Retargeting Security                 May 2007 
 
 
   Identity-Info: <https://desination.com/destination.cer>;alg=rsa-sha1, 
   index=1 
   Max-Forwards: 70 
   Date: Thu, 21 Feb 2002 13:02:03 GMT 
   Contact: <sip:bob@home.source.com> 
   Content-Type: application/sdp 
   Content-Length: 147 
       
   v=0 
   o=Alice 2890844526 2890844526 IN IP4 destination.com 
   s=Session SDP 
   c=IN IP4 destination.com 
   t=0 0 
   m=audio 49172 RTP/AVP 0 
   a=rtpmap:0 PCMU/8000 
    
    
8. IANA considerations  
    
   This specification registers a new SIP header and a new option tag. 
    
8.1 Header 
    
   This specification registers a new SIP header, according to the 
   guidelines in Section 27.1 of RFC 3261. 
       
   Name: Target-Info 
       
   Description: This new header captures the request-URI change and the 
   current request-URI. 
    
8.2 Optional Tag  
    
   This specification registers a new optional tag, according to the 
   guidelines in Section 27.1 of RFC 3261. 
         
   Name: target-info 
    
   Description: This option tag is used to indicate that a UA requires 
   intermediate proxies that perform retargeting to add Target-Info, 
   Identity and Identity-Info headers in the response. 
 
 
9. Security Considerations 
    
   This document proposes a security mechanism to provide the caller 
   with credentials of SIP intermediaries that retarget a request and 
   the final recipient’s identity through response. 
    
 
 
Yang                   Expires - November 2007              [Page 13] 
                         Retargeting Security                 May 2007 
 
 
    
    
References 
    
                     
   [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 
      Session Initiation Protocol", RFC 3261, June 2002.       
   [2] Elwell, J., "Connected Identity in the Session Initiation 
      Protocol", Internet draft, IETF, January, 2007. 
   [3] J. Rosenberg, G. Camarillo, Ed. D. Willis A Framework for 
      Consent-Based Communications in the Session Initiation Protocol 
      (SIP), Internet draft, IETF, 2007. 
   [4] J. Rosenberg, Obtaining and Using Globally Routable User Agent 
      (UA) URIs (GRUU) in the Session Initiation Protocol (SIP), IETF, 
      2007. 
   [5] J. Peterson, Retargeting and Security in SIP: A Framework and 
      Requirements, Internet draft. IETF, 2005. 
    
    
    
Acknowledgments 
    
   Thanks to Mark Duffy for providing valuable comments. 
    
    
Author's Addresses 
    
   Xu Yang 
   Sonus Networks 
   7 Technology Park Drive  
   Westford, MA 01886 
   Phone: 978-614-8205 
   Email: cxuyang@sonusnet.com 
     
    
    
    
    
    
    
    







 
 
Yang                   Expires - November 2007              [Page 14] 
                         Retargeting Security                 May 2007 
 
 
Full Copyright Statement 
    
   Copyright (C) The IETF Trust (2007). 
    
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
Intellectual Property 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights. Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org. 
     
 
Acknowledgment 
 
   Funding for the RFC Editor function is currently provided by the IETF 
   Administrative Support Activity (IASA). 




 
 
Yang                   Expires - November 2007              [Page 15]