One document matched: draft-peterson-sipping-role-authz-00.txt
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, <http://www.oasis-open.org>.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 11:09:42 |