SIP SAML Profile and Binding

This document specifies composition of the Security Assertion Markup Language (SAML) V2.0 with SIP in order to accommodate richer authorization mechanisms and enable "trait-based authorization". Trait-based authorization is where one is authorized to make use of some resource based on roles or traits rather than ones identity. Motivations for trait-based authorization, along with use-case scenarios, are presented in . Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML-based framework for creating and exchanging security information. and provide non-normative overviews of SAMLv2. The SAMLv2 specification set is normatively defined by . Various means for encoding authorization information exists, such as authorization certificates , SPKI , or extensions to the authenticated identity body . This document focuses on an encoding of the authorization information using SAML assertions but does not exclude other formats to be used utilized in the future.

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 . The SIP network element "Authentication Service" is introduced in . We reuse this term to refer to a network element that authenticates and authorizes a user and creates a "SIP identity assertion". This system entity is the logical equivalent of a "SAML Authority" in the SAML terminology. For overall SIP terminology, see . In this specification, the term, or term component, "SAML" refers to SAML V2.0 in all cases. For example, the term "SAML assertion" implicitly means "SAMLv2 assertion". For overall SAML terminology, see . The below list maps other various SIP terms to their SAML (rough-)equivalents: System Entity, Entity SAML Authority Relying Party SAML Responder SAML Requester Additional terms defined in the context of this specification: one or more attributes of a "user profile". the set of various attributes accompanying (i.e., mapped to) a user account in many environments.

SAML defines an XML-based framework for exchanging "security assertions" between entities. In the course of making, or relying upon such assertions, SAML system entities may use SAML protocols, or other protocols, to communicate an assertion itself, or the subject of an assertion. Thus one can employ SAML to make and encode statements such as "Alice has these profile attributes and her domain's certificate is available over there, and I'm making this statement, and here's who I am." Then one can cause such an assertion to be conveyed to some party who can then rely on it in some fashion for some purpose, for example input it into some local policy evaluation for access to some resource. This is done in a particular "context of use". Such a context of use could be, for example, deciding whether to accept and act upon a SIP-based invitation to initiate a communication session. The specification of how SAML is employed in a particular context of use is known as a "SAML profile". The specification of how SAML assertions and/or protocol messages are conveyed in, or over, another protocol is known as a "SAML Binding". Typically, a SAML profile specifies the SAML bindings that may be used in its context. Both SAML profiles and SAML bindings reference other SAML specifications, especially the SAML Assertions and Protocols, aka "SAML Core", specification . There is an additional subtle aspect of SAML profiles that is worth highlighting -- the notion of a "SAML assertion profile". A SAML assertion profile is the specification of the assertion contents in the context of a particular SAML profile. It is possibly further qualified by a particular implementation and/or deployment context. Condensed examples of SAML assertion profiles are: The SAML assertion must contain at least one authentication statement and no other statements. The relying party must be represented in the <AudienceRestriction> element. The SubjectConfirmation Method must be Foo. etc. The SAML assertion must contain at least one attribute statement and may contain more than one. The values for the subject's profile attributes named "Foo" and "Bar" must be present. An authentication statement may be present. etc. The primary facets of SAML itself are: Assertions Abstract Request/Response protocol We describe each in turn below:

A SAML assertion is a package of information including issuer and subject, conditions and advice, and/or attribute statements, and/or authentication statements and/or other statements. Statements may or may not be present. The SAML assertion "container" itself contains the following information: Who issued the assertion, when was it issued and the assertion identifier. The name of the subject, the security domain and optional subject information, like public key. Special kind of conditions like assertion validity period, audience restriction and target restriction. Explaining how the assertion was made, for example. In terms of SAML assertions containing SAML attribute statements or SAML authentication statements, here are explanatory examples: With a SAML assertion containing a SAML attribute statement, an issuing authority is asserting that the subject is associated with certain attributes with certain subject profile attribute values. For example, user jon@cs.example.com is associated with the attribute "Department", which has the value "Computer Science". With a SAML assertion containing a SAML authentication statement, an issuing authority is asserting that the subject was authenticated by certain means at a certain time. With a SAML assertion containing both a SAML attribute statement and a SAML authentication statement, an issuing authority is asserting the union of the above.

