SIPPING D. Petrie Internet-Draft SIPez LLC. Expires: April 26, 2007 M. Dolly AT&T Labs V. Hilt Bell Labs/Lucent Technologies October 23, 2006 The Session Initiation Protocol User Agent Identity Profile Data Set draft-petrie-sipping-identity-dataset-01.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 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 26, 2007 [Page 1] Internet-Draft SIP UA Data Set October 2006 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. sipIdentity Element . . . . . . . . . . . . . . . . . . . 6 3.2. aor Element . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. locationRegistration Element . . . . . . . . . . . . . . . 7 3.4. registerPeriod Element . . . . . . . . . . . . . . . . . . 7 3.5. qValue Element . . . . . . . . . . . . . . . . . . . . . . 7 3.6. sipCredential Element . . . . . . . . . . . . . . . . . . 7 3.6.1. realm Element . . . . . . . . . . . . . . . . . . . . 8 3.6.2. authUser Element . . . . . . . . . . . . . . . . . . . 8 3.6.3. a1Digest Element . . . . . . . . . . . . . . . . . . . 8 3.6.4. password Element . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. Content-type registration for 'application/uapid+xml' . . 9 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Changes from draft-petrie-sipping-identity-dataset-00 . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informational References . . . . . . . . . . . . . . . . . 11 Appendix A. SIP Identity Dataset Schema . . . . . . . . . . . . . 12 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Petrie, et al. Expires April 26, 2007 [Page 2] Internet-Draft SIP UA Data Set October 2006 1. Introduction [I-D.ietf-sipping-config-framework] defines a configuration framework for finding, retrieving and change 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: sipIdentity aor locationRegistration registerPeriod qValue sipCredential realm authUser a1Digest password 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 sipIdentity element is the container for all of the properties Petrie, et al. Expires April 26, 2007 [Page 3] Internet-Draft SIP UA Data Set October 2006 related to a specific identity or AOR. The identities defined in sipIdentity element(s) define identities for inbound or outbound SIP signaling from the user agent. The use of the data contained in the sipIdentity element is intended to be independent from the particular SIP application (e.g. VoIP, IM or presence). From a VoIP perspective, the sipIdentity is similar to a line definition. However the sipIdentity element is not intended to contain all of the VoIP or call handling feature options and properties. The sipIdentity 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 sipIdentity 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 sipIdentity element is considered to be atomic when it comes to merging. That is all sipIdentity 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 sipIdentity 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 26, 2007 [Page 4] Internet-Draft SIP UA Data Set October 2006 "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 26, 2007 [Page 5] Internet-Draft SIP UA Data Set October 2006 3.1. sipIdentity Element sipIdentity - 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 sipIdentity elements in a property_set element. The sipIdentity elements MAY appear in multiple profile (e.g. device and user). The sipIdentity element MUST contain one aor and locationRegistration element. The sipIdentity element MAY contain zero or one registerPeriod, zero or one qValue, and zero or more sipCredential elements. Contained in property_set. sipIdentity 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 sipIdentity 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 sipIdentity 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 sipIdentity 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 sipIdentity 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 sipIdentity 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 26, 2007 [Page 6] Internet-Draft SIP UA Data Set October 2006 3.2. aor Element The "aor" element is contained in the sipIdentity 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 sipIdentity element. 3.3. locationRegistration Element The "locationRegistration" 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 locationRegistration element SHOULD be contained in a sipIdentity element. 3.4. registerPeriod Element The registerPeriod 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 locationRegistration element indicates that the user agent SHOULD register. The value of the registerPeriod element SHOULD be an integer greater than 1. (Default value: 3600) Zero or one registerPeriod element MAY be contained in a sipIdentity element. 3.5. qValue Element The qValue 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 qValue element MAY be included in the sipIdentity element. The qValue element is meaningless unless the locationRegistration indicates that the user agent should register a contact. The value of the qValue element is a decimal number between 1.0 and 0.0 (the legal values for the qvalue ABNF construct in [RFC3261]) 3.6. sipCredential Element The sipCredential element contains the credentials for performing SIP [RFC3261] digest authentication related to a single realm. As it is Petrie, et al. Expires April 26, 2007 [Page 7] Internet-Draft SIP UA Data Set October 2006 possible for a user agent to be challenged from multiple realms when sending SIP requests, zero or more sipCredential elements may be contained in a sipIdentity 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 sipIdentity elements. The sipCredential element SHOULD contain exactly one of each of the elements: realm, auth-user and one of either the a1Digest or password elements. 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 sipCredential 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 authUser and a1Digest elements contained in the sipCredential element. Exactly one realm element SHOULD be contained in a sipCredential element. 3.6.2. authUser Element The authUser 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 authUser element SHOULD be contained in a sipCredential element. 3.6.3. a1Digest Element The a1Digest element contains a string with the value of the A1 digest of the username, realm and password as defined in [RFC2617]. At most one a1Digest element MUST be contained in a sipCredential element. The a1Digest element MUST NOT exist in a sipCredential element containing a password element. The username and realm used to construct the value of the a1Digest element MUST match the values of the realm and authUser elements contained in the sipCredential element with the a1Digest element. 3.6.4. password Element The password element contains the clear text password for use with DIGEST Authentication [RFC2617]. At most one password MUST be contained in a sipCredential element. The password element MUST NOT Petrie, et al. Expires April 26, 2007 [Page 8] Internet-Draft SIP UA Data Set October 2006 exist in a sipCredential element containing a a1Digest element. The user agent uses this password along with the realm and authUser elements to calculate the A1 digest used for DIGEST Authentication. 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 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 XML name space registration: urn:ietf:params:xml:ns:uaprof:id 5.1. Content-type registration for 'application/uapid+xml' To: ietf-types@iana.org Subject: Registration of MIME media type application/uapid+xml MIME media type name: application MIME subtype name: uapid+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC 3023], section 3.2. Security considerations: This content type is designed to carry SIP user agent profile data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. Interoperability considerations: This content type provides a common format for exchange of SIP user agent profile information. Published specification: RFC XXXX (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification) Applications which use this media type: SIP user agents and profile delivery servers. Petrie, et al. Expires April 26, 2007 [Page 9] Internet-Draft SIP UA Data Set October 2006 Additional information: Magic number(s): File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Daniel Petrie EMail: dan.ietf AT sipez DOT com Intended usage: LIMITED USE Author/Change controller: This specification is a proposed work item of the IETF SIPPING working group, with mailing list address: sipping@ietf.edu. Other information: This media type is a specialization of application/xml [RFC 3023], and many of the considerations described there also apply to application/uapid+xml. 6. Change History [[RFC Editor: Please remove this entire section upon publication as an RFC.]] 6.1. Changes from draft-petrie-sipping-identity-dataset-00 Converted the DTD schema to use Relax NG schema. Defined XML name space for schema: "urn:ietf:params:xml:ns:uaprof:id" Defined mime type: application/uapid+xml to be used as default content type for the configuration framework. Changed names of elements, attributes and other data types which contained "-" or "_" to use camel case. Added password element so that credential can contain either A1 digest or clear text password as the clear text password is required by the user agent in some cases to wildcard the realm. 7. References 7.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-09 (work in progress), October 2006. [I-D.petrie-sipping-profile-datasets] Petrie, D., "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets", Petrie, et al. Expires April 26, 2007 [Page 10] Internet-Draft SIP UA Data Set October 2006 draft-petrie-sipping-profile-datasets-03 (work in progress), October 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., Maler, E., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, . [W3C.REC-xml-names-19990114] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml- names-19990114, January 1999, . 7.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-03 (work in progress), March 2006. [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", Petrie, et al. Expires April 26, 2007 [Page 11] Internet-Draft SIP UA Data Set October 2006 W3C REC-xmlschema-2, May 2001, . Appendix A. SIP Identity Dataset Schema The following is the Relax NG XML schema for the SIP Identity dataset. Petrie, et al. Expires April 26, 2007 [Page 12] Internet-Draft SIP UA Data Set October 2006 both outbound inbound Petrie, et al. Expires April 26, 2007 [Page 13] Internet-Draft SIP UA Data Set October 2006 true false 25 0 1.0 Petrie, et al. Expires April 26, 2007 [Page 14] Internet-Draft SIP UA Data Set October 2006 Note: delta-seconds, name-addr, qvalue, realm-value, username-value are defined in the ABNF for SIP [RFC3261]. Appendix B. Acknowledgments Petrie, et al. Expires April 26, 2007 [Page 15] Internet-Draft SIP UA Data Set October 2006 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 26, 2007 [Page 16] Internet-Draft SIP UA Data Set October 2006 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 (2006). 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 26, 2007 [Page 17]