draft-ietf-sipping-trait-authz-02.txt   rfc4484.txt 
SIPPING WG J. Peterson Network Working Group J. Peterson
Internet-Draft NeuStar Request for Comments: 4484 NeuStar
Expires: August 5, 2006 J. Polk Category: Informational J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
H. Tschofenig H. Tschofenig
Siemens Siemens
February 2006 August 2006
Trait-based Authorization Requirements for the Session Initiation
Protocol (SIP)
draft-ietf-sipping-trait-authz-02
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 Trait-Based Authorization Requirements
http://www.ietf.org/ietf/1id-abstracts.txt. for the Session Initiation Protocol (SIP)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2006. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 (SIP). 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 allows greater privacy for users of an
identity system. identity system.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................4
3. Trait-based Authorization Framework . . . . . . . . . . . . . 5 3. Trait-Based Authorization Framework .............................4
4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 4. Example Use Cases ...............................................7
4.1. Settlement for Services . . . . . . . . . . . . . . . . . 8 4.1. Settlement for Services ....................................7
4.2. Associating Gateways with Providers . . . . . . . . . . . 8 4.2. Associating Gateways with Providers ........................7
4.3. Permissions on Constrained Resources . . . . . . . . . . . 9 4.3. Permissions on Constrained Resources .......................8
4.4. Managing Priority and Precedence . . . . . . . . . . . . . 10 4.4. Managing Priority and Precedence ...........................9
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. Acknowledgements ...............................................13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 8. References .....................................................13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References ......................................13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References ....................................13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
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 (SIP) [1] for enabling trait-based authorization. This
stems from the recognition that when SIP requests are received by a effort stems from the recognition that when SIP requests are received
User Agent Server (UAS), there are authorization requirements that by a User Agent Server (UAS), there are authorization requirements
are orthogonal to ascertaining of the identity of the User Agent that 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
attributes of the principal that originated a SIP request. attributes of the principal that originated a SIP request.
For example, in traditional SIP authorization architectures, the mere For example, in traditional SIP authorization architectures, the mere
fact that a UAC has been authenticated by a UAS doesn't mean that the fact that a UAC has been authenticated by a UAS doesn't mean that the
UAS will grant the UAC full access to its services or capabilities - UAS will grant the UAC full access to its services or capabilities --
in most instances, a UAS will compare the authenticated identity of in most instances, a UAS will compare the authenticated identity of
the UAC to some set of users that are permitted to make particular the UAC to some set of users that are permitted to make particular
requests (as a way of making an authorization decision). However, in requests (as a way of making an authorization decision). However, in
large communities of users with few pre-existing relationships (such large communities of users with few preexisting relationships (such
as federations of discrete service providers), it is unlikely that as federations of discrete service providers), it is unlikely that
the authenticated identity of a UAC alone will give a UAS sufficient the authenticated identity of a UAC alone will give a UAS sufficient
information to decide how to handle a given request. information to decide how to handle a given request.
Trait-based authorization entails an assertion by an authorization Trait-based authorization entails an assertion by an authorization
service of attributes associated with an identity. An assertion is a service of attributes associated with an identity. An assertion is a
sort of document consisting of a set of these attributes which are sort of document consisting of a set of these attributes that are
wrapped within a digital signature provided by the party that wrapped within a digital signature provided by the party that
generates the assertion (the operator of the authorization service). generates the assertion (the operator of the authorization service).
These attributes describe the 'trait' or 'traits' of the identity in These attributes describe the 'trait' or 'traits' of the identity in
question - facts about the principal corresponding to that identity. question -- facts about the principal corresponding to that identity.
For example, a given principal might be a faculty member at a For example, a given principal might be a faculty member at a
university. An assertion for that principal's identity might state university. An assertion for that principal's identity might state
that they have the 'trait' of 'is a faculty member', and the that they have the 'trait' of 'is a faculty member', and the
assertion would be issued (and signed) by a university. When a UAS assertion would be issued (and signed) by a university. When a UAS
receives a request with this trait assertion, if it trusts the receives a request with this trait assertion, if it trusts the
signing university, it can make an authorization decision based on signing university, it can make an authorization decision based on
whether or not faculty members are permitted to make the request in whether or not faculty members are permitted to make the request in
question, rather than just looking at the identity of the UAC and question, rather than just looking at the identity of the UAC and
trying to discern whether or not they are a faculty member through trying to discern whether or not they are a faculty member through
some external means. Thus, these assertions allow a UAS to authorize some external means. Thus, these assertions allow a UAS to authorize
a SIP request without having to store or access attributes associated a SIP request without having to store or access attributes associated
with the identity of the UAC itself. Even complex authorization with the identity of the UAC itself. Even complex authorization
decisions based the presence of multiple disjointed attributes are decisions based the presence of multiple disjointed attributes are
feasible; for example, a 'faculty' member could be part of the feasible; for example, a 'faculty' member could be part of the
'chemistry' department, and both of these traits could be used to 'chemistry' department, and both of these traits could be used to
make authorization decisions in a given federation. make authorization decisions in a given federation.
It is easy to see how traits can be used in a single administrative It is easy to see how traits can be used in a single administrative
domain, for example a single university, where all users are managed domain, for example, a single university, where all users are managed
under the same administration. In order for traits to have a broader under the same administration. In order for traits to have a broader
usage for services like SIP, which commonly are not bounded by usage for services like SIP, which commonly are not bounded by
administrative domains, domains that participate in an common administrative domains, domains that participate in a common
authorization scheme must federate with one another. The concept of authorization scheme must federate with one another. The concept of
federation is integral to any trait-based authorization scheme. federation is integral to any trait-based authorization scheme.
Domains that federate with one another agree on the syntax and Domains that federate with one another agree on the syntax and
semantics of traits - without this consensus, trait-based semantics of traits -- without this consensus, trait-based
authorization schemes would only be useful in an intradomain context. authorization schemes would only be useful in an intradomain context.
A federation is defined as a set of administrative domains that A federation is defined as a set of administrative domains that
implement common policies regarding the use and applicability of implement common policies regarding the use and applicability of
traits for authorization decisions. Federation necessarily implies a traits for authorization decisions. Federation necessarily implies a
trust relationship, and usual implies some sort of pre-shared keys or trust relationship, and usual implies some sort of pre-shared keys or
other means of cryptographic assurance that a particular assertion other means of cryptographic assurance that a particular assertion
was generated by an authorization service that participates in the was generated by an authorization service that participates in the
federation. federation.
In fact, when trait-based authorization is used, an assertion of In fact, when trait-based authorization is used, an assertion of
attributes can be presented to a UAS instead of the identity of user attributes can be presented to a UAS instead of the identity of user
of the UAC. In many cases, a UAS has no need to know who, exactly, of the UAC. In many cases, a UAS has no need to know who, exactly,
has made a request - knowing the identity is only a means to the end has made a request -- knowing the identity is only a means to the end
of matching that identity to policies that actually depend on traits of matching that identity to policies that actually depend on traits
independent of identity. This fact allows trait-based authorization independent of identity. This fact allows trait-based authorization
to offer a very compelling privacy and anonymity solution. Identity to offer a very compelling privacy and anonymity solution. Identity
becomes one more attribute of an assertion that may or may not be becomes one more attribute of an assertion that may or may not be
disclosed to various destinations. disclosed to various destinations.
Trait-based authorization for SIP depends on authorization services Trait-based authorization for SIP depends on authorization services
that are trusted by both the UAC and the UAS that wish to share a that are trusted by both the UAC and the UAS that wish to share a
session. For that reason, the authorization services described in session. For that reason, the authorization services described in
this document are most applicable to either clients in a single this document are most applicable to clients either in a single
domain, or in federated domains that have agreed to trust one domain or in federated domains that have agreed to trust one
another's authorization services. This could be common in academic another's authorization services. This could be common in academic
environments, or business partnerships that wish to share attributes environments, or business partnerships that wish to share attributes
of principals with one another. Some trait-based authorization of principals with one another. Some trait-based authorization
architectures have been proposed to provide single sign-on services architectures have been proposed to provide single sign-on services
across multiple providers. across multiple providers.
Although trait-based identity offers an alternative to traditional Although trait-based identity offers an alternative to traditional
identity architectures, this effort should be considered identity architectures, this effort should be considered
complementary to the end-to-end cryptographic SIP identity effort complementary to the end-to-end cryptographic SIP identity effort
[3]. An authentication service might also act as an authorization [3]. An authentication service might also act as an authorization
skipping to change at page 5, line 9 skipping to change at page 4, line 26
authenticated identity body. authenticated identity body.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [2] and indicate requirement levels for described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations. compliant SIP implementations.
3. Trait-based Authorization Framework 3. Trait-Based Authorization Framework
A trait-based authorization architecture entails the existence of an A trait-based authorization architecture entails the existence of an
authorization service. Devices must send requests to an authorization service. Devices must send requests to an
authorization service in order to receive an assertion that can be authorization service in order to receive an assertion that can be
used in the context of a given network request. Different network used in the context of a given network request. Different network
request types will often necessitate different or additional request types will often necessitate different or additional
attributes in assertions from the authorization service. attributes in assertions from the authorization service.
For the purposes of SIP, SIP requests might be supplied to an For the purposes of SIP, SIP requests might be supplied to an
authorization service to provide the basis for an assertion. It authorization service to provide the basis for an assertion. It
skipping to change at page 6, line 5 skipping to change at page 5, line 10
assertion within in a SIP request. It's possible that this assertion assertion within in a SIP request. It's possible that this assertion
could be provided by reference or by value. For example, a SIP UA could be provided by reference or by value. For example, a SIP UA
could include a MIME body within a SIP request that contains the could include a MIME body within a SIP request that contains the
assertion; this would be inclusion by value. Alternatively, content assertion; this would be inclusion by value. Alternatively, content
indirection [4], or some new header, could be used to provide a URI indirection [4], or some new header, could be used to provide a URI
(perhaps an HTTP URL) where interested parties could acquire the (perhaps an HTTP URL) where interested parties could acquire the
assertion; this is inclusion by reference. assertion; this is inclusion by reference.
The basic model is as follows: The basic model is as follows:
+----------------+
+----------------+ | | +----------------+ | |
| +------------+ | Request | +------------+ | | +------------+ | Request | +------------+ |
| | Entity | |------------------------>| | Assertion | | | | Entity | |------------------------>| | Assertion | |
| | requesting | | | | Granting | | | | requesting | | | | Granting | |
| | authz | |<------------------------| | Entity | | | | authz | |<------------------------| | Entity | |
| | assertions | | Assertion | +------------+ | | | assertions | | Assertion | +------------+ |
| +------------+ | | ^ | | +------------+ | | ^ |
| | | | . Trust | | | | | . Trust |
| | | | . Rel. | | | | | . Rel. |
| | | | v | | | | | v |
skipping to change at page 6, line 30 skipping to change at page 5, line 34
| | | | +------------+ | | | | | +------------+ |
| | | | | | | | | |
| v | +----------------+ | v | +----------------+
| +------------+ | Service Request + ^ | | +------------+ | Service Request + ^ |
| | Entity | | Assertion | | | | Entity | | Assertion | |
| | using authz| | -----------------------------+ | | | using authz| | -----------------------------+ |
| | assertion | | | | | assertion | | |
| +------------+ | <-------------------------------+ | +------------+ | <-------------------------------+
+----------------+ Response/Error +----------------+ Response/Error
The entity requesting authorization assertions (or the entity which The entity requesting authorization assertions (or the entity that
gets some assertions granted) and the entity using these gets some assertions granted) and the entity using these
authorization assertions might be co-located in the same host or authorization assertions might be co-located in the same host or
domain, or they might be entities in different domains that share a domain, or they might be entities in different domains that share a
federate with one another. The same is true for the entity which federate with one another. The same is true for the entity that
grants these assertions to a particular entity and the entity which grants these assertions to a particular entity and the entity that
verifies these assertions. verifies these assertions.
From a protocol point of view, it is worth noting that the process of From a protocol point of view, it is worth noting that the process of
obtaining some assertions might happen some time before the usage of obtaining some assertions might happen some time before the usage of
these assertions. Furthermore, different protocols might be used and these assertions. Furthermore, different protocols might be used and
the assertions may have a lifetime which might allow that these the assertions may have a lifetime that might allow that these
assertions are presented to the verifying entity multiple times assertions are presented to the verifying entity multiple times
(during the lifetime of the assertion). (during the lifetime of the assertion).
Some important design decisions are associated with carrying Some important design decisions are associated with carrying
assertions in a SIP request. If an assertion is carried by value, or assertions in a SIP request. If an assertion is carried by value, or
uses a MIME-based content indirection system, then proxy servers will uses a MIME-based content indirection system, then proxy servers will
be unable to inspect the assertion themselves. If the assertion were be unable to inspect the assertion themselves. If the assertion were
referenced in a header, however, it might be possible for the proxy referenced in a header, however, it might be possible for the proxy
to acquire and inspect the assertion itself. There are certainly to acquire and inspect the assertion itself. There are certainly
architectures in which it would be meaningful for proxy servers to architectures in which it would be meaningful for proxy servers to
apply admissions controls based on assertions. apply admissions controls based on assertions.
It is also the case that carrying assertions by reference allows It is also the case that carrying assertions by reference allows
versatile access controls to be applied to the assertion itself. For versatile access controls to be applied to the assertion itself. For
instance, an HTTP URL where an assertion could be acquired could instance, an HTTP URL where an assertion could be acquired could
indicate a web server that challenged requests, and only allowed indicate a web server that challenged requests, and only allowed
certain authorized sources to inspect the assertion, or which certain authorized sources to inspect the assertion, or that provided
provided different versions of the assertion depending on who is different versions of the assertion depending on who is asking. When
asking. When a SIP UA initiates a request with privacy controls [5], a SIP UA initiates a request with privacy controls [5], a web server
a web server might provide only trait information ('faculty', might provide only trait information ('faculty', 'student', or
'student', or 'staff') to most queries, but provide more detailed 'staff') to most queries, but provide more detailed information,
information, including the identity of the originator of the SIP including the identity of the originator of the SIP request, to
request, to certain privileged askers. The end-users that makes certain privileged askers. The end-users that make requests should
requests should have some way to inform authorization services of the have some way to inform authorization services of the attributes that
attributes that should be shared with particular destinations. should be shared with particular destinations.
Assertions themselves might be scoped to a particular SIP Assertions themselves might be scoped to a particular SIP transaction
transaction, SIP dialog, or possibly have a longer lifetime. The or SIP dialog, or they might have a longer lifetime. The recipient
recipient of an assertion associated with a SIP request needs to have of an assertion associated with a SIP request needs to have some way
some way to verify that the authorization service intended that this to verify that the authorization service intended that this assertion
assertion could be used for the request in question. However, the could be used for the request in question. However, the format of
format of assertions is not specified by these requirements. assertions is not specified by these requirements.
Trait assertions for responses to SIP requests are outside the scope Trait assertions for responses to SIP requests are outside the scope
of these requirements; it is not clear if there is any need for the of these requirements; it is not clear if there is any need for the
recipient of a request to provide authorization data to the recipient of a request to provide authorization data to the
requestor. requestor.
Trait-based authorization has significant applicability to SIP. Trait-based authorization has significant applicability to SIP.
There are numerous instances in which it is valuable to assert There are numerous instances in which it is valuable to assert
particular facts about a principal other than the principal's particular facts about a principal other than the principal's
identity to aid the recipient of a request in making an authorization identity to aid the recipient of a request in making an authorization
skipping to change at page 8, line 10 skipping to change at page 7, line 17
The following use cases are by no means exhaustive, but provide a few The following use cases are by no means exhaustive, but provide a few
high-level examples of the sorts of services that trait-based high-level examples of the sorts of services that trait-based
authorization might provide. All of the cases below consider authorization might provide. All of the cases below consider
interdomain usage of authorization assertions. interdomain usage of authorization assertions.
4.1. Settlement for Services 4.1. Settlement for Services
When endpoints in two domains share real-time communications When endpoints in two domains share real-time communications
services, sometimes there is a need for the domains to exchange services, sometimes there is a need for the domains to exchange
accounting and settlement information in real-time. The operators of accounting and settlement information in real-time. The operators of
valuable resources (for example, PSTN trunking, conference bridges, valuable resources (for example, Public Switched Telephone Network
or the like) in the called domain may wish to settle with the calling (PSTN) trunking, conference bridges, or the like) in the called
domain (either with the operators of the domain, or a particular domain may wish to settle with the calling domain (either with the
user), and some accounting operations might need to complete before a operators of the domain or a particular user), and some accounting
call is terminated. For example, a caller in one domain might want operations might need to complete before a call is terminated. For
to access a conference bridge in another domain, and the called example, a caller in one domain might want to access a conference
domain might wish to settle for the usage of the bridge with the bridge in another domain, and the called domain might wish to settle
calling domain. Or in a wireless context, a roaming user might want for the usage of the bridge with the calling domain. Or in a
to use services in a visited network, and the visited network might wireless context, a roaming user might want to use services in a
need to understand how to settle with the user's home network for visited network, and the visited network might need to understand how
these services. to settle with the user's home network for these services.
Assuming that the calling domain constitutes some sort of commercial Assuming that the calling domain constitutes some sort of commercial
service capable of exchanging accounting information, the called service capable of exchanging accounting information, the called
domain may want to verify that the remote user has a billable account domain may want to verify that the remote user has a billable account
in good standing before allowing a remote user access to valuable in good standing before allowing a remote user access to valuable
resources. Moreover, the called domain may need to discover the resources. Moreover, the called domain may need to discover the
network address of an accounting server and some basic information network address of an accounting server and some basic information
about how to settle with it. about how to settle with it.
An authorization assertion created by the calling domain could An authorization assertion created by the calling domain could
skipping to change at page 8, line 48 skipping to change at page 8, line 6
4.2. Associating Gateways with Providers 4.2. Associating Gateways with Providers
Imagine a case where a particular telephone service provider has Imagine a case where a particular telephone service provider has
deployed numerous PSTN-SIP gateways. When calls come in from the deployed numerous PSTN-SIP gateways. When calls come in from the
PSTN, they are eventually proxied to various SIP user agents. Each PSTN, they are eventually proxied to various SIP user agents. Each
SIP user agent server is interested to know the identity of the PSTN SIP user agent server is interested to know the identity of the PSTN
caller, of course, which could be given within SIP messages in any caller, of course, which could be given within SIP messages in any
number of ways (in SIP headers, bodies, or what have you). However, number of ways (in SIP headers, bodies, or what have you). However,
in order for the recipient to be able to trust the identity (in this in order for the recipient to be able to trust the identity (in this
instance, the calling party's telephone number) stated in the call, instance, the calling party's telephone number) stated in the call,
they must first trust that the call originated from the gateway, and they must first trust that the call originated from the gateway and
that the gateway is operated by a known (and trusted) provider. that the gateway is operated by a known (and trusted) provider.
There are a number of ways that a service provider might try to There are a number of ways that a service provider might try to
address this problem. One possibility would be routing all calls address this problem. One possibility would be routing all calls
from gateways through a recognizable 'edge' proxy server (say, from gateways through a recognizable 'edge' proxy server (say,
'sip.example.com'). Accordingly, any SIP entity that received a 'sip.example.com'). Accordingly, any SIP entity that received a
request via the edge proxy server (assuming the use of hop-by-hop request via the edge proxy server (assuming the use of hop-by-hop
mutual cryptographic authentication) would know the service provider mutual cryptographic authentication) would know the service provider
from whom the call originated. However, it is possible that requests from whom the call originated. However, it is possible that requests
from the originating service provider's edge proxy might be proxied from the originating service provider's edge proxy might be proxied
skipping to change at page 9, line 22 skipping to change at page 8, line 29
only transitively. Moreover, in many architectures requests that did only transitively. Moreover, in many architectures requests that did
not originate from PSTN gateways could be sent through the edge proxy not originate from PSTN gateways could be sent through the edge proxy
server. In the end analysis, the recipient of the request is less server. In the end analysis, the recipient of the request is less
interested in knowing which carrier the request came from than in interested in knowing which carrier the request came from than in
knowing that the request came from a gateway. knowing that the request came from a gateway.
Another possible solution is to issue certificates to every gateway Another possible solution is to issue certificates to every gateway
corresponding to the hostname of the gateway corresponding to the hostname of the gateway
('gateway1.example.com'). Gateways could therefore sign SIP requests ('gateway1.example.com'). Gateways could therefore sign SIP requests
directly, and this property could be preserved end-to-end. But directly, and this property could be preserved end-to-end. But
depending on the public key infrastructure, this could however become depending on the public key infrastructure, this could, however,
costly for large numbers of gateways, and moreover a user agent become costly for large numbers of gateways, and moreover a user
server that receives the request has no direct assurance from a agent server that receives the request has no direct assurance from a
typical certificate that the host is in fact a gateway just because typical certificate that the host is in fact a gateway just because
it happens to be named 'gateway1'. it happens to be named 'gateway1'.
Trait-based authorization would enable the trait 'is a gateway' to be Trait-based authorization would enable the trait 'is a gateway' to be
associated with an assertion that is generated by the service associated with an assertion that is generated by the service
provider (i.e. signed by 'example.com'). Since these assertions provider (i.e., signed by 'example.com'). Since these assertions
would travel end-to-end from the originating service provider to the would travel end-to-end from the originating service provider to the
destination user agent server, SIP requests which carry them can pass destination user agent server, SIP requests that carry them can pass
through any number of intermediaries without discarding cryptographic through any number of intermediaries without discarding cryptographic
authentication information. This mechanism also does not rely on authentication information. This mechanism also does not rely on
hostname conventions to identity what constitutes a gateway and what hostname conventions to identify what constitutes a gateway and what
does not - it relies on an explicit and unambiguous attribute in an does not -- it relies on an explicit and unambiguous attribute in an
assertion. assertion.
4.3. Permissions on Constrained Resources 4.3. Permissions on Constrained Resources
Consider a scenario wherein two universities are making use of a Consider a scenario wherein two universities are making use of a
videoconferencing service over a constrained bandwidth resource. videoconferencing service over a constrained-bandwidth resource.
Both universities would like to enforce policies that determine how Both universities would like to enforce policies that determine how
this constrained bandwidth will be allocated to members of their this constrained bandwidth will be allocated to members of their
respective communities. For example, faculty members might have respective communities. For example, faculty members might have
privileges to establish videoconferences during the day, while privileges to establish videoconferences during the day, while
students might not. Faculty might also be able to add students to a students might not. Faculty might also be able to add students to a
particular videoconference dynamically, or otherwise moderate the particular videoconference dynamically, or otherwise moderate the
content or attendance of the conference, whereas students might content or attendance of the conference, whereas students might
participate only more passively. participate only more passively.
Trait-based authorization is ideal for managing authorization Trait-based authorization is ideal for managing authorization
skipping to change at page 11, line 5 skipping to change at page 10, line 14
priority assessment. If the assertion's creator is trusted by the priority assessment. If the assertion's creator is trusted by the
evaluator, the given priority could be factored into any relevant evaluator, the given priority could be factored into any relevant
request processing. request processing.
4.5. Linking Different Protocols 4.5. Linking Different Protocols
Cryptographic computations are expensive and computing authorization Cryptographic computations are expensive and computing authorization
decisions might require a lot of time and multiple messages between decisions might require a lot of time and multiple messages between
the entity enforcing the decisions and the entity computing the the entity enforcing the decisions and the entity computing the
authorization decision. Particularly in a mobile environment these authorization decision. Particularly in a mobile environment these
entities are physically separated - or not even in the same entities are physically separated -- or not even in the same
administrative domain. Accordingly, the notion of "single sign-on" administrative domain. Accordingly, the notion of "single sign-on"
is another potential application of authorization assertions, and is another potential application of authorization assertions and
trait-based authorization - a user is authenticated and authorized trait-based authorization -- a user is authenticated and authorized
through one protocol, and can reuse the resulting authorization through one protocol, and can reuse the resulting authorization
assertion in other, potential unrelated protocol exchanges. assertion in other, potential unrelated protocol exchanges.
For example, in some environments it is useful to make the For example, in some environments it is useful to make the
authorization decision for a "high-level" service (such a voice authorization decision for a "high-level" service (such as a voice
call). The authorization for the "voice call" itself might include call). The authorization for the "voice call" itself might include
authorization for SIP signaling and also for lower level network authorization for SIP signaling and also for lower-level network
functions, for example a quality-of-service (QoS) reservation to functions, for example, a quality-of-service (QoS) reservation to
improve the performance of real-time media sessions established by improve the performance of real-time media sessions established by
SIP. Since the SIP signaling protocol and the QoS reservation SIP. Since the SIP signaling protocol and the QoS reservation
protocol are totally separate, it is necessary to link the protocol are totally separate, it is necessary to link the
authorization decisions of the two protocols. The authorization authorization decisions of the two protocols. The authorization
decision might be valid for a number of different protocol exchanges, decision might be valid for a number of different protocol exchanges,
for different protocols and for a certain duration or some other for different protocols and for a certain duration or some other
attributes. attributes.
To enable this mechanism as part of the initial authorization step an To enable this mechanism as part of the initial authorization step,
authorization assertion is returned to the end host of the SIP UAC an authorization assertion is returned to the end host of the SIP UAC
(cryptographically protected). If QoS is necessary, the end host (cryptographically protected). If QoS is necessary, the end host
might reuse the returned assertion in the QoS signaling protocol. might reuse the returned assertion in the QoS signaling protocol.
Any domains in the federation that would honor the assertion Any domains in the federation that would honor the assertion
generated to authorize the SIP signaling would similar honor the use generated to authorize the SIP signaling would similarly honor the
of the assertion in the context of QoS. Upon the initial generation use of the assertion in the context of QoS. Upon the initial
of the assertion by an authorization server, traits could be added generation of the assertion by an authorization server, traits could
that specify the desire level of quality that should be granted to be added that specify the desired level of quality that should be
the media associated with a SIP session. granted to 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
UAC of the need to do so. 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.
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 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 authorization assertion scheme. The mechanism MUST 7. The mechanism MUST have a single baseline mandatory-to-implement
also allow support of other assertion schemes, which would be authorization assertion scheme. The mechanism MUST also allow
optional to implement. One example of an assertion scheme is support of other assertion schemes, which would be optional to
SAML [6]. 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 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 per-
message, per-transaction, or per-dialog basis. 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
of a given principal to particular recipients, based on the 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
request that lacks a present and valid authorization assertion, 15. It MUST be possible for a UAS or proxy server to reject a request
and to inform the sending UAC that it must acquire such an that lacks a present and valid authorization assertion, and to
assertion in order to complete the request. 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 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
request containing an assertion that does not provide any containing an assertion that does not provide any attributes or
attributes or traits that are known to the recipient, or that traits that are known to the recipient or that are relevant to
are relevant to the request in question. 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
document discusses security. document discusses security.
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. Acknowledgements
This document introduces no considerations for the IANA.
Appendix A. Acknowledgments
The authors thank Christopher Eagan for his valuable input. The authors thank Christopher Eagan and Mary Barnes for their
valuable input.
8. References 8. References
8.1. Normative 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, June 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", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip- identity-06 (work in progress), October 2005. RFC 4474, August 2006.
[4] Burger, E., "A Mechanism for Content Indirection in SIP [4] Burger, E., Ed., "A Mechanism for Content Indirection in Session
Messages", draft-ietf-sip-content-indirect-mech-05 (work in Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
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", Standards, "Security Assertion Markup Language v1.0", November
November 2002, <http://www.oasis-open.org>. 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 Authors' Addresses
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Phone: +1 925/363-8720 Phone: +1 925/363-8720
Email: jon.peterson@neustar.biz EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/ URI: http://www.neustar.biz/
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Suite 570 Suite 570
Richardson, TX 75802 Richardson, TX 75802
US US
Email: jmpolk@cisco.com EMail: jmpolk@cisco.com
Douglas C. Sicker Douglas C. Sicker
University of Colorado at Boulder University of Colorado at Boulder
ECOT 531 ECOT 531
Boulder, CO 80309 Boulder, CO 80309
US US
Email: douglas.sicker@colorado.edu EMail: douglas.sicker@colorado.edu
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich 81739 Munich 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 15, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity 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 (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 Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 70 change blocks. 
186 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/