Network Working Group J. Peterson Request for Comments: 4484 NeuStar Category: Informational J. Polk Cisco D. Sicker CU Boulder H. Tschofenig Siemens August 2006 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) Status of This Memo 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 (C) The Internet Society (2006).
AbstractThis document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.
1. Introduction ....................................................2 2. Terminology .....................................................4 3. Trait-Based Authorization Framework .............................4 4. Example Use Cases ...............................................7 4.1. Settlement for Services ....................................7 4.2. Associating Gateways with Providers ........................7 4.3. Permissions on Constrained Resources .......................8 4.4. Managing Priority and Precedence ...........................9 4.5. Linking Different Protocols ...............................10 5. Trait-Based Authorization Requirements .........................11 6. Security Considerations ........................................13 7. Acknowledgements ...............................................13 8. References .....................................................13 8.1. Normative References ......................................13 8.2. Informative References ....................................13 1] for enabling trait-based authorization. This effort stems from the recognition that when SIP requests are received by a User Agent Server (UAS), there are authorization requirements that are orthogonal to ascertaining of the identity of the User Agent Client (UAC). Supplemental authorization information might allow the UAS to implement non-identity-based policies that depend on further attributes of the principal that originated a SIP request. For example, in traditional SIP authorization architectures, the mere 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 -- in most instances, a UAS will compare the authenticated identity of the UAC to some set of users that are permitted to make particular requests (as a way of making an authorization decision). However, in large communities of users with few preexisting relationships (such as federations of discrete service providers), it is unlikely that the authenticated identity of a UAC alone will give a UAS sufficient information to decide how to handle a given request. Trait-based authorization entails an assertion by an authorization service of attributes associated with an identity. An assertion is a sort of document consisting of a set of these attributes that are wrapped within a digital signature provided by the party that generates the assertion (the operator of the authorization service). These attributes describe the 'trait' or 'traits' of the identity in question -- facts about the principal corresponding to that identity. For example, a given principal might be a faculty member at a
university. An assertion for that principal's identity might state that they have the 'trait' of 'is a faculty member', and the assertion would be issued (and signed) by a university. When a UAS receives a request with this trait assertion, if it trusts the signing university, it can make an authorization decision based on whether or not faculty members are permitted to make the request in question, rather than just looking at the identity of the UAC and trying to discern whether or not they are a faculty member through some external means. Thus, these assertions allow a UAS to authorize a SIP request without having to store or access attributes associated with the identity of the UAC itself. Even complex authorization decisions based the presence of multiple disjointed attributes are feasible; for example, a 'faculty' member could be part of the 'chemistry' department, and both of these traits could be used to make authorization decisions in a given federation. 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 under the same administration. In order for traits to have a broader usage for services like SIP, which commonly are not bounded by administrative domains, domains that participate in a common authorization scheme must federate with one another. The concept of federation is integral to any trait-based authorization scheme. Domains that federate with one another agree on the syntax and semantics of traits -- without this consensus, trait-based authorization schemes would only be useful in an intradomain context. A federation is defined as a set of administrative domains that implement common policies regarding the use and applicability of traits for authorization decisions. Federation necessarily implies a trust relationship, and usual implies some sort of pre-shared keys or other means of cryptographic assurance that a particular assertion was generated by an authorization service that participates in the federation. In fact, when trait-based authorization is used, an assertion of 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, 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 independent of identity. This fact allows trait-based authorization to offer a very compelling privacy and anonymity solution. Identity becomes one more attribute of an assertion that may or may not be disclosed to various destinations. Trait-based authorization for SIP depends on authorization services that are trusted by both the UAC and the UAS that wish to share a session. For that reason, the authorization services described in this document are most applicable to clients either in a single
domain or in federated domains that have agreed to trust one another's authorization services. This could be common in academic environments, or business partnerships that wish to share attributes of principals with one another. Some trait-based authorization architectures have been proposed to provide single sign-on services across multiple providers. Although trait-based identity offers an alternative to traditional identity architectures, this effort should be considered complementary to the end-to-end cryptographic SIP identity effort . An authentication service might also act as an authorization service, generating some sort of trait assertion token instead of an authenticated identity body. RFC 2119  and indicate requirement levels for compliant SIP implementations. 3]). User agents might also use a separate protocol to request an assertion. In either case, the client will need to authenticate itself to an authorization service before it receives an assertion. This authentication could use any of the standard mechanisms described in RFC 3261 , or use some other means of authentication. Once a SIP UA has an assertion, it will need some way to carry an 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 include a MIME body within a SIP request that contains the assertion; this would be inclusion by value. Alternatively, content
indirection , or some new header, could be used to provide a URI (perhaps an HTTP URL) where interested parties could acquire the assertion; this is inclusion by reference. The basic model is as follows: +----------------+ | | | +------------+ | Request | +------------+ | | | Entity | |------------------------>| | Assertion | | | | requesting | | | | Granting | | | | authz | |<------------------------| | Entity | | | | assertions | | Assertion | +------------+ | | +------------+ | | ^ | | | | | . Trust | | | | | . Rel. | | | | | v | | | | | +------------+ | | Transfer | | | Assertion | | | | | | | Verifying | | | | | | | Entity | | | | | | +------------+ | | | | | | | v | +----------------+ | +------------+ | Service Request + ^ | | | Entity | | Assertion | | | | using authz| | -----------------------------+ | | | assertion | | | | +------------+ | <-------------------------------+ +----------------+ Response/Error The entity requesting authorization assertions (or the entity that gets some assertions granted) and the entity using these authorization assertions might be co-located in the same host or domain, or they might be entities in different domains that share a federate with one another. The same is true for the entity that grants these assertions to a particular entity and the entity that verifies these assertions. 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 these assertions. Furthermore, different protocols might be used and the assertions may have a lifetime that might allow that these assertions are presented to the verifying entity multiple times (during the lifetime of the assertion). Some important design decisions are associated with carrying assertions in a SIP request. If an assertion is carried by value, or uses a MIME-based content indirection system, then proxy servers will
be unable to inspect the assertion themselves. If the assertion were referenced in a header, however, it might be possible for the proxy to acquire and inspect the assertion itself. There are certainly architectures in which it would be meaningful for proxy servers to apply admissions controls based on assertions. It is also the case that carrying assertions by reference allows versatile access controls to be applied to the assertion itself. For instance, an HTTP URL where an assertion could be acquired could indicate a web server that challenged requests, and only allowed certain authorized sources to inspect the assertion, or that provided different versions of the assertion depending on who is asking. When a SIP UA initiates a request with privacy controls , a web server might provide only trait information ('faculty', 'student', or 'staff') to most queries, but provide more detailed information, including the identity of the originator of the SIP request, to certain privileged askers. The end-users that make requests should have some way to inform authorization services of the attributes that should be shared with particular destinations. Assertions themselves might be scoped to a particular SIP transaction or SIP dialog, or they might have a longer lifetime. The recipient of an assertion associated with a SIP request needs to have some way to verify that the authorization service intended that this assertion could be used for the request in question. However, the format of assertions is not specified by these requirements. 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 recipient of a request to provide authorization data to the requestor. Trait-based authorization has significant applicability to SIP. There are numerous instances in which it is valuable to assert particular facts about a principal other than the principal's identity to aid the recipient of a request in making an authorization policy decision. For example, a telephony service provider might assert that a particular user is a 'customer' as a trait. An emergency services network might indicate that a particular user has a privileged status as a caller.
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, they must first trust that the call originated from the gateway and that the gateway is operated by a known (and trusted) provider. There are a number of ways that a service provider might try to address this problem. One possibility would be routing all calls from gateways through a recognizable 'edge' proxy server (say, 'sip.example.com'). Accordingly, any SIP entity that received a request via the edge proxy server (assuming the use of hop-by-hop mutual cryptographic authentication) would know the service provider from whom the call originated. However, it is possible that requests from the originating service provider's edge proxy might be proxied again before reaching the destination user agent server, and thus in many cases the originating service provider's identity would be known only transitively. Moreover, in many architectures requests that did not originate from PSTN gateways could be sent through the edge proxy server. In the end analysis, the recipient of the request is less interested in knowing which carrier the request came from than in knowing that the request came from a gateway. Another possible solution is to issue certificates to every gateway corresponding to the hostname of the gateway ('gateway1.example.com'). Gateways could therefore sign SIP requests directly, and this property could be preserved end-to-end. But depending on the public key infrastructure, this could, however, become costly for large numbers of gateways, and moreover a user agent server that receives the request has no direct assurance from a typical certificate that the host is in fact a gateway just because it happens to be named 'gateway1'. Trait-based authorization would enable the trait 'is a gateway' to be associated with an assertion that is generated by the service provider (i.e., signed by 'example.com'). Since these assertions would travel end-to-end from the originating service provider to the destination user agent server, SIP requests that carry them can pass through any number of intermediaries without discarding cryptographic authentication information. This mechanism also does not rely on hostname conventions to identify what constitutes a gateway and what does not -- it relies on an explicit and unambiguous attribute in an assertion.
respective communities. For example, faculty members might have privileges to establish videoconferences during the day, while students might not. Faculty might also be able to add students to a particular videoconference dynamically, or otherwise moderate the content or attendance of the conference, whereas students might participate only more passively. Trait-based authorization is ideal for managing authorization decisions that are predicated on membership in a group. Rather than basing access on individual users, levels (or roles) could be assigned that would be honored by both universities, since they both participate in the same federation. If the federation honored the traits "faculty", "staff", and "student", they could be leveraged to ensure appropriate use of the network resource between universities participating in the federation. An assertion would then be attached to every request to establish a session that indicated the role of the requestor. Only if the requestor has the appropriate trait would the session request be granted. Ideally, these policies would be enforced by intermediaries (SIP proxy servers) that are capable of inspecting and verifying the assertions.
priority assessment. If the assertion's creator is trusted by the evaluator, the given priority could be factored into any relevant request processing.
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)  and another is RFC 3281 X.509 Attribute Certificates . 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.
Section 3.  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.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.  Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.  Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.  Organization for the Advancement of Structured Industry Standards, "Security Assertion Markup Language v1.0", November 2002, <http://www.oasis-open.org>.  Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
http://www.neustar.biz/ James M. Polk Cisco Systems 2200 East President George Bush Turnpike Suite 570 Richardson, TX 75802 US EMail: email@example.com Douglas C. Sicker University of Colorado at Boulder ECOT 531 Boulder, CO 80309 US EMail: firstname.lastname@example.org 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 email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).