One document matched: draft-petrie-sipping-identity-dataset-00.txt
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
<sip_identity id="home">
<aor>"Alice Jones"<alice@home.example.com></aor>
<location_registration>true</location_registration>
<register_period>3600</register_period>
<sip_credential>
<realm>home.example.com</realm>
<auth_user>alice</auth-user>
<a1_digest>670d8b81e3de71980a1f0a757c0f4273</a1_digest>
</sip_credential>
<sip_credential>
<realm>myhomeserviceprovider.com</realm>
<auth_user>alice.jones</auth_user>
<a1_digest>9da610b04b2b76bd7c3cfae84b6f9eee</a1_digest>
</sip_credential>
</sip_identity>
<sip_identity id="work" default="outbound">
<aor>
"Alice Jones"<alice@work.example.com;transport=TLS>
</aor>
<location_registration>true</should-register>
<register_period>45</register_period>
<q_value>1.0</q_value>
<sip_credential>
<realm>work.example.com</realm>
<auth_user>alice</auth_user>
<a1_digest>670d8b81e3de71980a1f0a757c0f4273</a1_digest>
</sip_credential>
</sip_identity>
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, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.REC-xmlschema-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, May 2001,
<http://www.w3.org/TR/xmlschema-2/>.
Appendix A. SIP Identity Dataset Schema
The following is the EBNF for the SIP Identity data set using the
format defined in [XML].
<!ELEMENT sip_identity (aor, location_registration, register_period?,
q_value?, sip_credential*) >
<!ELEMENT aor (name-addr) >
<!ELEMENT location_registration ("provision" |
"register" | #PCDATA) >
<!ELEMENT register_period (delta-seconds) >
<!ELEMENT q_value (qvalue) >
<!ELEMENT sip_credential (realm, auth_user, a1_digest) >
<!ELEMENT realm (realm-value) >
<!ELEMENT auth_user (username-value) >
<!ELEMENT a1_digest (A1) >
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]
| PAFTECH AB 2003-2026 | 2026-04-21 18:38:48 |