SIP H. Tschofenig Internet-Draft Siemens Expires: January 10, 2005 J. Peterson NeuStar, Inc. J. Polk Cisco D. Sicker CU Boulder M. Tegnander Siemens July 12, 2004 Using SAML for SIP draft-tschofenig-sip-saml-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes how to use the Security Assertion Markup Language (SAML) to offer trait-based authorization. As such, it Tschofenig, et al. Expires January 10, 2005 [Page 1] Internet-Draft Using SAML for SIP July 2004 provides an alternative to existing authorization mechanisms for SIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5 4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6 4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Request/Response protocol . . . . . . . . . . . . . . . . 7 4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Network Asserted Identities . . . . . . . . . . . . . . . 13 6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 15 6.3 PSTN-to-SIP phone call . . . . . . . . . . . . . . . . . . 17 7. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . 19 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 22 10. Security considerations . . . . . . . . . . . . . . . . . . 23 10.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . 23 10.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . 23 10.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . 23 10.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . 23 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 13. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.1 Normative References . . . . . . . . . . . . . . . . . . . 29 14.2 Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 A. SAML Artifact format . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . 33 Tschofenig, et al. Expires January 10, 2005 [Page 2] Internet-Draft Using SAML for SIP July 2004 1. Introduction This document proposes a method for using the Security Assertion Markup Language (SAML) in collaboration with SIP to acommodate richer authorization mechanisms and enable trait- based authorization where you are authenticated using roles or traits instead of identity. A motivation for trait based authorization and some scenarios are presented in [I-D.ietf-sipping-trait-authz]. Security Assertion Markup Language (SAML)[I-D.saml-tech-overview-1.1-03] is an XML extension for security information exchange. It is being developed by OASIS. SAML enables users to gain access to multiple website resources without having to re-authenticate every time the domain changes. The first authentication would be transferred to subsequent domains using SAML. To provide trait-based authorization a few solutions are possible: authorization certificates, SPKI or extensions to the authenticated identity body [I-D.ietf-sip-authid-body]. The authors selected SAML due to the amount of work done in the area of SAML which provides some assurance that this technology is mature enough. Tschofenig, et al. Expires January 10, 2005 [Page 3] Internet-Draft Using SAML for SIP July 2004 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The SIP entity 'Authentication Service' was introduced with [I-D.ietf-sip-identity]. The Authentication Service is the entity that authenticates and authorizes a user and creates an Assertion. This entity is the equivalent of the asserting party in the SAML terminology. For terminology related to SAML the reader is referred to [I-D.saml-tech-overview-1.1-03]. Tschofenig, et al. Expires January 10, 2005 [Page 4] Internet-Draft Using SAML for SIP July 2004 3. Goals and Non-Goals This document tries to accomplish the following goals: o This document defines how SAML assertions are carried in the SIP header. As such, the usage of SAML Assertions within SIP can be seen as a SAML profile. o The requirements and scenarios defined in [I-D.ietf-sipping-trait-authz] are compared to the solution described in this document by utilizing SAML assertions. The following issues are outside the scope of this document: o The configuration of the Authentication Service in order to attach certain assertions is outside the scope of this specification and might depend on the environment where SIP is used. To avoid restricting the functionality of SIP either as an in-band or an out-of-band mechanism, it can be defined to trigger the inclusion of SAML assertions. XCAP[I-D.draft-ietf-simple-xcap-02] is a possible mechanism to configure the behavior of the Authentication Service in an out-of-band fashion. o The attributes stored in Assertions are, for example, roles, membership to a certain organization, specific access rights or information about the authentication. A definition of most of these attributes is application dependent and not defined in this document. Since the attributes need to be understood by the entity verifying the assertions it might be necessary to describe common attributes in a future version of this document. Note that some attribute definitions are already available with SAML (such as attributes providing information about the authentication procedure). o SIP is not used as a request/response protocol for obtaining Assertions (although possible). Such a protocol is, for example, required between the Relying Party and the Asserting Party to fetch an Assertion based on a received Artifact. Note, however, that SIP is still implicitly used to request Assertions. Tschofenig, et al. Expires January 10, 2005 [Page 5] Internet-Draft Using SAML for SIP July 2004 4. SAML Introduction In SAML there are three main entities: the user, the asserting party and the relying party. The asserting party is asserting that a particular user has been given proper authorization. The relying party has to trust the asserting party with regard to the provided information and then decides whether or not to accept the assertions provided, giving different levels of privileges. The components of SAML are: o Assertions/Artifact o Request/Response protocols o Bindings o Profiles We describe each in turn below 4.1 Assertions An Assertion is a package of information including authentication statements, attribute statements and authorization decision statements. All kinds of statements do not have to be present, but at least one. An Assertion contains several elements: Issuing information: Who issued the assertion, when was it issued and the assertion identifier. Subject information: The name of the subject, the security domain and optional subject information, like public key. Conditions under which the assertion is valid: special kind of conditions like assertion validity period, audience restriction and target restriction. Tschofenig, et al. Expires January 10, 2005 [Page 6] Internet-Draft Using SAML for SIP July 2004 Additional advice: explaining how the assertion was made, for example. In an authentication statement, an issuing authority asserts that a certain subject was authenticated by certain means at a certain time. In an attribute statement, an issuing authority asserts that a certain subject is associated with certain attributes which has certain values. For example, user jon@cs.example.com is associated with the attribute 'Department', which has the value 'Computer Science'. In an authorization decision statement, a certain subject with a certain access type to a certain resource has given certain evidence that the identity is correct. Based on this, the relying party then makes the decision on giving access or not. The subject could be a human or a program, the resource could be a webpage or a web service, for example. 4.2 Artifact The artifact used in the Browser/Artifact profile, is a base-64 encoded string which 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. 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 token who references an assertion for the subject who holds the artifact. 4.3 Request/Response protocol SAML defines a request/response protocol for obtaining Assertions. The request asks for an Assertion or makes queries for authentication, attribute and authorization decisions. The response is carrying back the requested Assertion. The XML format for protocol messages are defined within an XML schema in TBD. 4.4 Bindings The bindings in SAML maps between the SAML protocol and a transport and messaging protocol. With SAML Version 1.1 there is only one binding specified, which is SAML embedded in SOAP-over-HTTP. In a binding, a transport and messaging protocol is used only for transporting the request/response mechanism. Tschofenig, et al. Expires January 10, 2005 [Page 7] Internet-Draft Using SAML for SIP July 2004 4.5 Profiles 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 respresents 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 in Figure 1 and in Figure 2. Tschofenig, et al. Expires January 10, 2005 [Page 8] Internet-Draft Using SAML for SIP July 2004 5. Assertion Handling Models As mentioned in Section 4.5, two main models can be used in SAML and therefore also with the SIP-SAML extension defined in this document: The Push and the Pull model. In the Pull model the end host requests an assertion from the Asserting Party and receives, after successful authentication and authorization, an Artifact. 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 at the Asserting Party and can later be referenced. The Relying Party later fetches the SAML Assertion after receiving a request by the user which 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. That is outside the scope of this document. 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 but removes the property of "single sign-on". +----------+ +--------------+ +--------------+ | User | | Asserting | | Relying | | | | Party | | Party | +----+-----+ +------+-------+ +------+-------+ | | | | Request Assertion | | |--------------------->| | | | | | | | | User Authentication | | | and Authorization | | |<---------------------| | |--------------------->| | | | | | | | | Artifact | | |<---------------------| | | | | | Request + Artifact | |----------------------+------------------------->| | | | | | | | | SAML request | Tschofenig, et al. Expires January 10, 2005 [Page 9] Internet-Draft Using SAML for SIP July 2004 | |<-------------------------| | | | | | | | |SAML response + Assertion | | |------------------------->| | | | | | | | Accept/Reject | |<---------------------+--------------------------| | | | Figure 1: SAML Pull model With the Push model, the user requests an Assertion from the Asserting Party. The user can also trigger the Asserting Party to attach an Assertion to the request. The Assertion, which is added to the service request, can be verified by the Relying Party without additional protocol interactions with the Asserting Party. The Assertion therefore contains enough information to authorize the service request. Using programming languages, a call-by value is implemented. Tschofenig, et al. Expires January 10, 2005 [Page 10] Internet-Draft Using SAML for SIP July 2004 +----------+ +--------------+ +--------------+ | User | | Asserting | | Relying | | | | Party | | Party | +----+-----+ +------+-------+ +------+-------+ | | | | Request Assertion | | |--------------------->| | | | | | | | | User Authentication | | | and Authorization | | |<---------------------| | |--------------------->| | | | | | | | | Assertion | | |<---------------------| | | | | | Request + Assertion | |----------------------+------------------------->| | | | | | | | Accept/Reject | |<---------------------+--------------------------| | | | Figure 2: SAML Push model The usage of SAML in HTTP-based environments and in SIP is, however, affected by some architectural differences. The main goal of realizing single-sign-on (SSO) functionality in HTTP is not the goal of this extension to SIP. The function of the entities in the Push and the Pull model are shown in Figure 1 and in Figure 2. The user has to request an Assertion at the Asserting Party and both entities mutually authenticate each other. The requested Assertion is sent to the user in a confidential manner to prevent eavesdroppers to obtain this Assertion. The Relying Party trusts the Asserting Party. It is assumed that the accessed resource is located at the Relying Party and that this entity does not become malicious or that it does not act on behalf of the user to impersonate him or her to other parties with regard to access to this resource. To prevent some degree of misuse, attributes in the Assertion limit its applicability for certain applications, servers or time frame. Signaling in SIP can, however, involve a number of entities in more Tschofenig, et al. Expires January 10, 2005 [Page 11] Internet-Draft Using SAML for SIP July 2004 complex scenarios. As an example, the scenario addressed in [I-D.ietf-sip-identity] aims to replace end-to-end authentication via S/MIME by a "mediated authentication architecture". The end hosts only need to be able to verify Assertions signed by an Authentication Service which guarantees that the sender was authenticated. Directly applying SAML to such a scenario, however, causes a problem: a SIP proxy, which securely receives a SAML Assertion (such as confidentially protected to prevent eavesdroppers between the SIP UA and the SIP proxy to learn the Assertion), can store this Assertion to impersonate the user in future requests towards other SIP end users. The fact that multiple parties see the Assertion along the path (i.e., SIP proxies) make the situation worse. The Assertion might include some attributes which restrict its usage (such as lifetime or indication of a particular resource) but they cannot fully prevent impersonation. If intermediate SIP proxies should also be able to process the Assertion then it cannot be bound to a particular receiver - the intermediate SIP proxies might not even be known to the SIP end host. This problem appears if SAML Assertions are not bound to a particular protocol run. Binding the Assertion to a particular session is not useful in the context of SSO but in many SIP scenarios there seems to be a problem if such a binding is not provided. There is little usage in requesting Assertions from a separate Authentication Service for every SIP message exchange since the additional latency and performance impact could potentially be large. Tschofenig, et al. Expires January 10, 2005 [Page 12] Internet-Draft Using SAML for SIP July 2004 6. Scenarios This section shows message flows based on scenarios in [I-D.ietf-sipping-trait-authz] enriched with a SAML based solution. Section 6.1 provides an example of enhanced network asserted identities and Section 6.2 shows a SIP conferencing scenario with role-based access control using SAML. A future version of this document will cover more scenarios from [I-D.ietf-sipping-trait-authz]. 6.1 Network Asserted Identities Figure 3 shows an enhanced network asserted identity scenario based on [I-D.ietf-sip-identity] which again utilizes extensions proposed with [I-D.ietf-sip-authid-body]. The enhancement is based on the attributes asserted by the Authentication Service. Figure 3 shows three entities, Alice@example.com, AS@example.com and Bob@example2.com. If Alice wants to communicate with Bob, she sends a SIP INVITE to her preferred AS. Depending on the chosen SIP security mechanism either digest authentication, S/MIME or Transport Layer Security is used to provide the AS with a strong assurance about the identity of Alice. During this step authorization attributes for inclusion into the SAML Header can be selected. After Alice is authenticated and authorized, a SAML assertion is attached to the SIP message. The Authentication Service can be configured to attach a number of assertions, not limited to the authenticated identity. To bind the SAML assertion to a specific SIP session, it is necessary for the AS to compute a hash of some fields of the message. A list of the fields to hash is described in [I-D.ietf-sip-identity] and particularly in [I-D.ietf-sip-authid-body]. The hash is digitally signed and inserted into the SAML assertion and placed into the SAML header. The SAML header also contains information about the identity which created the digital signature. Upon reception of the message, Bob learns the signature in the SAML header and verifies the binding to the SIP message in order to prevent cut-and-paste attacks. The provided SAML assertion can then be used to assist during the authorization procedure. If Bob does not understand the extension defined in this document, he silently ignores it. When the 200 OK message arrives at Bob's AS, the same procedure as when Alice sent her INVITE to her AS can be performed, if desired. This exchange is not shown in Figure 3. Note that this scenario does not imply that the SAML assertions are solely used by SIP UAs. Assertions can also be helpful for SIP Tschofenig, et al. Expires January 10, 2005 [Page 13] Internet-Draft Using SAML for SIP July 2004 proxies or B2B UAs. Additionally, a push model is shown in this section but it is reasonable to use a pull as well. For simplicity reasons a push model should be prefered since an additional message exchange between the Authentication Service and the UA can be omitted. +--------+ +--------------+ +--------+ |Alice@ | |Authentication| | Bob@ | |example | |Service | |example2| |.com | |@example.com | |com | | | | | | | +---+----+ +------+-------+ +---+----+ | | | | INVITE | | |---------------------->| | | From:alice@foo.com | | | | | | | | | 407 Proxy auth. req. | | |<----------------------| | | Challenge | | | | | | | | | Challenge response | | |---------------------->| | | | | | | | | | | | INVITE | | |---------------------->| | | | INVITE | | | + SAML assertion | | |--------------------->| | | | | | | | 200 OK | | |<----------------------+----------------------| | | | Figure 3: Network Asserted Identities A variation of the scenario presented in Figure 3 is given in Figure 4 where an end host (Alice@example.com) obtains an Assertion from its SIP proxy server. This assertion is then attached by the end host to the outgoing INVITE message. Unlike in case of an Artifact, Bob@example.com does not need to contact the Proxy Server. Tschofenig, et al. Expires January 10, 2005 [Page 14] Internet-Draft Using SAML for SIP July 2004 An example of this scenario could be to preempt a lower priority call if enough assurance for doing so is presented in the attached SAML assertion. This would also mean that there is a priority value included in the INVITE (for example in the Resource-Priority Header). +--------+ +--------------+ +--------+ | Alice@ | |Proxy Server | | Bob@ | |example | | | |example | |.com | |@example.com | |.com | | | | | | | +---+----+ +------+-------+ +---+----+ | | | | INVITE | | |---------------------->| | | From:alice@example.com| | | | | | | | | 407 Proxy auth. req. | | |<----------------------| | | SAML Auth Header | | | to use | | | | | | | | | INVITE + SAML assertion | |-----------------------+--------------------->| | | | | | | | | | | 200 OK | | |<----------------------+----------------------| | | | Figure 4: End host attaching SAML Assertion Note that Bob and Alice can do not need to be in the same administrative domain. It is feasible that Bob is in a domain that is federated with Alice's domain. The Assertion obtained by Alice@example.com needs to be associated with a particular SIP messaging session. How to achieve this binding is for further consideration. 6.2 SIP Conferencing This section is meant to raise some discussions about the usage of SAML in the domain of SIP conferencing. Tschofenig, et al. Expires January 10, 2005 [Page 15] Internet-Draft Using SAML for SIP July 2004 Two possible usage cases are described. The first use case describes a user who routes its SIP message through the Authentication Service (Asserting Party) to allow SAML Assertions to be included. The following goals could be achieved by this procedure: o The user identity can be replaced to have the user to be anonymous with regard to the Focus o The user identity could be asserted to the Focus o The SAML Assertion could provide additional information such as group membership (belongs to the students,staff, faculty group of university X). This could, for non-identity-based authorization system imply certain rights. The corresponding SIP message flow (in high level detail) could have the following shape: +-----+ +-----------+ +-----------+ | | | SIP Proxy | | Focus | |User | |(Asserting | | (Relying | | | | party) | | party) | +--+--+ +-----+-----+ +-----+-----+ | INVITE | | |sip:conf-factory | | |------------------>| INVITE+SAML | | |------------------>| | | | | | Ringing | | Ringing |<------------------| |<------------------| | | | | | | OK | | OK |<------------------| |<------------------| | | | | | ACK | | |------------------>| ACK | | |------------------>| | | | | | | ... many more msgs... Figure 5: SIP Conferencing and SAML In the second use case, a SIP Proxy (which acts as an Asserting Party) stores authorization policies for usage with SIP conferencing. These authorization policies could be attached by the Asserting Party Tschofenig, et al. Expires January 10, 2005 [Page 16] Internet-Draft Using SAML for SIP July 2004 for this particular session. The Focus does not need to store this type of information. These policies might not be configured by the user itself. One could think of a model similar to the Geopriv model where the rule maker does not need to be the same entity as the conferencing participant. The authorization policies defined in [I-D.niemi-xcon-cpcp-rules] could be reused. If we think of virtual 3GPP/IEEE meeting scenario then certain members have more rights than others and it must be asserted that a particular person is the member of a company and possibly some other restrictions. The SAML assertion could, for example, include (among other things): accept true Figure 6: Carrying authz. policies for SIP Conferering in SAML The identity section of the conditions part is left empty since the Assertion is attached to a request which originates from a particular entity. The identity to whom the Assertion was granted is already included in other SAML specific attributes. 6.3 PSTN-to-SIP phone call Alice, using a phone connected to the PSTN, wants to make a call to Bob, which resides in a SIP network. Her call is switched through the PSTN by means of PSTN signaling (outside the scope of this document) to the PSTN/SIP gateway. At the gateway, the call is converted from SS7 signaling to SIP signaling. Since Alice was previously properly authenticated through PSTN signaling mechanisms, the gateway can create an assertion based on signaling information from Alice and digitally sign it with it's private key. Alice's call is forwarded from the SIP/PSTN gateway to Bob's phone. Bob can certify that the identity of Alice is correct by examining the SAML assertion. Tschofenig, et al. Expires January 10, 2005 [Page 17] Internet-Draft Using SAML for SIP July 2004 +-----------+ +----------------------+ | | | | SS7 | SIP/PSTN | | Public Switched |--------------------->| Gateway | | | | | | | | | | Telephone Network | +--+-----------+----+ | ^ | | | | +---------+------------+ | | SIP+SAML | | SS7 | v | | | +--------+ | O | | | | O /|\ <----+----| SIP | | /|\ / \ SIP+ | Proxy | | / \ Bob SAML | | | Alice | +--------+ | | SIP based | | Network | +-------------------+ Figure 7: PSTN to SIP call Tschofenig, et al. Expires January 10, 2005 [Page 18] Internet-Draft Using SAML for SIP July 2004 7. Header Syntax This document specifies a new SIP header: SAML-Payload This header MUST NOT appear more than once in a SIP message. SAML-Payload = "SAML-Payload" HCOLON saml-assertion The saml-assertion field either contains a base64 encoded SAML Assertion which SHOULD be S/MIME protected or an Artifcat. An example of an Assertion is shown in Section 8 and its protection is highly recommended but not mandated by the SAML specification. If an SAML assertions is protected then S/MIME MUST be used rather than XML digital signatures. To bind a SAML assertion to a SIP message a few selected SIP message fields are input to a hash function. The digest-string, defined in Section 10 of [I-D.ietf-sip-identity], is included into the TBD element of the SAML Assertion. Tschofenig, et al. Expires January 10, 2005 [Page 19] Internet-Draft Using SAML for SIP July 2004 8. Example This is an example of a SAML assertion and how it is structured in XML. NameQualifier=alice@example.com Format="urn:oasis:names:tc:SAML:1.1:nameid- format:emailAddress">uid=alice urn:oasis:names:tc:SAML:1.0: cm:SIP-artifact-01 The elements in the Assertion have the following meaning: +---------------------+-----+-------------------------------+ | Tag name |Req- | Description | | |uired| | +---------------------+-----+-------------------------------+ |MajorVersion | X |Major version of the assertion | +---------------------+-----+-------------------------------+ |MinorVersion | X |Minor version of the assertion | +---------------------+-----+-------------------------------+ |AssertionID | X |ID of the assertion | +---------------------+-----+-------------------------------+ |Issuer | X |The name of the SAML authority | | | |that created the assertion | Tschofenig, et al. Expires January 10, 2005 [Page 20] Internet-Draft Using SAML for SIP July 2004 +---------------------+-----+-------------------------------+ |IssuerInstant | X |Issuing time of the assertion | +---------------------+-----+-------------------------------+ | | |Conditions that MUST be taken | |Conditions | |into account when assessing | | | |the validity of the assertion | +---------------------+-----+-------------------------------+ | | |A URI reference that specifies | |AuthenticationMethod | X |what kind of authentication | | | |took place | +---------------------+-----+-------------------------------+ |AuthenticationInstant| X |Specifies the time when the | | | |authentication took place | +---------------------+-----+-------------------------------+ |Qualifier | |The name by which the subject | | | |is recognized | +---------------------+-----+-------------------------------+ | | |A URI reference representing | |Format | |the format of NameIdentifier | | | | | +---------------------+-----+-------------------------------+ | | |Specifies a subject by supply- | |SubjectConfirmation | |ing data that allows the sub- | | | |ject to be authenticated | +---------------------+-----+-------------------------------+ | | |A URI reference who identifies | |ConfirmationMethod | |which method to be used for | | | |authenticating the subject | +---------------------+-----+-------------------------------+ Figure 9: Tag descriptions Tschofenig, et al. Expires January 10, 2005 [Page 21] Internet-Draft Using SAML for SIP July 2004 9. Requirement Comparison A future version of this document will compare the requirements listed in [I-D.ietf-sipping-trait-authz] with the solution provided in this document. Tschofenig, et al. Expires January 10, 2005 [Page 22] Internet-Draft Using SAML for SIP July 2004 10. Security considerations This section discusses security considerations when using SAML with SIP. 10.1 Stolen Assertion Threat: If an eavesdropper can copy the real user's SAML response and included assertions and construct it's own SIP message, then the eavesdropper could be able to impersonate the user at other SIP entities. Countermeasures: By providing adequate confidentiality, eavesdropping of a SAML assertion can be stopped. 10.2 MitM Attack Threat: Since the SAML assertion is carried within a SIP message, a malicious site could impersonate the user at some other SIP entities. These SIP entities would believe the adversary to be the subject of the assertion. Countermeasures: If the adversary is a not-participating in the SIP signaling itself (i.e., it is not a SIP proxy or a SIP UA), this threat can be eliminated by employing inherent SIP security mechanisms, such as TLS. However, if this entity is part of the communication itself then reference integrity needs to be provided. Assertions with tight restrictions (e.g., validity of the assertion) can also limit the possible damage. 10.3 Forged Assertion Threat: A malicious user could forge or alter a SAML assertion in order to communicate with the SIP entities. Countermeasures: To avoid this kind of attack, the entities must assure that proper mechanisms for protecting the SAML assertion needs to be in place. It is recommended to protect the Assertion using a digital signature. 10.4 Replay Attack Threat: In the case of using SIP with the SAML pull model, the threat of replay lies in the fact that the artifact is a one-time-use subject. The same artifact can be used again to gain access to resources. Countermeasures: Cases where multiple requests are made which Tschofenig, et al. Expires January 10, 2005 [Page 23] Internet-Draft Using SAML for SIP July 2004 references the same request must be tracked in order to avoid the threat. Tschofenig, et al. Expires January 10, 2005 [Page 24] Internet-Draft Using SAML for SIP July 2004 11. Contributors The authors would like to thank Henning Schulzrinne for their input to this document. Tschofenig, et al. Expires January 10, 2005 [Page 25] Internet-Draft Using SAML for SIP July 2004 12. IANA Considerations This document contains a number of IANA considerations. A future version of this document will list them in this section. Tschofenig, et al. Expires January 10, 2005 [Page 26] Internet-Draft Using SAML for SIP July 2004 13. Open issues During the work on this document a number of open issues have been discovered: o It needs to be studied how the interworking between reference integrity and the usage of obtained SAML assertion can be properly accomplished. o In Section 7, it suggests that an S/MIME protected SAML assertion could appear by-value in a SIP header. This issue deserves further investigations. If by-value inclusion is required, then at best, this header might contain a "cid:" URL. This allows you to point to a particular MIME body in the body of a SIP message. However, proxy servers cannot add bodies to SIP requests, and so this would be a UA-only approach. o Where should the Assertions be attached? At the UA or at the proxy? In the scenarios depicted in Section 6, we have both approaches depending on what kind of scenario it is. In Figure 3, they are added at the UA and in contrast we have Figure 7, where the assertions are added at the PSTN/SIP gateway. MIME bodies can only be attached at the UA. Proxies by definition do not attach MIME bodies; if an intermediary were to do so, it would not be playing the proxy server role in the SIP architecture. If an assertion needs to be added by-value, something like the redirection-based mechanism originally in the identity draft would be appropriate. This issue is for further study. o The usage of the SAML artifact from HTTP to provide by-reference carriage of the assertion needs further study. The HTTP artifact assumes that the recipient will know how to dereference the artifact, which for various reasons in the HTTP binding makes sense, but in SIP might not. The authors think that it would be good to provide a URL associated with the asserting party, one which might also contain the artifact (i.e. http://asserting-party.com/artifact), or parts of the artifact, that are necessary to index to a particular assertion being held by the asserted party. Hence, an HTTPS URL has to be used for this purpose. Otherwise, given the very peer-to-peer nature of SIP it is possible that the artifact will not give you enough information to be able to figure out how to contact the asserting party. o Some work on option-tags is required. Are there cases when processing of the assertion would be required by the sender? Or Tschofenig, et al. Expires January 10, 2005 [Page 27] Internet-Draft Using SAML for SIP July 2004 when a proxy server wants to be able to say that a UA must supply this header in order to access a particular resource? If so (and I think so), an option-tag should be defined for this extension that can be used in Require, Supported, 420, etc. o Specific SAML confirmation method identifiers and identifiers for the bindings or profiles must be defined and registrered with OASIS. A confirmation method identifier is a URI that specifies which method should be used by the target domain to assure that the identity of the subject is true. This mechanism seems to be provide the same reference integrity properties as the hash over the various headers/bodies proposed in the identity draft. o A few new URIs need to be registered. The proposed URIs for identification are: * SIP Binding: urn:oasis:names:tc:SAML:1.0:bindings:SIP-binding * Artifact profile: urn:oasis:names:tc:SAML:1.0:profiles:SIP-artifact-01 * Assertion profile: urn:oasis:names:tc:SAML:1.0:profiles:SIP-assertion-01 o The proposed URIs for Confirmation Method Identifiers are: * Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01 * Assertion profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer o These are based on the URIs already used in the existing SOAP-SAML binding, specified in Section 3 of [I-D.saml-bindings-1.1]. o An alignment with the work done by Liberty Alliance on Federated Identities as described in [I-D.liberty-idff-arch-overview] would be useful. o The security consideration needs more details. Tschofenig, et al. Expires January 10, 2005 [Page 28] Internet-Draft Using SAML for SIP July 2004 14. References 14.1 Normative References [I-D.ietf-sipping-trait-authz] Peterson, J., "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)", draft-ietf-sipping-trait-authz-00 (work in progress), February 2004, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 14.2 Informative References [I-D.draft-ietf-simple-xcap-02] Rosenberg, J., "Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02 (work in progress), February 2004, . [I-D.ietf-sip-authid-body] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", draft-ietf-sip-authid-body-03 (work in progress), May 2004, . [I-D.ietf-sip-identity] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-02 (work in progress), May 2004, . [I-D.liberty-idff-arch-overview] Wason, T., "Liberty ID-FF Architecture Overview", 2004, . [I-D.niemi-xcon-cpcp-rules] Niemi, A., "Conference Policy Authorization Rules", draft-niemi-xcon-cpcp-rules-00 (work in progress), May 2004, . [I-D.saml-bindings-1.1] Maler, E., Philpott, R. and P. Mishra, "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003, . Tschofenig, et al. Expires January 10, 2005 [Page 29] Internet-Draft Using SAML for SIP July 2004 [I-D.saml-core-1.1] Maler, E., Philpott, R. and P. Mishra, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", September 2003, . [I-D.saml-sec-consider-1.1] Maler, E. and R. Philpott, "Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V1.1", September 2003, . [I-D.saml-tech-overview-1.1-03] Maler, E. and J. Hughes, "Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1", March 2004, . [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999, . Authors' Addresses Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US EMail: jon.peterson@neustar.biz Tschofenig, et al. Expires January 10, 2005 [Page 30] Internet-Draft Using SAML for SIP July 2004 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 US EMail: jmpolk@cisco.com Douglas C. Sicker University of Colorado at Boulder ECOT 531 Boulder, CO 80309 US EMail: douglas.sicker@colorado.edu Marcus Tegnander Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Tschofenig, et al. Expires January 10, 2005 [Page 31] Internet-Draft Using SAML for SIP July 2004 Appendix A. SAML Artifact format TypeCode := 0x0001 RemainingArtifact := SourceID AssertionHandle SourceID := 20-byte_sequence AssertionHandle := 20-byte_sequence The sourceID is a 20-byte sequence which is used by the destination domain to determine the identity and location of the source domain. It is assumed that the destination domain will maintain a table of sourceID values as well as URLs for the domains it is having SAML sessions with and this information is communicated out-of-band. When the destination receives the SAML artifact, it determines if the source domain belongs to a known source domain and obtains the location before sending a SAML request. If two source domains communicating with the same target domain MUST be distinguished by unique SourceIDs. The AssertionHandle is constructed on the basis that they SHOULD not have any predictable relationship to the contents of the assertion and that it MUST be not worth the effort to reconstruct or guess the value of the AssertionHandle. In [I-D.saml-bindings-1.1] section 4.1.1.8, some RECOMMENDED practices for creation of SAML artifacts are listed. Tschofenig, et al. Expires January 10, 2005 [Page 32] Internet-Draft Using SAML for SIP July 2004 Intellectual Property Statement 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 ietf-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig, et al. Expires January 10, 2005 [Page 33]