evaluator, the given priority could be factored into any relevant
request processing.
4.5. Linking Different Protocols
Cryptographic computations are expensive and computing authorization
decisions might require a lot of time and multiple messages between
the entity enforcing the decisions and the entity computing the
authorization decision. Particularly in a mobile environment these
entities are physically separated -- or not even in the same
administrative domain. Accordingly, the notion of "single sign-on"
is another potential application of authorization assertions and
trait-based authorization -- a user is authenticated and authorized
through one protocol, and can reuse the resulting authorization
assertion in other, potential unrelated protocol exchanges.
For example, in some environments it is useful to make the
authorization decision for a "high-level" service (such as a voice
call). The authorization for the "voice call" itself might include
authorization for SIP signaling and also for lower-level network
functions, for example, a quality-of-service (QoS) reservation to
improve the performance of real-time media sessions established by
SIP. Since the SIP signaling protocol and the QoS reservation
protocol are totally separate, it is necessary to link the
authorization decisions of the two protocols. The authorization
decision might be valid for a number of different protocol exchanges,
for different protocols and for a certain duration or some other
attributes.
To enable this mechanism as part of the initial authorization step,
an authorization assertion is returned to the end host of the SIP UAC
(cryptographically protected). If QoS is necessary, the end host
might reuse the returned assertion in the QoS signaling protocol.
Any domains in the federation that would honor the assertion
generated to authorize the SIP signaling would similarly honor the
use of the assertion in the context of QoS. Upon the initial
generation of the assertion by an authorization server, traits could
be added that specify the desired level of quality that should be
granted to the media associated with a SIP session.
5. Trait-Based Authorization Requirements
The following are the constraints and requirements for trait-based
authorization in SIP:
1. The mechanism MUST support a way for SIP user agents to embed an
authorization assertion in SIP requests. Assertions can be
carried either by reference or by value.
2. The mechanism MUST allow SIP UACs to deliver to an authorization
service those SIP requests that need to carry an assertion. The
mechanism SHOULD also provide a way for SIP intermediaries to
recognize that an assertion will be needed, and either forward
requests to an authorization service themselves or notify the 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]).
4. Authorization services MUST have a way to authenticate a SIP UAC.
5. The assertions generated by authorization services MUST be
capable of providing a set of values for a particular trait that
a principal is entitled to claim.
6. The mechanism MUST provide a way for authorized SIP
intermediaries (e.g., authorized proxy servers) to inspect
assertions.
7. The mechanism MUST have a single baseline mandatory-to-implement
authorization assertion scheme. The mechanism MUST also allow
support of other assertion schemes, which would be optional to
implement. One example of an assertion scheme is Security
Assertion Markup Language (SAML) [6] and another is RFC 3281
X.509 Attribute Certificates [7].
8. The mechanism MUST ensure reference integrity between a SIP
request and assertion. Reference integrity refers to the
relationship between a SIP message and the assertion authorizing
the message. For example, a reference integrity check would
compare the sender of the message (as expressed in the SIP
request, for example, in the "From" header field value) with the
identity provided by the assertion. Reference integrity is
necessary to prevent various sorts of relay and impersonation
attacks. Note that reference integrity MAY apply on a per-
message, per-transaction, or per-dialog basis.
9. Assertion schemes used for this mechanism MUST be capable of
asserting attributes and/or traits associated with the identity
of the principal originating a SIP request. No specific traits
or attributes are required by this specification.
10. The mechanism MUST support a means for end-users to specify
policies to an authorization service for the distribution of
their traits and/or attributes to various destinations.
11. The mechanism MUST provide a way of preventing unauthorized
parties (either intermediaries or endpoints) from viewing the
contents of assertions.
12. Assertion schemes MUST provide a way of selectively sharing the
traits and/or attributes of the principal in question. In other
words, it must be possible to show only some of the attributes of
a given principal to particular recipients, based on the
cryptographically- assured identity of the recipient.
13. It MUST be possible to provide an assertion that contains no
identity -- that is, to present only attributes or traits of the
principal making a request, rather than the identity of the
principal.
14. The manner in which an assertion is distributed MUST permit
cryptographic authentication and integrity properties to be
applied to the assertion by the authorization service.
15. It MUST be possible for a UAS or proxy server to reject a request
that lacks a present and valid authorization assertion, and to
inform the sending UAC that it must acquire such an assertion in
order to complete the request.
16. The recipient of a request containing an assertion MUST be able
to ascertain which authorization service generated the assertion.
17. It MUST be possible for a UAS or proxy server to reject a request
containing an assertion that does not provide any attributes or
traits that are known to the recipient or that are relevant to
the request in question.
18. It SHOULD be possible for a UAC to attach multiple assertions to
a single SIP request, in cases where multiple authorization
services must provide assertions in order for a request to
complete.
6. Security Considerations
The subject of this document is an authorization system for SIP that
is not predicated on the distribution of end-users’ identities, but
rather shares traits of the users. As such, the bulk of this
document discusses security.
The distribution of authorization assertions requires numerous
security properties. An authorization service must be able to sign
assertions, or provide some similar cryptographic assurance that can
provide non-repudiation for assertions. These requirements are
further detailed in Section 3.
7. Acknowledgements
The authors thank Christopher Eagan and Mary Barnes for their
valuable input.
8. References
8.1. Normative References
[1] 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.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[4] Burger, E., Ed., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[6] Organization for the Advancement of Structured Industry
Standards, "Security Assertion Markup Language v1.0", November
2002, <http://www.oasis-open.org>.
[7] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
Authors’ Addresses
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Suite 570
Richardson, TX 75802
US
EMail: jmpolk@cisco.com
Douglas C. Sicker
University of Colorado at Boulder
ECOT 531
Boulder, CO 80309
US
EMail: douglas.sicker@colorado.edu
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Full 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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).