SIPPING WG J. Peterson Internet-Draft NeuStar Expires: August 25, 2003 J. Polk Cisco D. Sicker CU Boulder February 24, 2003 Role-based Authorization Requirements for the Session Initiation Protocol draft-peterson-sipping-role-authz-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document lays out a set of requirements related to role-based authorization for the Session Initiation Protocol. While numerous authentication mechanisms are described in the base SIP specification, role-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 allow greater privacy for users of an Peterson, et al. Expires August 25, 2003 [Page 1] Internet-Draft SIPPING RBA February 2003 identity system. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Role-Based Authorization Framework . . . . . . . . . . . . . . 4 4. Role-based Authorization Requirements . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 Normative References . . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Peterson, et al. Expires August 25, 2003 [Page 2] Internet-Draft SIPPING RBA February 2003 1. Introduction This document explores requirements of the Session Initiation Protocol [1] for enabling role-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 go beyond the establishment 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, 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 pre-existing 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. Role-based authorization entails an assertion by a authorization service of attributes associated with an identity. These attributes describe the 'role' or 'roles' 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 'role' of a faculty member. When a UAS receives a request with this role assertion, 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 discover 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 attributes associated with the identity of the UAC itself. In fact, when role-based authorization is used, an assertion can be presented to a UAS instead of the identity of user of the UAC. In many cases, the 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 roles. This fact allows role-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 shared with various destinations. Role-based authorization depends on an authorization service that is trusted by the UAC and the UAS. For that reason, authorization Peterson, et al. Expires August 25, 2003 [Page 3] Internet-Draft SIPPING RBA February 2003 services are most applicable to either single domains, or 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 role-based authorization architectures have been proposed to provide single sign-on services. Although role-based identity offers an alternative to traditional identity architectures, this effort should be considered complementary to the end- to-end cryptographic SIP identity effort [3]. An authentication service might also act as an authorization service, generating some sort of role assertion token instead of an authenticated identity body. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and indicate requirement levels for compliant SIP implementations. 3. Role-Based Authorization Framework A role-based authorization architecture entails the existence of an authorization service. Devices need to send requests to an authorization service in order to receive an assertion that can be used in the context of a given network request. Different network request types will often necessitate different or additional attributes in assertions from the authorization service. For the purposes of SIP, SIP requests might be supplied to an authorization service to provide the basis for an assertion. It could be the case that a user agent will take a particular SIP request, such as an INVITE, for which it wishes to acquire an assertion and forward this to the authorization service (in a manner similar to the way that an authenticated identity body is requested in [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 RFC3261 [1], 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 Peterson, et al. Expires August 25, 2003 [Page 4] Internet-Draft SIPPING RBA February 2003 indirection [4], 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. 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 which provided different versions of the assertion depending on who is asking. When a SIP UA initiates a request with privacy controls [5], a web server might provide only role 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 makes 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, SIP dialog, or possibly 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. Role 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. Role-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 role. An emergency services network might indicate that a particular user has a privileged status as a caller. Peterson, et al. Expires August 25, 2003 [Page 5] Internet-Draft SIPPING RBA February 2003 4. Role-based Authorization Requirements The following are listed requirements proposed from this effort: 1. The mechanism must support a way for SIP user agents to carry an authorization assertion in SIP requests by reference or by value. 2. The mechanism must allow SIP UACs to supply SIP requests to an authorization service to form the basis for 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. Authorization services must treat each request with a unique assertion; this becomes apparent when the service request is progressive in nature (has multiple values within the same service). 6. Proxy servers should have a way to inspect assertions associated with a SIP request. 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 SAML [6]. 8. Assertion schemes used for this mechanism must have reference integrity with a SIP request in order to prevent replay attacks. Note that this 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 roles associated with the identity of the principal originating a SIP request. No specific roles or attributes are required by this specification. Peterson, et al. Expires August 25, 2003 [Page 6] Internet-Draft SIPPING RBA February 2003 10. The mechanism must support a means for end-users to specify policies to an authorization service for the distribution of their roles and/or attributes to various destinations. 11. An assertion must have security properties that prevent unauthorized parties from viewing the contents of the assertion. 12. Assertion schemes must provide a way of selectively sharing the roles 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 without an identity - that is, to present only attributes or roles 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 an authorization assertion, and to notify the 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. A legitimate recipient of a request containing an assertion (either a UAS or a proxy server) must be capable of inspecting an assertion, and 18. It must be possible for a UAS or proxy server to reject a request containing an assertion that does not provide any attributes or roles that are known to the recipient, or that are relevant to the request in question. 5. 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 roles of the users. As such, the bulk of this document discusses security. The distribution of authorization assertions requires numerous Peterson, et al. Expires August 25, 2003 [Page 7] Internet-Draft SIPPING RBA February 2003 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. 6. IANA Considerations This document introduces no considerations for the IANA. 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, May 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. Informative References [3] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft- ietf-sip-peterson-identity-01 (work in progress), July 2002. [4] Olson, S., "A Mechanism for Content Indirection in SIP Messages", draft-ietf-sip-content-indirect-mech-01 (work in progress), November 2002. [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, . 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/ Peterson, et al. Expires August 25, 2003 [Page 8] Internet-Draft SIPPING RBA February 2003 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 Peterson, et al. Expires August 25, 2003 [Page 9] Internet-Draft SIPPING RBA February 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this 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 revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "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 Funding for the RFC Editor function is currently provided by the Internet Society. Peterson, et al. Expires August 25, 2003 [Page 10]