Trait-based Authorization Mechanisms for SIP Based on SAML

Transcription

1 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 Security Assertion Markup Language (SAML) in collaboration with SIP to accommodate richer authorization mechanisms and enable trait-based authorization whereby users are authorized based on traits (or attributes) instead of identity. As such, this provides an alternative to existing authorization mechanisms for SIP. Existing mechanisms are generally identity based and present challenges in face of frequent changing identities, pseudonyms or even privacy enabling environments. Such a trait-based authorization mechanism 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. Although trait-based authorization offers an alternative to traditional identity based authorization, this effort should be considered complementary to sophisticated SIP security mechanisms available today. Index Terms SAML, SIP, Security, Trait-based authorization, Roles I. INTRODUCTION Session Initiation (SIP) [1] is an application layer signaling protocol created by the Internet Engineering Task Force (IETF). SIP allows SIP aware entities to locate one another and to establish, maintain and terminate a session. 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 allowing greater privacy for users. This effort stems from the recognition that when a User Agent Server (UAS) receives SIP requests, there are authorization requirements that are orthogonal to ascertaining 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 who originated a SIP request. For example, in traditional SIP authorization architectures, the mere fact that a UAC has been authenticated by a UAS does not 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. Further, when trait-based authorization is used, an assertion of attributes can be presented to a UAS instead (or in addition) 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 an end, which is 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. It is desirable to have authorization decisions that are somewhat more sophisticated than simple accept or reject decisions. Authorization decisions that are context-specific would be a significant enhancement. For instance, a policy that is sensitive to the time of the day may authorize a user only during a certain period during the day (say during business hours). For such a policy to be implemented, some form of an access control mechanism is needed that can express such a policy. One of the problems with many authorization systems based on identity is that there needs to be an a priori establishment of privileges associated with that identity, especially when the access control policies have at least a moderate level of sophistication. In some cases attributes are more important than the identity - particularly if identities can easily be obtained such as in many systems today. Providing the authorizing entity with as much information as possible (and allowed) about the calling user will, therefore, assist in the authorization process. 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

2 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, it can make an authorization decision (if it trusts the signing university either directly or indirectly via a federation) based on whether 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 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. The trait-based authorization for SIP that we describe in this paper depends on authorization services built around trust relationships. 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. It is important to point out this interdomain relationship will likely involve a fairly complex pre-negotiation stage. The two domains will need to do significant prenegotiation of potential traits and values in order to make meaningful authorization decisions. Some trait-based authorization architectures have been proposed to provide single sign-on services across multiple providers. Although trait-based authorization offers an alternative to traditional identity based authorization, this effort should be considered complementary to sophisticated SIP security mechanisms available today. An authentication service might also act as an authorization service, generating some sort of trait assertion token instead of an authenticated identity body. In order to facilitate such trait-based authorizations, we define a SAML-based mechanism for asserting user attributes across domains in a secure manner. Clearly, there are other possible solutions to provide trait-based authorization, including authorization certificates, SPKI, or extensions to the authenticated identity body as described in [3]. The authors selected SAML due to the maturity of the technology, the flexibility it offers, and its fit with the existing SIP mechanisms. SAML is an XML extension for security information exchange. Currently, SAML s primary application has been in single sign-on mechanisms for web services. Within the SAML model, authentication, attribute and authorization elements are coded into SAML assertions, which are then transported between the entities in different domains. Profiles define ways to incorporate SAML in different communication protocols and frameworks. We define two profiles for using SAML in SIP - the transfer of SAML assertions by value or by reference. We also describe how this mechanism could be used to assist in VoIP emergency service, and as a means of providing efficient inter-carrier authentication and authorization. This remainder of this paper is organized as follows. Section II provides a brief overview of SAML. Section III provides a brief rationale and description of the SAML architectural model. Section IV describes the SIP SAML profiles. Finally, section V describes two use cases where this mechanism could be applied. II. BACKGROUND This section provides a brief primer on Security Assertion Markup Language (SAML). For additional background on SIP, refer to [1]. Various groups have contributed to the general development of trait (or role) based access schemes; see [4], [5], [6]. More recently, OASIS and Internet2 have worked to develop an RBA model for web service single sign-on, namely Shibboleth, see [7], [9]. OASIS developed an XML extension for security information exchange, referred to as the Security Assertion Markup Language (SAML). This mechanism allows for the rich representation of security information and is a highly structured language. In SAML, there are three main entities: the user, the asserting party and the relying party. The asserting party is asserting that proper authentication has been given by a particular user and that this user possesses certain attributes. The relying party has to trust the asserting party with regard to the information provided, and then decide whether to accept those assertions, giving different levels of privileges. The components of SAML include assertions/artifacts, request/response protocols, and bindings and profiles. [7] An assertion is a package of information, which includes authentication statements, attribute statements, and authorization decision statements. An assertion contains several elements, including (1) issuing information, (2) subject information, and (3) additional advice. In an authentication statement, an issuing authority asserts that a certain subject was authenticated by certain

