SIPPING D. Petrie Internet-Draft SIPez LLC. Expires: April 19, 2006 M. Dolly AT&T Labs V. Hilt Bell Labs/Lucent Technologies October 16, 2005 The Session Initiation Protocol User Agent Identity Profile Data Set draft-petrie-sipping-identity-dataset-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 April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines the properties and data format for the SIP user agent identity profile data set. The properties in this data set define identities or SIP address of records (AORs) related to incoming or outgoing SIP signaling on a user agent. The identities may be those that are registered via the SIP REGISTER method or Petrie, et al. Expires April 19, 2006 [Page 1] Internet-Draft SIP UA Data Set October 2005 identities which are provisioned on the user agent. These identities may be used or referenced when defining identity specific handling related to SIP features on the user agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SIP Identity Data Set . . . . . . . . . . . . . . . . . . . . 5 3.1. sip_identity Element . . . . . . . . . . . . . . . . . . . 6 3.2. aor Element . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. location_registration Element . . . . . . . . . . . . . . 7 3.4. register_period Element . . . . . . . . . . . . . . . . . 7 3.5. q_value Element . . . . . . . . . . . . . . . . . . . . . 7 3.6. sip_credential Element . . . . . . . . . . . . . . . . . . 7 3.6.1. realm Element . . . . . . . . . . . . . . . . . . . . 8 3.6.2. auth_user Element . . . . . . . . . . . . . . . . . . 8 3.6.3. a1_digest Element . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informational References . . . . . . . . . . . . . . . . . 10 Appendix A. SIP Identity Dataset Schema . . . . . . . . . . . . . 10 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Petrie, et al. Expires April 19, 2006 [Page 2] Internet-Draft SIP UA Data Set October 2005 1. Introduction [I-D.ietf-sipping-config-framework] defines a configuration framework for finding, retrieving and notification of profile data for SIP [RFC3261] user agents. It is intended that the identity dataset defined in this document may be contained in the user and device profiles described in the configuration framework. [I-D.petrie- sipping-profile-datasets] defines a general XML schema to contain user agent profile data. This document defines identity specific data by extending the profile data sets schema. In this document we define properties and XML schema which allow the definition of SIP identities, whether an identity should be registered with the SIP [RFC3261] REGISTER method and how. In addition credential properties related to the identities need to support SIP DIGEST authentication are defined. The information contained in the identity data set is intended to be sufficient to enable the user agent to store and/or retrieve the users' (or identities') certificates and private keys from the Credential Service as defined in [I-D.ietf-sipping-certs]. Certificate management where the certificate or private key for an identity is contained directly in a user agent profile is out of scope for this document. This document defines the properties and XML schema for the SIP user agent identity profile data set. The following XML elements are defined to contain the identity properties in this document: sip_identity aor location_registration register_period q_value sip_credential realm auth_user a1_digest 1.1. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119[RFC2119]. 2. Overview The sip_identity element is the container for all of the properties related to a specific identity or AOR. The identities defined in Petrie, et al. Expires April 19, 2006 [Page 3] Internet-Draft SIP UA Data Set October 2005 sip_identity element(s) define identities for inbound or outbound SIP signaling from the user agent. The use of the data contained in the sip_identity element is intended to be independent from the particular SIP application (e.g. VoIP, IM or presence). From a VoIP perspective, the sip_identity is similar to a line definition. However the sip_identity element is not intended to contain all of the VoIP or call handling feature options and properties. The sip_identity element has an id attribute which can be used when defining identity specific feature behavior. The definition of identity specific feature properties is out of scope of this document. The sip_identity attribute "id" is defined to enable feature properties to reference the identity(s) to which they are specific. The identity data set provides the ability to define which AORs to enable on a user agent and whether to register the AOR. It also associates SIP digest authentication credentials with the AOR that the user agent may used when challenged. [SIP] specifies that a UAS should reject incoming requests if "the Request-URI does not identify an address that the UAS is willing to accept requests for". The identity data set provides a means to define the identities for the addresses that the UAS should accept. The sip_identity element is considered to be atomic when it comes to merging. That is all sip_identity elements are taken in whole from the user and device profiles obtained via the ua-profile event package. If duplicate AORs are found the one which occurred first when looking through the device and then user profiles is used and subsequent, duplicate sip-identity elements are ignored. [need reference for AOR comparison in 3261]. User agents that support a limited number of identities use the first N unique sip_identity elements when searching through the profiles in the order described above, where N is the number of identities the user agent can support. The following excerpt of a SIP user agent profile is an example of the SIP identity data set. Petrie, et al. Expires April 19, 2006 [Page 4] Internet-Draft SIP UA Data Set October 2005 "Alice Jones"<alice@home.example.com> true 3600 home.example.com alice 670d8b81e3de71980a1f0a757c0f4273 myhomeserviceprovider.com alice.jones 9da610b04b2b76bd7c3cfae84b6f9eee "Alice Jones"<alice@work.example.com;transport=TLS> true 45 1.0 work.example.com alice 670d8b81e3de71980a1f0a757c0f4273 In the above example the user has two identities. Both of these identities may be contained in the user or device profile or one identity could be in the device profile and the other in the user profile. Both identities have an id attribute which serves as a unique label or handle for the identity. In this example case the first identity has an id of "home" the second has the id of "work". The id attribute values are only text labels and have no semantic meaning. How this particular user got two identities in their profile is a profile delivery server implementation issue and is out of scope of this document. 3. SIP Identity Data Set The XML schema defined in this document extends the root element "property_set" schema defined in [I-D.petrie-sipping-profile- datasets]. Petrie, et al. Expires April 19, 2006 [Page 5] Internet-Draft SIP UA Data Set October 2005 3.1. sip_identity Element sip_identity - This element contains properties related to a specific SIP identity or AOR. It is an XML element that extends on the XML "setting_container" element contained in the root "property_set" element. There MAY be zero or more sip_identity elements in a property_set element. The sip_identity elements MAY appear in multiple profile (e.g. device and user). The sip_identity element MUST contain one aor and location_registration element. The sip_identity element MAY contain zero or one register_period, zero or one q_value, and zero or more sip_credential elements. Contained in property_set. sip_identity has two attributes: id and default. - type string. default - indicates this is the default line to for outbound, inbound or both directions. id - is a label of type string (default value: ""). This label MAY be used by other user agent features to specify behavior that is specific to a particular identity. For example a call handling feature such as "do not disturb" might be enabled for inbound calls to a specific identity. The properties for the "do not disturb" feature could reference which identity using the string in the "id" attribute. The "id" attribute is specified in this document, but user agent feature properties which use the "id" attribute (such as "do not disturb") are out of scope of this document. default - specifies that the identity contained in this sip_identity element is to be used as the default identity (default value: ""). Possible values: "inbound", "outbound", "both". No value indicates that this identity should only be used when specifically addressed by the inbound signaling or as indicated by the user for outbound initiated signaling. A value of "inbound" means that this identity should be used for inbound signaling that does not match any of the other identities defined in other sip_identity element. A value of "inbound" also indicates that the user agent should accept incoming signaling that is not addressed to a specific identity defined in a sip_identity element. A value of "outbound" indicates that the user agent should use this identity as the default for outbound SIP signaling. A value of "both" is the equivalent of "inbound" and "outbound" There SHOULD be at most one sip_identity element with a "default" attribute of "inbound" and at most one with a value of "outbound" or one with a value of "both". If more than one sip_identity has the "default" attribute to indicate that it is the default for inbound or outbound signaling, the first occurrence is used when searching through the device and then user profiles. Petrie, et al. Expires April 19, 2006 [Page 6] Internet-Draft SIP UA Data Set October 2005 3.2. aor Element The "aor" element is contained in the sip_identity element. The aor element specifies the SIP address of record for the identity. The value of the aor element is in the form of the name-addr ABNF construct defined in SIP [RFC3261]. It is important to note that the name-addr construct may contain a display name, URI parameters and SIP message header parameters. The user agent SHOULD include these parameters when constructing a Contact header for registration (if this identity is to be registered). Exactly one aor element SHOULD be contained in a sip_identity element. 3.3. location_registration Element The "location_registration" element is used to indicate whether the user agent is to register the local Contact for this identity using the SIP [RFC3261] REGISTER method. A value of "register" indicates that the user agent SHOULD register a Contact for this identity. A value of "provisioned" indicates that the Contact is provisioned in the network and that the user agent SHOULD NOT register a Contact (Default value: "register"). Exactly one location_registration element SHOULD be contained in a sip_identity element. 3.4. register_period Element The register_period element MAY be used to indicate the Expiration header value in seconds to use in REGISTER requests for this identity. This element is ignored unless the location-registration element indicates that the user agent SHOULD register. The value of the register_period element SHOULD be an integer greater than 1. (Default value: 3600) Zero or one register_period element MAY be contained in a sip_identity element. 3.5. q_value Element The q_value element contains the value that SHOULD be used in the q field parameter of the Contact header when sending REGISTER request for this identity. Zero or one q_value element MAY be included in the sip_identity element. The q_value element is meaningless unless the location_registration indicates that the user agent should register a contact. The value of the q_value element is a decimal number between 1.0 and 0.0 (the legal values for the qvalue ABNF construct in [RFC3261]) 3.6. sip_credential Element The sip_credential element contains the credentials for performing SIP [RFC3261] digest authentication related to a single realm. As it Petrie, et al. Expires April 19, 2006 [Page 7] Internet-Draft SIP UA Data Set October 2005 is possible for a user agent to be challenged from multiple realms when sending SIP requests, zero or more sip_credential elements may be contained in a sip_identity element. The user agent SHOULD only use the credentials contained in the identity that is used for the outbound request. That is, the user agent SHOULD not use credentials contained in other sip_identity elements. The sip_credential element SHOULD contain exactly one of each of the elements: realm, auth-user, a1-digest. 3.6.1. realm Element The realm element contains the string that defines the realm to which this credential pertains. The value of the realm element is the same as the realm parameter in the [RFC2617] headers: WWW-Authenticate, Authorization and the SIP [RFC3261] headers: Proxy-Authenticate and Proxy-Authorization. When the user agent receives a authentication challenge (401 or 407 response), the user agent looks for a sip_credential element which contains a realm element that matches the realm parameter in the authorization response challenge. If a match of the realm value is found, the user agent uses the values in the auth_user and a1_digest elements contained in the sip_credential element. The exactly one realm element SHOULD be contained in a sip_credential element. 3.6.2. auth_user Element The auth_user element contains the string value of the username parameter which SHOULD be used in Authorization and Proxy- Authorization request headers when retrying a request that was challenged for authentication. Exactly one auth_user element SHOULD be contained in a sip_credential element. 3.6.3. a1_digest Element The a1_digest element contains a string with the value of the A1 digest of the username, realm and password as defined in [RFC2617]. Exactly one a1_digest element SHOULD be contained in a sip_credential element. The username and realm used to construct the value of the a1_digest element MUST match the values of the realm and auth_user elements contained in the sip_credential element with the a1_digest element. 4. Security Considerations Security is mostly a profile delivery problem. The delivery framework MUST provide a secure means of delivering the profile data as it may contain sensitive data that would be undesirable if it were Petrie, et al. Expires April 19, 2006 [Page 8] Internet-Draft SIP UA Data Set October 2005 stolen or sniffed. Storage of the profile on the profile delivery server and user agent is an implementation problem. The profile delivery server and the user agent MUST provide protection that prevents unauthorized access of the profile data. The profile delivery server and the user agent MUST enforce the access control policies defined in the profile data sets if present. 5. IANA Considerations [Need to define a namespace for the identity data set.] 6. References 6.1. Normative References [I-D.ietf-sipping-config-framework] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-07 (work in progress), July 2005. [I-D.petrie-sipping-profile-datasets] Petrie, D., "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets", draft-petrie-sipping-profile-datasets-02 (work in progress), July 2005. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC3261] 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. [W3C.REC-xml-20001006] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [W3C.REC-xml-names-19990114] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999. Petrie, et al. Expires April 19, 2006 [Page 9] Internet-Draft SIP UA Data Set October 2005 6.2. Informational References [I-D.ietf-sipping-certs] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", draft-ietf-sipping-certs-02 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [W3C.REC-xmlschema-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . Appendix A. SIP Identity Dataset Schema The following is the EBNF for the SIP Identity data set using the format defined in [XML]. Note: delta-seconds, name-addr, qvalue, realm-value, username-value are defined in the ABNF for SIP [RFC3261]. Petrie, et al. Expires April 19, 2006 [Page 10] Internet-Draft SIP UA Data Set October 2005 Appendix B. Acknowledgments Petrie, et al. Expires April 19, 2006 [Page 11] Internet-Draft SIP UA Data Set October 2005 Authors' Addresses Daniel Petrie SIPez LLC. 34 Robbins Rd. Arlington, MA 02476 US Phone: +1 617 273 4000 Email: dan.ietf AT SIPez DOT com URI: http://www.sipez.com/ Martin Dolly AT&T Labs 200 Laurel Avenue Middletowm, NJ 07748 US Phone: Email: mdolly AT att DOT com URI: Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 US Phone: Email: volkerh@bell-labs.com URI: Petrie, et al. Expires April 19, 2006 [Page 12] Internet-Draft SIP UA Data Set October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrie, et al. Expires April 19, 2006 [Page 13]