SAML defines an abstract request/response protocol for obtaining assertions. See Section 3 "SAML Protocols" of . A request asks for an assertion. A response returns the requested assertion or an error. This abstract protocol may then be cast into particular contexts of use by binding it to specific underlying protocols, e.g., HTTP or SIP, and "profiling" it for the specific use case at hand. The SAML HTTP-based web single sign-on profile is one such example (see Section 4.1 Web Browser SSO Profile of ). Trait-based SIP communication session establishment, the topic of this specification, is another.

The scope of this specification is: Specify a SIP profile of SAML -- also known as a "SIP SAML profile" -- such that a subject's profile attributes, and their domain's certificate, can be conveyed to a relying party using SAML. In doing so, satisfy the requirements outlined in , and compose with . The following are outside the scope of this specification: Defining a means for configuring the runtime behavior, or deployment characteristics, of the Authentication Service. Discussion: For example, a SIP Authentication Service could be implemented such that its SAML-based features are employed, or not, on a subject-by-subject basis, and/or on a domain-by-domain basis. The definition of specific conveyed subject profile attributes (aka traits). Discussion: This specification defines a facility enabling "trait-based authorization" as discussed in . The attributes of interest in trait-based authorization will be ones akin to, for example: roles, organizational membership, access rights, or authentication event context. Definition of such attributes is application- and/or deployment-context-dependent and are not defined in this specification. However, The SAMLv2 specification defines several "SAML Attribute Profiles" for encoding attributes from various application domains, e.g., LDAP, UUID/GUID, DCE PAC, and XACML, in SAML assertions . In order for any trait-based system to be practical, participating entities must agree on attributes and traits that will be conveyed and subsequently relied upon. Without such agreements, a trait-based system cannot be usefully deployed. This specification does not discuss the manner in which participating entites might discover one another or agree on the syntax and semantics of attributes and traits. Note that SAMLv2 specifies a "metadata" facility that may be useful in addressing this need.

Employing SAML in SIP necessitates devising a new SAML profile(s) and binding(s) because those already specified in the SAMLv2 specification set are specific to other use contexts, e.g., HTTP-based web browsing. Although SIP bears some similarity to HTTP, it is a seperately distinct protocol, thus requiring specification of SIP-specific SAML profile(s) and binding(s). This is technically straightforward as both SAML and SIP are explicitly extensible. The SIP SAML Profiles defined in this document make use of concepts defined by "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" -- also known as "SIP Identity". SIP Identity allows the SIP UA client and an entity on behalf of the UA client to attach a SAML assertion (or a reference to it). Since intermediaries, like an outbound SIP proxy, are not allowed to modify the body of a SIP message such an intermediary would attach a pointer to the assertion instead. The specific details on how the SAML assertion is requested are outside the scope of this document. Possible mechanisms are to use a software library that can be accessed via an API, a separate authorization server that can be queried via HTTP (as envisioned the 'OAuth Web Resource Authorization Profiles' specification ), or any other mechanism. As such, this document does not further describe the functional split between the party that attaches the SAML assertion to the SIP message and the party that creates the SAML assertion. The SIP Identity specification calls the party that makes identity assertions about the caller "Authentication Service (AS)". Such an Authentication Service, which likely has access to various pieces of information concerning the calling party, could also act as a SAML Authority, and make such information available to the callee via SAML. This document uses the term SAML Authority and Authentication Service interchangable particularly because of the fact that the entity that attaches the SAML assertion to the SIP message also uses the SIP Identity mechanism to bind it to the message. Note that technically there is a difference between attaching a reference to a SAML assertion and attaching a SAML assertion to the body of a message. We define two different profiles to cover these two cases: In case of this profile the AS attaches a reference to a SAML assertion to the SIP message and makes it available to the verifier. More details about this profile can be found in . In case of this profile the SAML assertion is made available to the verifying party directly without the additional step of utilizing a reference. This approach is described in .

This document represents the URL pointing to the authorization information using a URI parameter. The grammar for this parameter is (following the ABNF in Section 25 of RFC 3261 ):