3 means at a certain time. In an attribute statement, an issuing authority asserts that a certain subject is associated with certain attributes, which have certain values. For example, user Alice@cs.example.com is associated with the attribute 'Department', which has the value 'Computer Science'. In an authorization decision statement, an individual subject is allowed to access a 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 the resource could be, for example, a web service. The artifact used in the Browser/Artifact profile, is a base-64 encoded string that is 40 bytes long. 20 bytes consists of the typecode, which is the source ID. The remaining 20 bytes consists of a 20-byte random number 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 data from the artifact on the source site. The purpose of the artifact is to act as a reference to an assertion. the form of a URI (this concept is presently under consideration as an addition to [8]). Note that this exchange also allows the artifact to be bound to a particular signaling session by attaching the assertion to the service request. This requires the Asserting Party to participate in the signaling message exchange, and provides stronger security properties. Request Artifact Artifact Service Request including Artifact III. MODELS When using a profile, SAML is used to provide assertions about a resource in the body of the message itself. In Version 1.1 of SAML, there are two profiles specified, the Browser/Artifact profile and the Browser/POST profile. The Browser/Artifact profile represents a "pull" model, where a special reference to the assertion, called an artifact, is sent to the relying party from the asserting party. The artifact is then used to "pull" the assertion from the asserting party. The Browser/POST profile represents a "push" model, where an assertion is posted (using the HTTP POST command) directly to the relying party. These two models are described below and depicted in Figure 1 and Figure 2. [7] These models are also described in [11], which also describes the general concept of how to store a messaging identity assertion in a messaging protocol. We present each model in this section and then elaborate on these models in the following section. In the Pull model the end host requests an assertion from the Asserting Party and receives, after successful authentication and authorization, an artifact. As previously described the artifact is a special form of an assertion. This artifact can be compared with the call-by reference approach where a reference to the assertion is stored with the Asserting Party and can later be referenced. The Relying Party fetches the SAML assertion after receiving a request by the user that includes the artifact. For communicating the SAML request and response messages, a separate message exchange is needed with a protocol such as SOAP or HTTP, which is outside the scope of this document. As an alternative to the above model, the artifact might take Figure 1: SAML Pull model Accept or Reject SAML Request SAML Response including Assertion With the Push model, the user requests an assertion from the Asserting Party. Figure 2 depicts this exchange. The user can also trigger the Asserting Party to attach an assertion to the request. The Relying Party, without additional protocol interactions with the Asserting Party, can verify the assertion, which is added to the service request. The assertion therefore contains enough information to authorize the service request. This Push model realizes a call-by value interaction. Request Assertion Assertion Figure 2: SAML Push model Service Request including Assertion Accept or Reject

