Trait-based Authorization Mechanisms for SIP Based on SAML
Douglas C. Sicker, University of Colorado Boulder
Hannes Tschofenig, Siemens
Jon Peterson, Neustar
Abstract - This paper presents a method for using the authorization architectures, the mere fact that a UAC has
Security Assertion Markup Language (SAML) in been authenticated by a UAS does not mean that the
collaboration with SIP to accommodate richer UAS will grant the UAC full access to its services or
authorization mechanisms and enable trait-based capabilities - in most instances, a UAS will compare the
authorization whereby users are authorized based on authenticated identity of the UAC to some set of users
traits (or attributes) instead of identity. As such, this that are permitted to make particular requests (as a way
provides an alternative to existing authorization of making an authorization decision). However, in large
mechanisms for SIP. Existing mechanisms are generally communities of users with few pre-existing relationships
identity based and present challenges in face of frequent (such as federations of discrete service providers), it is
changing identities, pseudonyms or even privacy unlikely that the authenticated identity of a UAC alone
enabling environments. Such a trait-based authorization will give a UAS sufficient information to decide how to
mechanism has significant applicability to SIP. There handle a given request. Further, when trait-based
are numerous instances in which it is valuable to assert authorization is used, an assertion of attributes can be
particular facts about a principal other than the presented to a UAS instead (or in addition) of the
principal's identity to aid the recipient of a request in identity of user of the UAC. In many cases, a UAS has
making an authorization policy decision. For example, a no need to know who, exactly, has made a request;
telephony service provider might assert that a particular knowing the identity is only a means to an end, which is
user is a 'customer' as a trait. An emergency services matching that identity to policies that actually depend on
network might indicate that a particular user has a traits independent of identity. This fact allows trait-based
privileged status as a caller. Although trait-based authorization to offer a very compelling privacy and
authorization offers an alternative to traditional identity anonymity solution. Identity becomes one more attribute
based authorization, this effort should be considered of an assertion that may or may not be disclosed to
complementary to sophisticated SIP security various destinations.
mechanisms available today. It is desirable to have authorization decisions that are
Index Terms—SAML, SIP, Security, Trait-based somewhat more sophisticated than simple accept or
authorization, Roles reject decisions. Authorization decisions that are
context-specific would be a significant enhancement.
I. INTRODUCTION For instance, a policy that is sensitive to the time of the
Session Initiation Protocol (SIP) [1] is an application day may authorize a user only during a certain period
layer signaling protocol created by the Internet during the day (say during business hours). For such a
Engineering Task Force (IETF). SIP allows SIP aware policy to be implemented, some form of an access
entities to locate one another and to establish, maintain control mechanism is needed that can express such a
and terminate a session. While some authentication policy. One of the problems with many authorization
mechanisms are described in the base SIP specification, systems based on identity is that there needs to be an a
trait-based authorization provides information used to priori establishment of privileges associated with that
make policy decisions based on the attributes of a identity, especially when the access control policies have
participant in a session. This approach provides a richer at least a moderate level of sophistication. In some cases
framework for authorization, as well as allowing greater attributes are more important than the identity -
privacy for users. particularly if identities can easily be obtained such as in
many systems today. Providing the authorizing entity
This effort stems from the recognition that when a User
with as much information as possible (and allowed)
Agent Server (UAS) receives SIP requests, there are
about the calling user will, therefore, assist in the
authorization requirements that are orthogonal to
authorization process.
ascertaining the identity of the User Agent Client
(UAC). Supplemental authorization information might Trait-based authorization entails an assertion by an
allow the UAS to implement non-identity-based policies authorization service of attributes associated with an
that depend on further attributes of the principal who identity. An assertion is a sort of document consisting of
originated a SIP request. For example, in traditional SIP a set of these attributes that are wrapped within a digital
signature provided by the party that generates the maturity of the technology, the flexibility it offers, and
assertion (the operator of the authorization service). its fit with the existing SIP mechanisms. SAML is an
These attributes describe the 'trait' or 'traits' of the XML extension for security information exchange.
identity in question - facts about the principal Currently, SAML’s primary application has been in
corresponding to that identity. For example, a given single sign-on mechanisms for web services. Within the
principal might be a faculty member at a university. An SAML model, authentication, attribute and authorization
assertion for that principal's identity might state that they elements are coded into SAML assertions, which are
have the 'trait' of 'is a faculty member', and the assertion then transported between the entities in different
would be issued (and signed) by a university. When a domains. Profiles define ways to incorporate SAML in
UAS receives a request with this trait assertion, it can different communication protocols and frameworks. We
make an authorization decision (if it trusts the signing define two profiles for using SAML in SIP - the transfer
university either directly or indirectly via a federation) of SAML assertions by value or by reference. We also
based on whether faculty members are permitted to make describe how this mechanism could be used to assist in
the request in question, rather than just looking at the VoIP emergency service, and as a means of providing
identity of the UAC and trying to discern whether they efficient inter-carrier authentication and authorization.
are a faculty member through some external means.
This remainder of this paper is organized as follows.
Thus, these assertions allow a UAS to authorize a SIP
Section II provides a brief overview of SAML. Section
request without having to store or access attributes
III provides a brief rationale and description of the
associated with the identity of the UAC itself. Even
SAML architectural model. Section IV describes the
complex authorization decisions based the presence of
SIP SAML profiles. Finally, section V describes two
multiple disjointed attributes are feasible; for example, a
‘use cases’ where this mechanism could be applied.
'faculty' member could be part of the 'chemistry'
department, and both of these traits could be used to
II. BACKGROUND
make authorization decisions in a given federation.
This section provides a brief primer on Security
The trait-based authorization for SIP that we describe in
this paper depends on authorization services built around Assertion Markup Language (SAML). For additional
trust relationships. For that reason, the authorization background on SIP, refer to [1].
services described in this document are most applicable Various groups have contributed to the general
to clients either in a single domain or in federated development of trait (or role) based access schemes; see
domains that have agreed to trust one another's [4], [5], [6]. More recently, OASIS and Internet2 have
authorization services. This could be common in worked to develop an RBA model for web service single
academic environments, or business partnerships that sign-on, namely Shibboleth, see [7], [9]. OASIS
wish to share attributes of principals with one another. It developed an XML extension for security information
is important to point out this interdomain relationship exchange, referred to as the Security Assertion Markup
will likely involve a fairly complex pre-negotiation Language (SAML). This mechanism allows for the rich
stage. The two domains will need to do significant pre- representation of security information and is a highly
negotiation of potential traits and values in order to make structured language. In SAML, there are three main
meaningful authorization decisions. Some trait-based entities: the user, the asserting party and the relying
authorization architectures have been proposed to party. The asserting party is asserting that proper
provide single sign-on services across multiple authentication has been given by a particular user and
providers. Although trait-based authorization offers an that this user possesses certain attributes. The relying
alternative to traditional identity based authorization, this party has to trust the asserting party with regard to the
effort should be considered complementary to information provided, and then decide whether to accept
sophisticated SIP security mechanisms available today. those assertions, giving different levels of privileges.
An authentication service might also act as an The components of SAML include assertions/artifacts,
authorization service, generating some sort of trait request/response protocols, and bindings and profiles.
assertion token instead of an authenticated identity body. [7] An assertion is a package of information, which
includes authentication statements, attribute statements,
In order to facilitate such trait-based authorizations, we
and authorization decision statements. An assertion
define a SAML-based mechanism for asserting user
contains several elements, including (1) issuing
attributes across domains in a secure manner. Clearly,
information, (2) subject information, and (3) additional
there are other possible solutions to provide trait-based
advice.
authorization, including authorization certificates, SPKI,
or extensions to the authenticated identity body as In an authentication statement, an issuing authority
described in [3]. The authors selected SAML due to the asserts that a certain subject was authenticated by certain
means at a certain time. In an attribute statement, an the form of a URI (this concept is presently under
issuing authority asserts that a certain subject is consideration as an addition to [8]).
associated with certain attributes, which have certain Note that this exchange also allows the artifact to be
values. For example, user Alice@cs.example.com is bound to a particular signaling session by attaching the
associated with the attribute 'Department', which has the assertion to the service request. This requires the
value 'Computer Science'. In an authorization decision Asserting Party to participate in the signaling message
statement, an individual subject is allowed to access a exchange, and provides stronger security properties.
certain resource using a certain action. Based on this,
the relying party then makes the decision to give access
or not. The subject could be a human or a program, and ASSERTING RELYING
the resource could be, for example, a web service. USER
PARTY PARTY
The artifact used in the Browser/Artifact profile, is a
base-64 encoded string that is 40 bytes long. 20 bytes Authentication
Protocol
consists of the typecode, which is the source ID. The Exchange
remaining 20 bytes consists of a 20-byte random number
Request Artifact
that servers use to look up an assertion. The source
server stores the assertion temporarily, and then the
destination server receives the assertion and pulls the Artifact
data from the artifact on the source site. The purpose of
the artifact is to act as a reference to an assertion. Service Request including Artifact
III. MODELS SAML Request
When using a profile, SAML is used to provide SAML Response
assertions about a resource in the body of the message including Assertion
itself. In Version 1.1 of SAML, there are two profiles
specified, the Browser/Artifact profile and the Accept or Reject
Browser/POST profile. The Browser/Artifact profile
represents a "pull" model, where a special reference to Figure 1: SAML Pull model
the assertion, called an artifact, is sent to the relying With the Push model, the user requests an assertion from
party from the asserting party. The artifact is then used the Asserting Party. Figure 2 depicts this exchange. The
to "pull" the assertion from the asserting party. The user can also trigger the Asserting Party to attach an
Browser/POST profile represents a "push" model, where assertion to the request. The Relying Party, without
an assertion is posted (using the HTTP POST command) additional protocol interactions with the Asserting Party,
directly to the relying party. These two models are can verify the assertion, which is added to the service
described below and depicted in Figure 1 and Figure 2. request. The assertion therefore contains enough
[7] These models are also described in [11], which also information to authorize the service request. This Push
describes the general concept of how to store a model realizes a call-by value interaction.
messaging identity assertion in a messaging protocol.
We present each model in this section and then elaborate
on these models in the following section. USER
ASSERTING RELYING
PARTY PARTY
In the Pull model the end host requests an assertion from
the Asserting Party and receives, after successful
Authentication
authentication and authorization, an artifact. As Protocol
previously described the artifact is a special form of an Exchange
assertion. This artifact can be compared with the call-by Request Assertion
reference approach where a reference to the assertion is
stored with the Asserting Party and can later be
Assertion
referenced. The Relying Party fetches the SAML
assertion after receiving a request by the user that
Service Request including Assertion
includes the artifact. For communicating the SAML
request and response messages, a separate message
exchange is needed with a protocol such as SOAP or Accept or Reject
HTTP, which is outside the scope of this document. As
an alternative to the above model, the artifact might take Figure 2: SAML Push model
A. SIP ARTIFACT PROFILE FOR SAML
The SIP artifact profile of SAML relies on a reference to
IV. SECURITY AND ARCHITECTURAL CONSIDERATIONS the needed assertion traveling in the form of a SAML
The usage of SAML in HTTP-based environments and artifact, which the target domain must dereference from
in SIP is, however, affected by some architectural the origin domain in order to determine the user’s
differences. The user has to request an assertion from security information. The artifact may be carried in a
the Asserting Party, then both entities mutually SIP header or as an attached MIME body.
authenticate each other. The requested assertion is sent The SIP artifact profile consists of a single interaction
to the user in a confidential manner to prevent among three parties (a user agent, an originating domain,
eavesdroppers from obtaining this assertion. and a target domain), with a nested sub-interaction
SIP signaling messages may traverse multiple SIP between two parties (the originating domain and the
proxies between two SIP UAs. With the involvement of target domain site). The interaction sequence is shown
multiple entities a large number of scenarios need to be in Figure 3, with the following paragraphs elucidating
considered. As an example, the scenario addressed in each step. The following models should be viewed as
[10] aims to replace end-to-end authentication via illustrative rather than prescriptive. For example, the
S/MIME by a "mediated authentication architecture". security procedure could occur prior to the assertion
Thereby, end hosts only need to be able to verify request (or after as depicted below).
assertions signed by an Authentication Service, which
guarantees that the sender was authenticated, instead of INBOUND SIP PROXY
authenticating the end hosts directly. Directly applying USER ASSERTING AS
RELYING
USER
BOB
SAML to such a scenario, however, causes a problem; a ALICE PARTY PARTY
SIP proxy, which securely receives a SAML assertion Authentication
(for example via a TLS secured channel providing Protocol
Exchange
confidentiality protection between the SIP UA and the Request Artifact
SIP proxy to prevent eavesdroppers from learning the
assertion), can store this assertion to impersonate the Artifact
user in future requests towards other SIP entities. The SIP INVITE including Artifact
fact that multiple SIP proxies may see the
assertion/artifact raises some security concerns. The SAML Request
assertion might include some attributes, which restrict its SAML Response
including Assertion
usage (such as lifetime or indication of a particular
resource). SIP INVITE
To prevent impersonation a binding between the 200 OK
assertion and the protocol is possible. This binding is
200 OK
called "reference integrity". However, tightly binding the
assertion to a particular SIP session (e.g., by including
the Call-ID) is not useful in the context of single sign-on, Figure 3: SIP Artifact Profile for SAML (the SAML Pull
but in many SIP scenarios there seems to be a problem model)
when such a binding is not provided. There is little use In step 1, an authentication and authorization process is
in requesting assertions from a separate Authentication executed between the SIP UA and the Asserting Party.
Service for every SIP message exchange since the User authorization by the Asserting Party is important in
additional latency and performance impact could order to be able to create the SAML assertion and the
potentially be large. Future work will consider the use of respective attributes. The SIP UA must ensure that the
holder-of-the-key assertions. Asserting Party is genuine.
V. SIP PROFILES FOR SAML In step 2, the user agent at the origin domain requests an
artifact.
Currently OASIS defines SAML bindings and profiles
for SOAP over HTTP. This section defines the SIP In step 3, an artifact is returned to the user agent. The
profiles for SAML. The section discusses two profiles; assertion is temporarily stored at the Asserting Party for
the SIP Artifact Profile and the SIP Assertion Profile. later retrieval by the Relying Party.
This discussion is maintained at a high level in terms of
network element responsibility. The details of the In step 4, the artifact is extracted and added to the
requirements for the various network elements are INVITE as a MIME attachment or inserted into a SIP
proposed in [10] and [8]. header and sent.
In steps 5 and 6, the target domain (the relying party) In step 5, based on an analysis (by the relying party) of
dereferences the one or more SAML artifacts in its the assertion, the inbound proxy server forwards the
possession in order to acquire the SAML assertions that INVITE to the target user’s UA.
correspond to each artifact. A registered SAML protocol
In step 6, the typical SIP session setup continues.
binding is used for a SAML request-response message
exchange between the target and origin domains. The C. CONSIDERATIONS REGARDING PROFILES
target domain functions as a SAML requester, and the The artifact profile describes a “pull” architecture,
originating domain functions as a SAML responder. wherein the actual transfer of assertions is initiated by
the target domain. The obvious advantage here is the
In step 7, based on the results of the prior exchange, the
opportunity for the target domain to request assertions
inbound proxy server forwards the INVITE to the target
describing specific attributes. In this pull model, the
user’s UA.
assertion/artifact would be carried in the header. It is
In step 8, the typical SIP session setup continues. worth noting, that the artifact for SIP would need to
contain a whole URL (the “Identity-Info” header as
B. SIP ASSERTION PROFILE FOR SAML
described in the sip-identity draft), which could be
The SIP assertion profile of SAML allows authentication
dereferenced to discover the asserting party.
information to be supplied to the target domain without
the use of an artifact or the need for a binding The assertion profile, on the other hand, describes a
“push” architecture, wherein the assertions are “pushed”
The SIP assertion profile consists of a series of two
out by the origin domain. The reduction in roundtrip
interactions, the first between a user equipped with a
time is the major advantage in this case. However, since
user agent and a source site, and the second directly
the target domain does not have the opportunity to
between the user and the destination site. The
request specific attributes, the origin domain needs to
interaction sequence is shown in Figure 4, with the
know which attributes need to be sent. It is very difficult
following sections elucidating each step.
for the SIP sender to anticipate (and predict the traits of
interest of) the eventual recipient. This reduces the
USER
flexibility of the process because it will have to be
B OB AS specified in the trust agreement between the domains.
USER ASSERTING INBOUND RELYING
ALICE PARTY SIP P ROXY P ARTY
VI. USE CASES
Authentication
Protocol In [10] and [8] we describe a number of high-level
Exchange examples of the sort of services that trait based systems
Request Assertion might provide. This includes mechanisms for the (1)
accounting of services, (2) associating gateways with
Assertion
providers, (3) granting permissions on constrained
resources, (4) providing geolocation privacy
SIP INVITE including Assertion
authorization, and (5) managing priority and precedence.
SIP INVITE We now consider two of these examples in more detail.
including Assertion
A. MANAGING PRIORITY AND PRECEDENCE
200 OK
There is a significant amount of interest in the Internet
200 OK
telephony community in assigning certain calls a
'priority' based on the identity of the user, with the
presumption that prioritized calls will be granted
Figure 4: SIP Assertion Profile for SAML (the SAML preferential treatment when network resources are
Push model) scarce. Different domains might have different criteria
for assigning priority, and it is unlikely that a domain
In step 1, an authentication and authorization process
would correlate the identity of a non-local user with the
transpires.
need for priority, even in situations where domains
In step 2, the user agent at the origin domain requests an would like to respect one another's prioritization
assertion. policies. Existing proposals have focused largely on
adding a new header field to SIP that might carry a
In step 3, an assertion is returned to the user agent.
priority indicator. This use case does not challenge this
In step 4, the assertion is extracted and added to the strategy, but merely shows by way of example how this
INVITE as a MIME attachment or inserted into a SIP requirement might be met with a trait-based
header and sent. authorization system. As such, the limitations of the
header field approach will not be contrasted here with a collaboration with SIP to accommodate richer
hypothetical trait-based system. An assertion created by authorization mechanisms and enable trait-based
a domain for a particular request might have an authorization whereby users are authenticated based on
associated 'priority' attribute. Recipients of the request traits (or roles) instead of identity. Such a trait-based
could inspect and verify the signature associated with the authorization mechanism has significant applicability to
assertion to determine which domain had authenticated SIP. We have described two such applications, namely a
the user and made the priority assessment. If the mechanism for managing priority and precedence and a
evaluator trusts the assertion’s creator, the given priority mechanism for granting permission on constrained
could be factored into any relevant request processing. resources.
This type of mechanism might be applicable to
emergency service situation such as 911 and GETS calls. IX. ACKNOWLEDGEMENTS
B. GRANTING PERMISSIONS ON We would like to thank James Polk and M. Tegnander
CONSTRAINTED RESOURCES for their contributions to this work.
Consider a scenario wherein two universities are making REFERENCES
use of a videoconferencing service over a constrained [1] Rosenberg J., Schulzrinne H., Camarillo G., Johnston
bandwidth resource. Both universities would like to A., Peterson J., Sparks R., Handley M., Schooler E,
enforce policies that determine how this constrained "SIP: Session Initiation Protocol", RFC 3261.
bandwidth will be allocated to members of their
respective communities. For example, faculty members [2] Ferraiolo D., Kuhn R., "Role-Based Access
might have privileges to connect videoconferences Controls", Proceedings of the 15th National Computer
during the day, while students might not. Faculty might Security Conference, Baltimore MD, October 1992.
also be able to add students to a particular [3] Peterson, J., " SIP Authenticated Identity Body (AIB)
videoconference dynamically, or otherwise moderate the Format” RFC 3893, September 2004.
content or attendance of the conference, whereas
[5] “Role Based Access Control”, National Institute of
students might participate only more passively. Trait-
Standards and Technology. http://csrc.nist.gov/rbac/
based authorization is ideal for managing authorization
decisions that are predicated on membership in a group. [6] SAML 1.0 Specification Set (31 May 2002):
Rather than basing access on individual users, levels (or Committee Specifications (OASIS Standard as of 5-Nov-
roles) could be assigned that would be honored by both 2002)
universities. Attributes could be established for [7] Mishra P., et al., “Bindings and Profiles for the
"faculty", "staff", and "student" to ensure appropriate use OASIS Security Assertion Markup Language (SAML)”,
of the resource. An assertion would then be attached to OASIS, May 2002.
every request to establish a session that indicated the role
[8] Tschofenig, H., Peterson, J., Polk, J., Sicker D. and
of the requestor. Only if the requestor has the
M. Tegnander, "Using SAML for SIP", draft-tschofenig-
appropriate trait would the session request be granted.
sip-saml-00, (work-in-progress), July 2004.
Ideally, these policies would be enforced by
intermediaries (SIP proxy servers) that are capable of [9] The shibboleth project at Internet2,
inspecting and verifying the assertions. http://shibboleth.internet2.edu
[10] Peterson, J, Polk, J. and Sicker, D., “Role-based
VII. FUTURE WORK Authorization Requirements for the Session Initiation
A number of open issues and details to this model are Protocol”, draft-ietf-sipping-peterson-role-authz-00,
presently under consideration within the IETF SIP and (work in progress), January 2004.
the SIPPING working group. For example, efforts are [11] Peterson, J., “Security Considerations for
underway to verify the security model that surrounds the Impersonation and Identity in Messaging Systems”
mechanisms. Related to this are efforts aimed at http://www.ietf.org/internet-drafts/draft-peterson-
ensuring the reference integrity of the assertions used in message-identity-00.txt, (work in progress), October
this model. Also, a number of artifact and assertion 2004.
related issues remain, including who and in what fashion
assertions and artifacts should be added to various SIP
messages.
VIII. CONCLUSIONS
In this paper, we presented a method for using the
Security Assertion Markup Language (SAML) in