draft-ietf-sipping-trait-authz-00.txt   draft-ietf-sipping-trait-authz-01.txt 
SIPPING WG J. Peterson SIPPING WG J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Expires: August 7, 2004 J. Polk Expires: August 17, 2005 J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
H. Tschofenig H. Tschofenig
Siemens Siemens
February 7, 2004 February 16, 2005
Trait-based Authorization Requirements for the Session Initiation Trait-based Authorization Requirements for the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-trait-authz-00 draft-ietf-sipping-trait-authz-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 7, 2004. This Internet-Draft will expire on August 17, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document lays out a set of requirements related to trait-based This document lays out a set of requirements related to trait-based
authorization for the Session Initiation Protocol. While some authorization for the Session Initiation Protocol. While some
authentication mechanisms are described in the base SIP authentication mechanisms are described in the base SIP
specification, trait-based authorization provides information used to specification, trait-based authorization provides information used to
make policy decisions based on the attributes of a participant in a make policy decisions based on the attributes of a participant in a
session. This approach provides a richer framework for session. This approach provides a richer framework for
authorization, as well as allow greater privacy for users of an authorization, as well as allow greater privacy for users of an
identity system. identity system.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trait-based Authorization Framework . . . . . . . . . . . . . 5 3. Trait-based Authorization Framework . . . . . . . . . . . . . 5
4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Settlement for Services . . . . . . . . . . . . . . . . . . . 7 4.1 Settlement for Services . . . . . . . . . . . . . . . . . 7
4.2 Associating Gateways with Providers . . . . . . . . . . . . . 8 4.2 Associating Gateways with Providers . . . . . . . . . . . 8
4.3 Permissions on Constrained Resources . . . . . . . . . . . . . 9 4.3 Permissions on Constrained Resources . . . . . . . . . . . 9
4.4 Managing Priority and Precedence . . . . . . . . . . . . . . . 10 4.4 Managing Priority and Precedence . . . . . . . . . . . . . 10
4.5 Linking Different Protocols . . . . . . . . . . . . . . . . . 10 4.5 Linking Different Protocols . . . . . . . . . . . . . . . 10
5. Trait-based Authorization Requirements . . . . . . . . . . . . 11 5. Trait-based Authorization Requirements . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . . 13
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
This document explores requirements of the Session Initiation This document explores requirements of the Session Initiation
Protocol [1] for enabling trait-based authorization. This effort Protocol [1] for enabling trait-based authorization. This effort
stems from the recognition that when SIP requests are received by a stems from the recognition that when SIP requests are received by a
User Agent Server (UAS), there are authorization requirements that User Agent Server (UAS), there are authorization requirements that
are orthogonal to ascertaining of the identity of the User Agent are orthogonal to ascertaining of the identity of the User Agent
Client (UAC). Supplemental authorization information might allow the Client (UAC). Supplemental authorization information might allow the
UAS to implement non-identity-based policies that depend on further UAS to implement non-identity-based policies that depend on further
skipping to change at page 11, line 37 skipping to change at page 11, line 37
generated to authorize the SIP signaling would similar honor the use generated to authorize the SIP signaling would similar honor the use
of the assertion in the context of QoS. Upon the initial generation of the assertion in the context of QoS. Upon the initial generation
of the assertion by an authorization server, traits could be added of the assertion by an authorization server, traits could be added
that specify the desire level of quality that should be granted to that specify the desire level of quality that should be granted to
the media associated with a SIP session. the media associated with a SIP session.
5. Trait-based Authorization Requirements 5. Trait-based Authorization Requirements
The following are the constraints and requirements for trait-based The following are the constraints and requirements for trait-based
authorization in SIP: authorization in SIP:
1. The mechanism MUST support a way for SIP user agents to embed an 1. The mechanism MUST support a way for SIP user agents to embed an
authorization assertion in SIP requests. Assertions can be authorization assertion in SIP requests. Assertions can be
carried either by reference or by value. carried either by reference or by value.
2. The mechanism MUST allow SIP UACs to deliver to an authorization 2. The mechanism MUST allow SIP UACs to deliver to an authorization
service those SIP requests that need to carry an assertion. The service those SIP requests that need to carry an assertion. The
mechanism SHOULD also provide a way for SIP intermediaries to mechanism SHOULD also provide a way for SIP intermediaries to
recognize that an assertion will be needed, and either forward recognize that an assertion will be needed, and either forward
requests to an authorization service themselves, or notify the requests to an authorization service themselves, or notify the
UAC of the need to do so. UAC of the need to do so.
3. Authorization services MUST be capable of delivering an assertion
to a SIP UAC, either by reference or by value. It MAY also be
possible for an authorization service to add assertions to
requests itself, if the user profile permits this (for example,
through the use of content-indirection as described in [4]).
3. Authorization services MUST be capable of delivering an 4. Authorization services MUST have a way to authenticate a SIP UAC.
assertion to a SIP UAC, either by reference or by value. It MAY
also be possible for an authorization service to add assertions
to requests itself, if the user profile permits this (for
example, through the use of content-indirection as described in
[4]).
4. Authorization services MUST have a way to authenticate a SIP
UAC.
5. The assertions generated by authorization services MUST be 5. The assertions generated by authorization services MUST be
capable of providing a set of values for a particular trait that capable of providing a set of values for a particular trait that
a principal is entitled to claim. a principal is entitled to claim.
6. The mechanism MUST provide a way for authorized SIP 6. The mechanism MUST provide a way for authorized SIP
intermediaries (e.g. authorized proxy servers) to inspect intermediaries (e.g. authorized proxy servers) to inspect
assertions. assertions.
7. The mechanism MUST have a single baseline mandatory-to- implement
7. The mechanism MUST have a single baseline mandatory-to- authorization assertion scheme. The mechanism MUST also allow
implement authorization assertion scheme. The mechanism MUST support of other assertion schemes, which would be optional to
also allow support of other assertion schemes, which would be implement. One example of an assertion scheme is SAML [6].
optional to implement. One example of an assertion scheme is
SAML [6].
8. The mechanism MUST ensure reference integrity between a SIP 8. The mechanism MUST ensure reference integrity between a SIP
request and assertion. Reference integrity refers to the request and assertion. Reference integrity refers to the
relationship between a SIP message and the assertion authorizing relationship between a SIP message and the assertion authorizing
the message. For example, a reference integrity check would the message. For example, a reference integrity check would
compare the sender of the message (as expressed in the SIP compare the sender of the message (as expressed in the SIP
request, for example in the "From" header field value) with the request, for example in the "From" header field value) with the
identity provided by the assertion. Reference integrity is identity provided by the assertion. Reference integrity is
necessary to prevent various sorts of relay and impersonation necessary to prevent various sorts of relay and impersonation
attacks. Note that reference integrity MAY apply on a per- attacks. Note that reference integrity MAY apply on a
message, per-transaction, or per-dialog basis. per-message, per-transaction, or per-dialog basis.
9. Assertion schemes used for this mechanism MUST be capable of 9. Assertion schemes used for this mechanism MUST be capable of
asserting attributes and/or traits associated with the identity asserting attributes and/or traits associated with the identity
of the principal originating a SIP request. No specific traits of the principal originating a SIP request. No specific traits
or attributes are required by this specification. or attributes are required by this specification.
10. The mechanism MUST support a means for end-users to specify 10. The mechanism MUST support a means for end-users to specify
policies to an authorization service for the distribution of policies to an authorization service for the distribution of
their traits and/or attributes to various destinations. their traits and/or attributes to various destinations.
11. The mechanism MUST provide a way of preventing unauthorized 11. The mechanism MUST provide a way of preventing unauthorized
parties (either intermediaries or endpoints) from viewing the parties (either intermediaries or endpoints) from viewing the
contents of assertions. contents of assertions.
12. Assertion schemes MUST provide a way of selectively sharing the 12. Assertion schemes MUST provide a way of selectively sharing the
traits and/or attributes of the principal in question. In other traits and/or attributes of the principal in question. In other
words, it must be possible to show only some of the attributes words, it must be possible to show only some of the attributes
of a given principal to particular recipients, based on the of a given principal to particular recipients, based on the
cryptographically- assured identity of the recipient. cryptographically- assured identity of the recipient.
13. It MUST be possible to provide an assertion that contains no 13. It MUST be possible to provide an assertion that contains no
identity - that is, to present only attributes or traits of the identity - that is, to present only attributes or traits of the
principal making a request, rather than the identity of the principal making a request, rather than the identity of the
principal. principal.
14. The manner in which an assertion is distributed MUST permit 14. The manner in which an assertion is distributed MUST permit
cryptographic authentication and integrity properties to be cryptographic authentication and integrity properties to be
applied to the assertion by the authorization service. applied to the assertion by the authorization service.
15. It MUST be possible for a UAS or proxy server to reject a 15. It MUST be possible for a UAS or proxy server to reject a
request that lacks a present and valid authorization assertion, request that lacks a present and valid authorization assertion,
and to inform the sending UAC that it must acquire such an and to inform the sending UAC that it must acquire such an
assertion in order to complete the request. assertion in order to complete the request.
16. The recipient of a request containing an assertion MUST be able 16. The recipient of a request containing an assertion MUST be able
to ascertain which authorization service generated the to ascertain which authorization service generated the
assertion. assertion.
17. It MUST be possible for a UAS or proxy server to reject a 17. It MUST be possible for a UAS or proxy server to reject a
request containing an assertion that does not provide any request containing an assertion that does not provide any
attributes or traits that are known to the recipient, or that attributes or traits that are known to the recipient, or that
are relevant to the request in question. are relevant to the request in question.
18. It SHOULD be possible for a UAC to attach multiple assertions to 18. It SHOULD be possible for a UAC to attach multiple assertions to
a single SIP request, in cases where multiple authorization a single SIP request, in cases where multiple authorization
services must provide assertions in order for a request to services must provide assertions in order for a request to
complete. complete.
6. Security Considerations 6. Security Considerations
The subject of this document is an authorization system for SIP that The subject of this document is an authorization system for SIP that
is not predicated on the distribution of end-users' identities, but is not predicated on the distribution of end-users' identities, but
rather shares traits of the users. As such, the bulk of this rather shares traits of the users. As such, the bulk of this
skipping to change at page 14, line 5 skipping to change at page 13, line 34
The distribution of authorization assertions requires numerous The distribution of authorization assertions requires numerous
security properties. An authorization service must be able to sign security properties. An authorization service must be able to sign
assertions, or provide some similar cryptographic assurance that can assertions, or provide some similar cryptographic assurance that can
provide non-repudiation for assertions. These requirements are provide non-repudiation for assertions. These requirements are
further detailed in Section 3. further detailed in Section 3.
7. IANA Considerations 7. IANA Considerations
This document introduces no considerations for the IANA. This document introduces no considerations for the IANA.
Normative References 8. References
8.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement [2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
Informative References 8.2 Informative References
[3] Peterson, J., "Enhancements for Authenticated Identity [3] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft- Management in the Session Initiation Protocol (SIP)",
ietf-sip-peterson-identity-01 (work in progress), July 2002. draft-ietf-sip-peterson-identity-04 (work in progress), February
2005.
[4] Olson, S., "A Mechanism for Content Indirection in SIP [4] Burger, E., "A Mechanism for Content Indirection in SIP
Messages", draft-ietf-sip-content-indirect-mech-03 (work in Messages", draft-ietf-sip-content-indirect-mech-05 (work in
progress), June 2003. progress), October 2004.
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation [5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[6] Organization for the Advancement of Structured Industry [6] Organization for the Advancement of Structured Industry
Standards, "Security Assertion Markup Language v1.0", November Standards, "Security Assertion Markup Language v1.0", November
2002, <http://www.oasis-open.org>. 2002, <http://www.oasis-open.org>.
Authors' Addresses Authors' Addresses
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich 81739 Munich 81739
Germany Germany
EMail: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors thank Christopher Eagan for his valuable input. The authors thank Christopher Eagan for his valuable input.
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use of
and distributed, in whole or in part, without restriction of any such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph are specification can be obtained from the IETF on-line IPR repository at
included on all such copies and derivative works. However, this http://www.ietf.org/ipr.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
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 The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. 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.
This document and the information contained herein is provided on an Disclaimer of Validity
"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.
Acknowledgement 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 Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/