4 IV. SECURITY AND ARCHITECTURAL CONSIDERATIONS The usage of SAML in HTTP-based environments and in SIP is, however, affected by some architectural differences. The user has to request an assertion from the Asserting Party, then both entities mutually authenticate each other. The requested assertion is sent to the user in a confidential manner to prevent eavesdroppers from obtaining this assertion. SIP signaling messages may traverse multiple SIP proxies between two SIP UAs. With the involvement of multiple entities a large number of scenarios need to be considered. As an example, the scenario addressed in [10] aims to replace end-to-end authentication via S/MIME by a "mediated authentication architecture". Thereby, end hosts only need to be able to verify assertions signed by an Service, which guarantees that the sender was authenticated, instead of authenticating the end hosts directly. Directly applying SAML to such a scenario, however, causes a problem; a SIP proxy, which securely receives a SAML assertion (for example via a TLS secured channel providing confidentiality protection between the SIP UA and the SIP proxy to prevent eavesdroppers from learning the assertion), can store this assertion to impersonate the user in future requests towards other SIP entities. The fact that multiple SIP proxies may see the assertion/artifact raises some security concerns. The assertion might include some attributes, which restrict its usage (such as lifetime or indication of a particular resource). To prevent impersonation a binding between the assertion and the protocol is possible. This binding is 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, but in many SIP scenarios there seems to be a problem when such a binding is not provided. There is little use in requesting assertions from a separate Service for every SIP message exchange since the additional latency and performance impact could potentially be large. Future work will consider the use of holder-of-the-key assertions. V. SIP PROFILES FOR SAML Currently OASIS defines SAML bindings and profiles for SOAP over HTTP. This section defines the SIP profiles for SAML. The section discusses two profiles; the SIP Artifact Profile and the SIP Assertion Profile. This discussion is maintained at a high level in terms of network element responsibility. The details of the requirements for the various network elements are proposed in [10] and [8]. A. SIP ARTIFACT PROFILE FOR SAML The SIP artifact profile of SAML relies on a reference to the needed assertion traveling in the form of a SAML artifact, which the target domain must dereference from the origin domain in order to determine the user s security information. The artifact may be carried in a SIP header or as an attached MIME body. The SIP artifact profile consists of a single interaction among three parties (a user agent, an originating domain, and a target domain), with a nested sub-interaction between two parties (the originating domain and the target domain site). The interaction sequence is shown in Figure 3, with the following paragraphs elucidating each step. The following models should be viewed as illustrative rather than prescriptive. For example, the security procedure could occur prior to the assertion request (or after as depicted below). ALICE Request Artifact Artifact SIP INVITE including Artifact SAML Request SAML Response including Assertion INBOUND SIP PROXY AS SIP INVITE BOB Figure 3: SIP Artifact Profile for SAML (the SAML Pull model) In step 1, an authentication and authorization process is executed between the SIP UA and the Asserting Party. User authorization by the Asserting Party is important in order to be able to create the SAML assertion and the respective attributes. The SIP UA must ensure that the Asserting Party is genuine. In step 2, the user agent at the origin domain requests an artifact. In step 3, an artifact is returned to the user agent. The assertion is temporarily stored at the Asserting Party for later retrieval by the Relying Party. In step 4, the artifact is extracted and added to the INVITE as a MIME attachment or inserted into a SIP header and sent.

5 In steps 5 and 6, the target domain (the relying party) dereferences the one or more SAML artifacts in its possession in order to acquire the SAML assertions that correspond to each artifact. A registered SAML protocol binding is used for a SAML request-response message exchange between the target and origin domains. The target domain functions as a SAML requester, and the originating domain functions as a SAML responder. In step 7, based on the results of the prior exchange, the inbound proxy server forwards the INVITE to the target user s UA. In step 8, the typical SIP session setup continues. B. SIP ASSERTION PROFILE FOR SAML The SIP assertion profile of SAML allows authentication information to be supplied to the target domain without the use of an artifact or the need for a binding The SIP assertion profile consists of a series of two interactions, the first between a user equipped with a user agent and a source site, and the second directly between the user and the destination site. The interaction sequence is shown in Figure 4, with the following sections elucidating each step. ALICE Request Assertion Assertion SIP INVITE including Assertion INBOUND SIP PROXY SIP INVITE including Assertion BOB AS Figure 4: SIP Assertion Profile for SAML (the SAML Push model) In step 1, an authentication and authorization process transpires. In step 2, the user agent at the origin domain requests an assertion. In step 3, an assertion is returned to the user agent. In step 4, the assertion is extracted and added to the INVITE as a MIME attachment or inserted into a SIP header and sent. In step 5, based on an analysis (by the relying party) of the assertion, the inbound proxy server forwards the INVITE to the target user s UA. In step 6, the typical SIP session setup continues. C. CONSIDERATIONS REGARDING PROFILES The artifact profile describes a pull architecture, wherein the actual transfer of assertions is initiated by the target domain. The obvious advantage here is the opportunity for the target domain to request assertions describing specific attributes. In this pull model, the assertion/artifact would be carried in the header. It is worth noting, that the artifact for SIP would need to contain a whole URL (the Identity-Info header as described in the sip-identity draft), which could be dereferenced to discover the asserting party. The assertion profile, on the other hand, describes a push architecture, wherein the assertions are pushed out by the origin domain. The reduction in roundtrip time is the major advantage in this case. However, since the target domain does not have the opportunity to request specific attributes, the origin domain needs to know which attributes need to be sent. It is very difficult for the SIP sender to anticipate (and predict the traits of interest of) the eventual recipient. This reduces the flexibility of the process because it will have to be specified in the trust agreement between the domains. VI. USE CASES In [10] and [8] we describe a number of high-level examples of the sort of services that trait based systems might provide. This includes mechanisms for the (1) accounting of services, (2) associating gateways with providers, (3) granting permissions on constrained resources, (4) providing geolocation privacy authorization, and (5) managing priority and precedence. We now consider two of these examples in more detail. A. MANAGING PRIORITY AND PRECEDENCE There is a significant amount of interest in the Internet telephony community in assigning certain calls a 'priority' based on the identity of the user, with the presumption that prioritized calls will be granted preferential treatment when network resources are scarce. Different domains might have different criteria for assigning priority, and it is unlikely that a domain would correlate the identity of a non-local user with the need for priority, even in situations where domains would like to respect one another's prioritization policies. Existing proposals have focused largely on adding a new header field to SIP that might carry a priority indicator. This use case does not challenge this strategy, but merely shows by way of example how this requirement might be met with a trait-based authorization system. As such, the limitations of the