The "absoluteURI" MUST contain a URI which dereferences to a resource containing a SAML assertion. All implementations of this specification MUST support the use of HTTP and HTTPS URIs. Such HTTP and HTTPS URIs MUST follow the conventions of RFC 2585 , and for those URIs the indicated resource MUST be of the form 'application/samlassertion+xml' described in that specification. An example of the syntax of the "token-info" parameter is given below:

; tag=1928301774 ]]>

This section defines two "SIP SAML profiles": The "AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile" The "Assertion-by-Value" Profile

The information given in this section is similar to the info provided when registering something, a MIME Media Type, say, with IANA. In this case, it is for registering this profile with the OASIS SSTC. See Section 2 "Specification of Additional Profiles" in . urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 Hannes Tschofenig (Hannes.Tschofenig@nsn.com) The SAML V2.0 confirmation method identifier is used in this profile. Given below. None.

illustrates this profile's overall protocol flow. The following steps correspond to the labeled interactions in the figure. Within an individual step, there may be one or more actual message exchanges depending upon the protocol binding employed for that particular step and other implementation-dependent behavior. Although this profile is overview is cast in terms of a SIP INVITE transaction, the reader should note that the mechanism specified herein, may be applied to any SIP request message. begins on the next page.

| | (1a) | | From:alice@foo.com | | | C | To:sip:bob@example.com| | | S | | | | e | 407 Proxy auth. req. | | | q |<----------------------| | (1b) | = | Challenge | | | N | | | | | ACK | | | | |---------------------->| | (1c) | V | | | | - | | | ^ | INVITE + authorization| | D | | header w/ creds | | | |---------------------->| | (2) I | | From:alice@foo.com | | | | To:sip:bob@example.com| | A | Proxy-Authorization:..| | C | | INVITE | L S | |--------------------->| (3) e | | From:alice@foo.com | O q | | To:sip:bob@example2.com | | | G = | | token-info: | | | https://example.com| | N | | /assns/?ID=abcde | | | | | | + | |URI resolution (eg. HTTP) | | |<=====================| (4) | 1 | | GET /assns/?ID=abcde | | | | | | | | | HTTP/1.1 200 OK | | | | |=====================>| (5) | | | | | | | | | | | | | | | | | | | Alice@example.com | | | | | | | | | | | | ... | | | | | | | | foo=bar | | | | 200 OK | | | V |<----------------------+----------------------| (6) . - | | | V ]]> Initial SIP Transaction between Caller and AS This optional initial step is comprised of substeps 1a, 1b, and 1c in . In this step, the caller, Alice, sends a SIP request message, illustrated as an INVITE, indicating Bob as the callee (1a), is subsequently challenged by the AS (1b), and sends an ACK in response to the challenge (1c). The latter message signals the completion of this SIP transaction (which is an optional substep of this profile). Caller sends SIP Request Message with Authorization Credentials to the AS Alice then sends an INVITE message in response to the challenge, or uses cached credentials for the domain if step 1 was skipped, as specified in and . Depending on the chosen SIP security mechanism for client authentication either digest authentication, client side authentication of Transport Layer Security, or a combination of both is used to provide the AS with a strong assurance about the identity of Alice. AS Authorizes the SIP Request and Forwards it to Callee First, the AS authorizes the received INVITE message as specified in and . If the authorization is successful, the AS constructs and caches a SAML assertion asserting Alice's profile attributes required by Bob's domain (example2.com), and also containing a the domain's (example.com) public key certificate, or a reference to it. The AS constructs a HTTP-based SAML URI Reference incorporating the assertion's Assertion ID (see Section 2.3.3 of ). The AS uses this URI and puts the value into the token-info parameter. The AS determines which profile attributes (if any) to assert in the <AttributeStatement> via local configuration and/or obtaining example2.com's metadata . The AS then sends the updated INVITE message to Bob. Callee Dereferences HTTP-based SAML URI Reference Bob's UAC or SIP Proxy receives the message and begins verifying it per the "Verifier Behavior" specified in . In order to accomplish this task, it needs to obtain Alice's domain certificate. It obtains the HTTP-based SAML URI reference from the message's token-info parameter and dereferences it per . Note that this is not a SIP message, but an HTTP message . AS Returns SAML Assertion Upon receipt of the above HTTP request, which contains an embedded reference to Alice's SAML Assertion, Alice's AS returns her assertion in an HTTP response message. Upon receipt of Alice's SAML Assertion, the AS continues its verification of the INVITE message. If successful, it returns a 200 OK message directly to Alice. Otherwise it returns an appropriate SIP error response. Callee Returns SIP 200 OK to Caller If Bob determines, based upon Alice's identity as asserted by the AS, and as further substantiated by the information in the SAML assertion, to accept the INVITE, he returns a SIP 200 OK message directly to Alice.

