Network Working Group M. Garcia Internet Draft Ericsson Expires: November 2002 May 2002 Private Session Initiation Protocol extension for Associated Uniform Resource Identifiers Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This memo describes a private extension to SIP [1] that allows a registrar to return a set of associated URIs to a registered address- of-record. We define the P-Associated-URI header field, used in the 200 OK response to a REGISTER request. The P-Associated-URI header field transports the set of Associated URIs to the registered address- of-record. Table of contents 1. Introduction......................................................2 2. Protocol operation................................................2 3. Applicability statement...........................................3 Network Working Group Expiration 11/30/02 [Page 1] Garcia The SIP Associated URI header May 2002 4. The Associated URI header.........................................3 5. Syntax and definition.............................................3 6. Usage.............................................................4 6.1 Procedures at the UA.............................................4 6.2 Procedures at the registrar......................................4 6.3 Procedures at the proxy..........................................5 7. Security Considerations...........................................5 8. IANA Considerations...............................................5 9. Author's Addresses................................................5 10. Acknowledgements.................................................6 11. References.......................................................6 11.1 Normative references............................................6 11.2 Informative references..........................................6 1. Introduction We consider that a user has a business relationship with a service provider. The service provider assigns one or more SIP or SIPS URIs to the user, so he can use any of this URIs to get services in the network. When the user is allocated with one or more URIs, he can distribute them according to their needs. For instance, the user may want to allocate a SIP URI for his private usage, whereas another URI is used for business purposes. From the point of view of the service provider, all these URIs are allocated to the same user. In certain situations, the user may roam from one terminal to another. In order to facilitate this roaming, it seems to be convenient that the network provides the user, once he has been authenticated, with the list of URIs allocated to him. We define a new P-Associated-URI header field, used in the 200 OK response to a REGISTER request. This header field conveys a list of URIs that the service provider has allocated to the user. 2. Protocol operation A user typically is assigned with one or more URIs. The service provider is aware of the set of URIs that a particular user is able to use. Once the user is authenticated, the service provider may want to inform the user of the set of URIs allocated to him. In this specification we introduce the concept of associated URI to an address-of-record URI. An associated URI is a URI that the service provider has allocated to a user for his own usage. A registrar contains information that allows an address-of-record URI to be associated with zero or more URIs. Usually, all these URIs (the address-of-record URI and the associated URIs) are allocated for the usage of a particular user. The extension to SIP we define in this document allows the UAC to know, upon a successful authenticated registration, which other URIs, if any, the service provider has associated to an address-of-record URI. Network Working Group Expiration 11/30/02 [Page 2] Garcia The SIP Associated URI header May 2002 Note that, generally speaking, the registrar does not register the associated URIs on behalf of the user. Only the address-of-record in the Request-URI of the REGISTER is registered and bound to the contact address. The only information conveyed is that the registrar is aware of other URIs to be used by the same user. It may be possible, however, that an application server (even the registrar itself) registers any of the associated URIs on behalf of the user by means of a third party registration. However, this third party registration is out of the scope of this document. A UAC MUST NOT consider the associated URIs to be registered. If a UAC wants to check whether any of the associated URIs is registered, it can do so by mechanisms specified outside this document, e.g., the UA may send a REGISTER request with the To header field value set to any of the associated URIs. If the associated URI is not registered, the UA MAY register it prior to its utilization. 3. Applicability statement This specification is applicable in SIP networks where the SIP provider is allocating the set of identities that a user can claim (in headers like the From field) in requests that it generates. It furthermore assumes that the provider knows the entire set of identities that a user can legitimately claim, and that the user is willing to restrict its claimed identities to that set. In normal SIP usage, the From field is explicitly an end-user specified field. 4. The Associated URI header The registrar inserts the P-Associated-URI header field into the 200 OK response to a REGISTER request. The header field value is populated with a list containing zero or more URIs that are associated to the address-of-record. If the registrar supports the P-Associated-URI header field, and there are URIs to populate in it, the registrar always inserts the P- Associated-URI header field in a 200 OK response to a REGISTER request, regardless of whether the REGISTER was an initial registration, re-registration, or de-registration and regardless of whether there are zero or more associated URIs. 5. Syntax and definition The P-Associated-URI is a SIP extension header. The syntax of the P- Associated-URI header field is based on the ABNF of SIP [1] and its syntax is described as follows: P-Associated-URI = "P-Associated-URI" HCOLON (addr-spec *(COMMA addr-spec)) Network Working Group Expiration 11/30/02 [Page 3] Garcia The SIP Associated URI header May 2002 A registrar supporting this extension MUST insert a P-Associated-URI header field into a 200 OK response for a REGISTER request. If the address-of-record in the REGISTER does not have any associated URIs, the registrar still inserts the header field, although without any value in it. Addition of P-Associated-URI to the Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [4], tables 1 and 2 in the SIP INFO method [5], tables 1 and 2 in Reliability of provisional responses in SIP [6], tables 1 and 2 in the SIP UPDATE method [7], tables 1 and 2 in the SIP extension for Instant Messaging [7] and table 1 in the SIP REFER method [8]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Associated-URI 2xx - - - - - o Header field SUB NOT PRA INF UPD MES REF _______________________________________________________________ P-Associated-URI - - - - - - - 6. Usage 6.1 Procedures at the UA A UAC may receive a P-Associated-URI header field in the 200 OK response for a REGISTER. The presence of the header field in the 200 OK response for a REGISTER request implies that the extension is supported at the registrar. The header value contains a list of zero or more associated URIs to the address-of-record URI. The UAC MAY use any of the associated URIs to populate the From header value, or any other SIP header value that provides information of the identity of the calling party, in a subsequent request. The UAC MAY check whether the associated URI is registered or not. This check can be done, e.g., by populating the To header value in a REGISTER sent to the registrar. As described in SIP [1], the 200 OK response may contain a Contact header field with zero or more values (zero meaning the address-of-record is not registered). 6.2 Procedures at the registrar A registrar that receives and authorizes a REGISTER request, may associate zero or more URIs with the address-of-record. A registrar that supports this specification MUST include a P- Associated-URI header field in the 200 OK response to a REGISTER request. Network Working Group Expiration 11/30/02 [Page 4] Garcia The SIP Associated URI header May 2002 In case the address-of-record under registration does not have any other SIP or SIPS URIs associated, the registrar MUST include an empty P-Associated-URI header value. In case the address-of-record under registration has one or more SIP or SIPS URIs associated, the registrar MUST include a comma separated list of URIs in the P-Associated-URI header value. 6.3 Procedures at the proxy This memo does not define any procedures at the proxy. 7. Security Considerations The information returned in the header value is not viewed as particularly sensitive. Rather, it is simply informational in nature, providing openness to the UAC with regard to the automatic association performed by the registrar. If end-to-end protection is not used at the SIP layer, it is possible for proxies between the registrar and the UA to modify the contents of the header value. This attack, while potentially annoying, should not have significant impacts. The lack of encryption, either end-to-end or hop-by-hop, may lead to leak some privacy regarding the list of authorized identities. For instance, a user who registers an address-of-record of sip:user1@example.com may get another SIP URI associated as sip:first.last@example.com returned in the P-Associated-URI header value. An eavesdropper could collect this information. If the user does not want to disclose the associated URIs, the eavesdropper could have gain access to private URIs. Therefore it is RECOMMENDED that this extension is used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. 8. IANA Considerations This document defines the SIP extension header field "P-Associated- URI" which should be included in the registry of SIP header fields defined in SIP [1]. As required by the SIP change process [3] the SIP extension header field name "Associated-URI" should also be registered in association with this extension. However, "Associated-URI" MUST not be used until documented by a standards-track RFC. Expert review as required for this process is to be provided by the SIP Working Group. 9. Author's Addresses Miguel A. Garcia Ericsson FIN-02420, Jorvas, Finland Tel: +358 9299 3553 e-mail: miguel.a.garcia@ericsson.com Network Working Group Expiration 11/30/02 [Page 5] Garcia The SIP Associated URI header May 2002 10. Acknowledgements The author would like to thank Andrew Allen, Gabor Bajko, Gonzalo Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Jonathan Rosenberg and the 3GPP CN1 WG members for the comments on this document. 11. References 11.1 Normative references 1. J. Rosenberg, H. S., etc, Session Initiation Protocol, RFC 3261 March 2002. 11.2 Informative references 2. M. Garcia et al, 3GPP requirements on SIP, draft-sipping-garcia- 3gpp-reqs-03.txt, work in progress. 3. S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, D. Willis, SIP change process, draft-tsvarea-sipchange-01.txt, February 2002, work in progress. 4. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. 5. S. Donovan, The SIP INFO method, RFC 2976, October 2000. 6. J. Rosenberg, H. Schulzrinne, Reliability of Provisional Responses in SIP, RFC 3262, March 2002. 7. J. Rosenberg, The Session Initiation Protocol UPDATE Method, draft-ietf-sip-update-02.txt, April 2002, work in progress. 8. B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, Session Initiation Protocol Extension for Instant Messaging, draft-ietf-sip-message-04, May 2002, work in progress. 9. Sparks, The REFER method, draft-sparks-sip-refer-split-00.txt, April 2002, work in progress. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Network Working Group Expiration 11/30/02 [Page 6] Garcia The SIP Associated URI header May 2002 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Expiration Date This memo is filed as , and expires November 30, 2002. Network Working Group Expiration 11/30/02 [Page 7]