6 header field approach will not be contrasted here with a hypothetical trait-based system. An assertion created by a domain for a particular request might have an associated 'priority' attribute. Recipients of the request could inspect and verify the signature associated with the assertion to determine which domain had authenticated the user and made the priority assessment. If the evaluator trusts the assertion s creator, the given priority could be factored into any relevant request processing. This type of mechanism might be applicable to emergency service situation such as 911 and GETS calls. B. GRANTING PERMISSIONS ON CONSTRAINTED RESOURCES Consider a scenario wherein two universities are making use of a videoconferencing service over a constrained bandwidth resource. Both universities would like to enforce policies that determine how this constrained bandwidth will be allocated to members of their respective communities. For example, faculty members might have privileges to connect 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. Traitbased 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. Attributes could be established for "faculty", "staff", and "student" to ensure appropriate use of the resource. 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. VII. FUTURE WORK A number of open issues and details to this model are presently under consideration within the IETF SIP and the SIPPING working group. For example, efforts are underway to verify the security model that surrounds the mechanisms. Related to this are efforts aimed at ensuring the reference integrity of the assertions used in this model. Also, a number of artifact and assertion related issues remain, including who and in what fashion assertions and artifacts should be added to various SIP messages. collaboration with SIP to accommodate richer authorization mechanisms and enable trait-based authorization whereby users are authenticated based on traits (or roles) instead of identity. Such a trait-based authorization mechanism has significant applicability to SIP. We have described two such applications, namely a mechanism for managing priority and precedence and a mechanism for granting permission on constrained resources. IX. ACKNOWLEDGEMENTS We would like to thank James Polk and M. Tegnander for their contributions to this work. REFERENCES [1] Rosenberg J., Schulzrinne H., Camarillo G., Johnston A., Peterson J., Sparks R., Handley M., Schooler E, "SIP: Session Initiation ", RFC [2] Ferraiolo D., Kuhn R., "Role-Based Access Controls", Proceedings of the 15th National Computer Security Conference, Baltimore MD, October [3] Peterson, J., " SIP Authenticated Identity Body (AIB) Format RFC 3893, September [5] Role Based Access Control, National Institute of Standards and Technology. [6] SAML 1.0 Specification Set (31 May 2002): Committee Specifications (OASIS Standard as of 5-Nov- 2002) [7] Mishra P., et al., Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML), OASIS, May [8] Tschofenig, H., Peterson, J., Polk, J., Sicker D. and M. Tegnander, "Using SAML for SIP", draft-tschofenigsip-saml-00, (work-in-progress), July [9] The shibboleth project at Internet2, [10] Peterson, J, Polk, J. and Sicker, D., Role-based Authorization Requirements for the Session Initiation, draft-ietf-sipping-peterson-role-authz-00, (work in progress), January [11] Peterson, J., Security Considerations for Impersonation and Identity in Messaging Systems (work in progress), October VIII. CONCLUSIONS In this paper, we presented a method for using the Security Assertion Markup Language (SAML) in