The following sections provide detailed definitions of the individual profile steps. The relevant illustration is , below. Note that this profile is agnostic to the specific SIP request, and also that the Sender and Authentication Service (AS) may be seperate or co-located in actuality.

| | (1a) | | | | 407 Proxy auth. req. | | |<----------------------| | (1b) | Challenge | | | | | | ACK | | |---------------------->| | (1c) | | | | | | |SIP Req + authorization| | | header w/ creds | | |---------------------->| | (2) | | | | | | | | SIP Req + token-info | | |--------------------->| (3) | | | | | URI resolution | | |<=====================| (4) | | (via HTTP) | | | | | | HTTP/1.1 200 OK | | |=====================>| (5) | | | | | | | | ? | (6) | | | ]]>

This optional step maps to Steps 1 and 2 of Section 5 "Authentication Service Behavior" of . If the SIP request sent by the caller in substep 1a is deemed insufficiently authenticated by the AS per the rules stipulated by Steps 1 and 2, then the AS MUST authenticate the sender of the message. The particulars of how this is accomplished depend upon implementation and/or deployment instantiation as discussed in . Substeps 1b and 1c as shown in are non-normative and illustrative only.

This step maps to Steps 1 and 2 of Section 5 "Authentication Service Behavior" of . This request is presumed to be made in a context such that the AS will not challenge it -- i.e., the AS will consider the sender of the message to be authenticated. If this is not true, then this procedure reverts back to Step 1, above. Otherwise, the AS carries out all other processing of the message as stipulated in Steps 1 and 2, and if successful, this procedure procedes to the next step below.

This first portion of this step maps to Steps 3 and 4 of Section 5 "Authentication Service Behavior" of , which the AS MUST perform, although with the following additional substeps: The AS MUST construct a SAML assertion according to the "" specified in of this specification. The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI per Section "3.7.5.1 URI Syntax" of . The AS MUST use the URI constructed in the immediately preceding substep as the value of the token-info parameter that is added to the SIP request message. Upon successful completion of all of the above, the AS forwards the request message. At this point in this step, after perhaps traversing some number of intermediaries, the SIP request message arrives at a SIP network entity performing the "verifier" role. This role and its behavior are specified in Section 6 "Verifier Behavior" of . The verifier MUST perform the steps enumerated in the aforementioned section, with the following modifications: Step 1 of Section 6 maps to and is updated by, the following two steps in this procedure. Steps 2, 3, and 4 of Section 6 may be mapped across this latter portion of this step, and/or the following two steps, as appropriate.

The verifier SHOULD ascertain whether it has a current cached copy of the SIP message sender's SAML assertion and domain certificate. If not, or if the verifier chooses to (e.g., due to local policy), it MUST dereference the the HTTP-based SAML URI Reference found in the SIP message's token-info parameter. To do so, the verifier MUST employ the "" specified in .

This step also employs "". If the prior step returns an HTTP error (e.g., 4xx series), then this procedure terminates and the verifier returns (upstream) a SIP 436 'Bad token-info' Response code. Otherwise, the HTTP response message will contain a SAML assertion and be denoted as such via the MIME media type of "application/samlassertion+xml" . The verifier MUST perform the verification steps specified in "", below. If successful, then this procedure continues with the next step.

The SIP request was successfully processed. The verifier now performs its next step, which depends at least in part on the type of SIP request it received.

For the "Assertion-by-value" profile we assume that a SAML assertion is obtained out-of-band and attached to the body of the SIP message. Note that any SIP message may be used to convey the SAML assertion even though SIP INVITE may be the most appropriate candiate. The verification step described in is applicable to this profile as well as the description on the content of the assertion illustrated in .

This section provides some guidance on what information should be put into a SAML assertion by the SAML Authority and how that information is then used by the Verifier.

The schema for SAML assertions themselves is defined in Section 2.3 of . An example SAML assertion, formulated according to this profile is given in . Overall SAML assertion profile requirements: If a SAML assertion is signed then it MUST be signed by the same key that is used in the Transport Layer Security mechanism utilized with HTTPS. Signing of SAML assertions is defined in Section 5.4 of . In the following subsections, the SAML assertion profile is specified element-by-element, in a top-down, depth-first manner, beginning with the outermost element, "<Assertion>". Where applicable, the requirements for an element's XML attributes are also stated, as a part of the element's description. Requirements for any given element or XML attribute are only stated when, in the context of use of this profile, they are not already sufficiently defined by .

The value for the ID XML attribute SHOULD be allocated randomly such that the value meets the randomness requirments specified in Section 1.3.4 of . The value for the IssueInstant XML attribute SHOULD be set at the time the SAML assertion is created (and cached for subsequent retrieval). This time instant value MAY be temporally the same as that encoded in the SIP message's Date header, and MUST be at least temporally later, although it is RECOMMENDED that it not be 10 minutes or more later.

The value for the Issuer XML element MUST be a value that matches either the Issuer or the Issuer Alternative Name fields in the certificate conveyed by the SAML assertion in the ds:X509Certificate element located on this path within the SAML assertion:

<Assertion <ds:Signature <ds:KeyInfo <ds:X509Data <ds:X509Certificate

The <Subject> element SHOULD contain both a <NameID> element and a <SubjectConfirmation> element. The value of the <NameID> element MUST be the Address of Record (AoR). The <SubjectConfirmation> element attribute Method SHOULD be set to the value: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches Although it MAY be set to some other implementation- and/or deployment-specific value. The <SubjectConfirmation> element itself SHOULD be empty.

The <Conditions> element SHOULD contain an <AudienceRestriction> element, which itself SHOULD contain an <Audience> element. When included the value of the <Audience> element MUST be the same as the addr-spec of the SIP request's To header field. The following XML attributes of the <Conditions> element MUST be set as follows: The value of the NotBefore XML attribute MUST be set to a time instant the same as the value for the IssueInstant XML attribute discussed above, or to a later time. The value of the NotOnOrAfter XML attribute MUST be set to a time instant later than the value for NotBefore.

The SAML assertion MAY contain an <AttributeStatement> element. If so, the <AttributeStatement> element will contain attribute-value pairs, e.g., of a user profile nature, encoded according to either one of the "SAML Attribute Profiles" as specified in , or encoded in some implementation- and/or deployment-specific attribute profile. The attribute-value pairs SHOULD in fact pertain to the entity identified in the SIP From header field, since a SAML assertion formulated per this overall section is stating that they do.

This section specifies the steps that a verifier has to perform to verify a SAML assertion created according to the profile from . The steps are: Before Step 1 in Section 6 of , the verifier MUST extract the AS's domain certificate from the <ds:X509Certificate> XML element at the end of the element path given in . Perform Step 1 in Section 6 of . After Step 1 in Section 6 of , but before Step 2 of that section, the verifier MUST verify the SAML assertion's signature via the procedures specified in Section 5.4 of as well as . The 479 'Invalid SAML Assertion' response code is used when the verifier is unable to process the SAML assertion. Perform Step 2 in Section 6 of . Verify that the signer of the SIP message's Identity header field is the same as the signer of the SAML assertion, if SIP Identity is used to bind the token-info parameter to the SIP signaling message. Note that without such protection certain attacks are feasible as described in . Verify that the content of the SAML assertion matches with the information carried in the SIP message. This may include the following checks: Verify that the SAML assertion's <Issuer> element value matches the Issuer or the Issuer Alternative Name fields in the AS's domain certificate. Verify that the SAML assertion's <NameID> element value is the same as the Address of Record (AoR) value. Verify that the SAML assertion's <SubjectConfirmation> element value is set to whichever value was configured at implementation- or deployment-time. The default value is: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches Verify that the SAML assertion contains an <Audience> element, and that its value matches the value of the addr-spec of the SIP To header field. Verify that the validity period denoted by the NotBefore and NotOnOrAfter attributes of the <Conditions> element meets the requirements given in .

This section specifies one SAML SIP Binding at this time. Additional bindings may be specified in future revisions of this specification. The description in is applicable to this profile.

This section specifies the "SAML HTTP-URI-based SIP Binding", (SHUSB). The SHUSB is a profile of the "SAML URI Binding" specified in Section 3.7 of . The SAML URI Binding specifies a means by which SAML assertions can be referenced by URIs and thus be obtained through resolution of such URIs. This profile of the SAML URI Binding is congruent with the SAML URI Binding -- including support for HTTP-based URIs being mandatory to implement -- except for the following further restrictions which are specified in the interest of interoperability (section numbers refer to ): Support for TLS 1.0 or SSL 3.0 is mandatory to implement. All SHOULDs in this section are to be interpreted as MUSTs.

This section presents two examples of a SAML assertion, one unsigned (for clarity), the other signed (for accuracy). In the first example, , the assertion is attesting with respect to the subject (lines 7-15) "Alice@example.com" (line 11). The validity conditions are expressed in lines 16-23, via both a validity period expressed as temporal endpoints, and an "audience restriction" stating that this assertion's semantics are valid for only the relying party named "example2.com". Also, the assertion's issuer is noted in lines 4-5. The above items correspond to some aspects of this specification's SAML assertion profile, as noted below in Security Considerations dicussions, see: and . In lines 24-36, Alice's telephone number is conveyed, in a "typed" fashion, using LDAP/X.500 schema as the typing means.

4 5 example.com 6 7 8 11 Alice@example.com 12 13 15 16 18 19 20 example2.com 21 22 23 24 25 32 33 +1-888-555-1212 34 35 36 37 ]]> In the second example, , the information described above is the same, the addition is that this version of the assertion is signed. All the signature information is conveyed in the <ds:signature> element, lines 7-47. Thus this assertion's origin and its integrity are assured. Since this assertion is the same as the one in the first example above, other than having a signature added, the second example below addresses the same Security Considerations aspects, plus those requiring a Signature.

4 5 example.com 6 7 8 9 11 13 15 16 19 22 26 27 28 30 31 Kclet6XcaOgOWXM4gty6/UNdviI= 32 33 34 35 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 37 38 39 40 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 44 45 46 47 48 49 52 Alice@example.com 53 54 56 57 59 60 61 example2.com 62 63 64 65 66 73 74 +1-888-555-1212 75 76 77 78 ]]>

This section discusses security considerations when using SAML with SIP.

By making SAML assertions available via HTTP-based requests by a potentially unbounded set of requesters, it is conceivably possible that anyone would be able to simply request one and obtain it. By SIP intermediaries on the signaling path for example. Or, an HTTP intermediary/proxy could intercept the assertion as it is being returned to a requester. The attacker could then attempt to utilize the SAML assertion in another exchange in order to impersonate the subject (the putative caller) to some SIP-based target entity. Such an attack is implausible for several reasons. The primary reason is that a message constructed by an imposter using a stolen assertion that conveys the public key certificate of some domain will not verify because the values in the SAML assertion, which are tied to the SIP message, will not verify. Furthermore, the SIP SAML assertion may contain restrictions regarding the parties it can be used by. Finally, the assertion should be signed and thus causing any alterations to break its integrity and make such alterations detectable.

The ability for other entities to obtain additional information about an individual, such as role in an organization or other authorization relevant information raises privacy concerns. Since the SAML assertion itself is not confidentiality protected nor the exchange of the reference to the SAML assertion an intermediary or a third party adversary would be allowed to gain additional information about an individual To address the threats three cases need to be differentiated. First, a third party that did not participate in any of the exchange is prevented from eavesdropping on the content of the SAML assertion by employing confidentiality protection of the SIP signaling exchange as well as the HTTP exchange. This ensures that an eavesdropper on the wire is unable to obtain information. However, this does not prevent intermediaries, such as SIP proxies from observing a URL to a SAML assertion (in the token-info parameter). To deal with this second type of attacker depending on the environment where such a threat must be addressed it is necessary to authenticate the entity that tries to resolve the reference to a SAML assertion and to only provide a positive response (with the SAML assertion) if the requestor is authorized to obtain the desired information. When a SAML assertion is carried inband then such a protection is more difficult to accomplish as the SAML assertion would have to be confidentiality protected with the key of the intented recipient, for example using S/MIME. Finally, the last type of threat concerns the intented recipient of the SAML assertion itself. Proper permissions for the distribution of information about the caller via the content of the SAML assertion to certain recipients need to be available. This permission must be provided by the caller itself or, in certain circumstances, by someone on behalf of the caller. From a technical point of view, some form of authorization policies will be required.

A malicious user could forge or alter a SAML assertion in order to communicate with the SIP entities. To avoid this kind of attack, the entities must assure that proper mechanisms for protecting the SAML assertion are employed, e.g., signing the SAML assertion itself or protecting the transport of the SAML assertion from the AS to the verifying party using TLS. Section 5.1 of specifies the signing of SAML assertions. Additionally, the assertion content dictated by the SAML assertion profile herein ensures ample evidence for a relying party to verify the assertion and its relationship with the received SIP request.

Theft of SIP message protected by the mechanisms described herein and replay of it at a later time. The SAML assertion may contain several elements to prevent replay attacks. There is, however, a clear tradeoff between the replaying an assertion and re-using it over multiple SIP exchanges/sessions. Additionally, the SAML assertion can be tied to the SIP exchange with the help of the SIP Identity mechanism. RFC 4474 signs certain header fields and the SIP message body and thereby helps to protect message modifications. If a recipient knows that all messages from a certain originator arrive with SIP Identity protection applies then downgrading attacks are not possible.

The authors would like to thank Marcus Tegnander and Henning Schulzrinne for his contributions to earlier versions of this document.

We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen Fries and Vijay Gurbani for their comments to this draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based on an idea by Jon Peterson.

When a SAML assertion is attached to the body of the message then the "application/samlassertion+xml" MIME media type is used. This MIME type is already registered with IANA and no further action is required from IANA.

This document extends the registry of URI parameters, as defined RFC 3969 with the following value: Parameter Name: token-info Predefined Values: No Reference: This document

This document registers a new SIP response code. It is sent when a verifier receives a SAML assertion but the Subject and Condition elements cannot be matched to the content in the SIP message, i.e., the binding between the SIP message and the SAML assertion cannot be accomplished. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. Response Code Number: 477 Default Reason Phrase: Binding to SIP Message failed

This document registers a new SIP response code. It is used when the verifier is unable to parse the content of the SAML assertion, because, for example, the assertion contains only unknown elements in in the SAML assertion, or the SAML assertion XML document is garbled. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. Response Code Number: 478 Default Reason Phrase: Unknown SAML Assertion Content

This document registers a new SIP response code. It is used when the verifier is unable to process the SAML assertion. A verifier may be unable to process the SAML assertion in case the assertion is self-signed, or signed by a root certificate authority for whom the verifier does not possess a root certificate. This response code is defined by the following information, which has been added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. Response Code Number: 479 Default Reason Phrase: Invalid SAML Assertion

RFC Editor - Please remove this section before publication.

Undo changes made in version 6. Removed the header fields and switched to a URI parameter Editorial changes

Defined a new SIP Identity signature mechanism.

Changed the document type to experimental Removed option tag Added the Caller-driven SIP SAML Conveyed Assertion Profile Defined a new header (SAML-Info) Changed the description for usage with this new header Updated security considerations Minor editorial cleanups

Updated IANA consideration section. Added option tag Updated acknowledgments section Minor editorial changes to the security considerations section

Denoted that this I-D is intended to update RFC4474 per SIP working group consensus at IETF-69. This is the tact adopted in order to address the impedance mismatch between the nature of the URIs specified as to be placed in the Identity-Info header field, and what is specified in RFC4474 as the allowable value of that header field. Added placeholder "TBD" section for a to-be-determined "call-by-value" profile, per SIP working group consensus at IETF-69. Removed use-case appendicies (per recollection of JHodges during IETF-69 discussion as being WG consensus, but such is not noted in the minutes).

Initial specifications to kickstart the work.