SIP H. Tschofenig Internet-Draft Siemens Expires:January 19,September 6, 2006 J. Peterson NeuStar, Inc. J. Polk Cisco D. Sicker CU BoulderM. Tegnander LYIT July 18, 2005 Using SAML forJ. Hodges NeuStar, Inc. March 5, 2006 SIPdraft-tschofenig-sip-saml-04.txtSAML Profile and Binding draft-tschofenig-sip-saml-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 onJanuary 19,September 6, 2006. Copyright Notice Copyright (C) The Internet Society(2005).(2006). Abstract This documentdefinesspecifies amechanism for using theSession Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML)in concert with the Session Initiation Protocol (SIP). In particular, it providesas well as away for SIP to refer toSAMLobjects, and for recipients ofSIPmessages to usebinding. The defined SIP SAML Profile composes with the mechanisms defined inorder to make more informed authorization decisions.the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.Goals and Non-GoalsSpecification Scope . . . . . . . . . . . . . . . . . . . . . 5 4. SAML Introduction . . . . . . . . . . . . . . . . . . . . .6 4.1. 7 4.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 4.2. Abstract Request/Response Protocol . . .6 4.2 Artifact. . . . . . . . . 9 5. Employing SAML in SIP . . . . . . . . . . . . . . . .7 4.3 Request/Response Protocol. . . . 10 6. Use-case Scenarios . . . . . . . . . . . .7 4.4 Bindings. . . . . . . . . . 12 6.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . .8 4.5 Profiles. . . 12 6.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 13 6.3. Compensation using SIP and SAML .8 5. Assertion Handling Models. . . . . . . . . . . . 15 7. SIP SAML Profiles . . . . .9 6. Scenarios. . . . . . . . . . . . . . . . . 17 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile . . . . . . . .14 6.1 Network Asserted Identities. . . . . . . . . . . . . . 17 7.1.1. Required Information .14 6.2 SIP Conferencing. . . . . . . . . . . . . . . . 17 7.1.2. Profile Overview . . . . .16 6.3 PSTN-to-SIP Phone Call. . . . . . . . . . . . . . 17 7.1.3. Profile Description . . . .17 6.4 Compensation using SIP and SAML. . . . . . . . . . . . .18 7. SIP-SAML Extension21 7.1.4. Assertion Profile Description . . . . . . . . . . . . 24 7.1.5. Assertion Verification . . . . . . . . .20 8. Example. . . . . . . 27 8. SAML SIP Binding . . . . . . . . . . . . . . . . . . .21 9. Requirement Comparison. . . . 29 8.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 29 9. Example Signed SAML Assertion . .23 10. Security Considerations. . . . . . . . . . . . . . 30 10. Security Considerations . . . .24 10.1 Stolen Assertion. . . . . . . . . . . . . . . 32 10.1. Man-in-the-middle Attacks and Stolen Assertions . . . . .24 10.2 MitM Attack32 10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 33 10.3. Replay Attack .24 10.3 Forged Assertion. . . . . . . . . . . . . . . . . . . .24 10.4 Replay Attack. 33 11. Contributors . . . . . . . . . . . . . . . . . . . . . .25 11. Contributors. . . 34 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . .26 12.. . 35 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .27 13.. 36 14. IANA Considerations . . . . . . . . . . . . . . . . . . . .28 14.. 37 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . .29 15.. 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . .32 15.1. 39 16.1. Normative References . . . . . . . . . . . . . . . . . .32 15.2. 39 16.2. Informative References . . . . . . . . . . . . . . . . .32. 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . .34. . . 42 Intellectual Property and Copyright Statements . . . . . . .35. . . 43 1. Introduction This documentproposes a method for usingspecifies composition of the Security Assertion Markup Language (SAML)in collaborationV2.0 with SIP [RFC3261] in order to accommodate richer authorization mechanisms and enabletrait- based"trait-based authorization." Trait-based authorization is whereyou are authenticated usingone is authorized to make use of some resource based on roles or traitsinstead of identity. A motivationrather than ones identifier(s). Motivations fortrait based authorization and some scenariostrait-based authorization, along with use-case scenarios, are presented in[I-D.ietf-sipping-trait-authz].[I-D.ietf-sipping-trait- authz]. Security Assertion Markup Language (SAML)[I-D.saml-tech-overview- 1.1-03]v2.0, "SAMLv2", is anXML extension for security information exchange that is being developed by OASIS. SAML is a XML-basedXML- based framework for creating and exchanging security information.To[OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-tech- overview-2.0-draft-08] provide non-normative overviews of SAMLv2. The SAMLv2 specification set is normatively defined by [OASIS.saml- conformance-2.0-os]. Various means of providing trait-based authorizationa few solutions are possible:exist: authorization certificates, SPKI or extensions to the authenticated identity body[I-D.ietf-sip-authid-body].[RFC3893]. The authors selected SAML due to its increasing use in environments such as the LibertyAllianceAlliance, and the Internet2 project, areas where the applicability to SIP is widely desired. 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 SIPentity 'Authentication Service' wasnetwork element "Authentication Service" is introducedwithin [I-D.ietf-sip-identity]. We reuse this term to refer toan entitya network element that authenticates and authorizes a user and createsan assertion.a "SIP identity assertion". This system entity is the moral equivalent ofthe asserting partya "SAML Authority" in the SAML terminology. Forterminology relatedoverall SIP terminology, see [RFC3261]. In this specification, the term, or term component, "SAML" refers to SAML V2.0 in all cases. For example, thereader is referred to [I-D.saml- tech-overview-1.1-03]. 3. Goals and Non-Goals This document triesterm "SAML assertion" implicitly means "SAMLv2 assertion". For overall SAML terminology, see [OASIS.saml-glossary-2.0-os]. The below list maps other various SIP terms toaccomplish the following goals: o This document defines howtheir SAMLassertions are carried(rough-)equivalents: Element, Network Element: System Entity, Entity Authentication Service: SAML Authority Invitee, Invited User, Called Party, Callee - Relying Party Server, User Agent Server (UAS): SAML Responder User Agent Client (UAC), client: SAML Requester Additional terms concocted in theSIP. As such,context of this specification: profile attribute(s): one or more attributes of a "user profile". user profile, subject profile: theusageset ofSAML assertions withinvarious attributes accompanying (i.e., mapped to) a user account in many environments. 3. Specification Scope The scope of this specification is: o Specify a SIPcan be seen asprofile of SAML -- aka a "SIP SAMLprofile. o The requirementsprofile" -- such that a subject's profile attributes, andscenarios defined in [I-D.ietf-sipping-trait- authz] are comparedtheir domain's certificate, can be conveyed to a relying party using SAML. In doing so, satisfy thesolution describedrequirements outlined inthis document by utilizing SAML assertions.[I-D.ietf-sipping- trait-authz], and compose with [I-D.ietf-sip-identity]. The followingissuesare outside the scope of thisdocument:specification: oThe configurationDefining a means for configuring the runtime behavior, or deployment characteristics, of the Authentication Service. Discussion: For example, a SIP Authentication Servicein order to attach certain assertions is outside the scope of this specification and might dependcould be implemented such that its SAML-based features are employed, or not, onthe environment where SIP is used. To avoid restricting the functionalitya subject-by-subject basis, and/or on a domain-by-domain basis. o The definition ofSIP eitherspecific conveyed subject profile attributes (aka traits). Discussion: This specification defines a facility enabling "trait-based authorization" asan in-band or an out-of-band mechanism, it can be defined to trigger the inclusion of SAML assertions. SAML itself provides mechanisms for this purpose. odiscussed in [I-D.ietf-sipping-trait-authz]. The attributesstoredof interest inassertions are,trait-based authorization will be ones akin to, forexample,example: roles,membership to a certain organization, specificorganizational membership, accessrightsrights, orinformation about the authentication. A definition of mostauthentication event context. Definition ofthesesuch attributes isapplicationapplication- and/or deployment-context- dependent and are not defined in thisdocument.specification. However, TheSAMLSAMLv2 specificationitself provides a number of common attributes and provides extension pointsdefines several "SAML Attribute Profiles" forfuture enhancements. A brief overview of the availableencoding attributeswithin an assertion is givenfrom various application domains, e.g., LDAP, UUID/GUID, DCE PAC, and XACML, inSection 4.1.SAML assertions [OASIS.saml- profiles-2.0-os]. In order forSAMLany trait-based system to beused in a practical system,practical, participating entities must agree on attributes and traits that will beused.conveyed and subsequently relied upon. Withoutthis pre-existing agreement, SAMLsuch agreements, a trait- based system cannot be usefully deployed. Thisdocumentspecification does not discuss the manner in which participating entites might discover one another or agree on the syntax and semantics of attributes and traits.o SIP is not used asNote that SAMLv2 specifies arequest/response protocol"metadata" facility that may be useful in addressing this need. 4. SAML Introduction SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] [OASIS.sstc-saml-tech- overview-2.0-draft-08] defines an XML-based framework for exchanging "security assertions" between entities. In theRelying Party andcourse of making, or relying upon such assertions, SAML system entities may use SAML protocols, or other protocols, to communicate regarding an assertion itself, or theAsserting Partysubject of an assertion. Thus one can employ SAML tofetchmake 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 assertionbasedto 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 areceived artifact. 4.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 SAMLIntroduction Inis employed in a particular context of use is known as a "SAML profile". The specification of how SAMLthereassertions and/or protocol messages arethree main entities:conveyed in, or over, another protocol is known as a "SAML Binding". Typically, a SAML profile specifies theuser,SAML bindings that may be used in its context. Both SAML profiles and SAML bindings reference other SAML specifications, especially theasserting partySAML Assertions and Protocols, aka "SAML Core", specification [OASIS.saml-core-2.0-os]. There is an additional subtle aspect of SAML profiles that is worth highlighting -- therelying party.notion of a "SAML assertion profile". Auser requests assertions and receives them afterSAML assertion profile is the specification of the assertion contents in the context of asuccessful authentication and authorization protocol execution. The asserting party provides assurance thatparticular SAML profile. It is possibly further qualified by a particularuser has been given proper authorization.implementation and/or deployment context. Condensed examples of SAML assertion profiles are: o The SAML assertion must contain at least one authentication statement and no other statements. The relying partyhas to trust the asserting party with regard tomust be represented in theprovided information<AudienceRestriction> element. The SubjectConfirmation Method must be Foo. etc. o The SAML assertion must contain at least one attribute statement andthen decides whether or not to acceptmay contain more than one. The values for theassertions provided, giving different levels of privileges.subject's profile attributes named "Foo" and "Bar" must be present. An authentication statement may be present. etc. Thecomponentsprimary facets of SAML itself are: oAssertions/ArtifactAssertions o Abstract Request/Responseprotocols o Bindings o Profilesprotocol We describe each in turnbelow 4.1below: 4.1. SAML AssertionsAnA SAML assertion is a package of information includingauthentication statements,issuer and subject, conditions and advice, and/or attribute statements, and/or authentication statementsand authorization decisionand/or other statements.All of statements doStatements may or may nothave tobepresent, but at least one does. Anpresent. The SAML assertion "container" itself containsseveral elements:the following information: 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. Additional advice: Explaining how the assertion was made, for example. Inanterms of SAML assertions containing SAML attribute statements or SAML authenticationstatement, an issuing authority asserts thatstatements, here are explanatory examples: With acertain subject was authenticated by certain means atSAML assertion containing acertain time. In anSAML attribute statement, an issuing authorityassertsis asserting thata certainthe subject is associated with certain attributeswhich haswith certain subject profile attribute values. For example, user jon@cs.example.com is associated with the attribute'Department',"Department", which has the value'Computer Science'. In an authorization decision statement, a certain subject with"Computer Science". With acertain access type toSAML assertion containing acertain resource has given certain evidence that the identitySAML authentication statement, an issuing authority iscorrect. Based on this, the relying party then makesasserting that thedecision on giving access or not. Thesubjectcould 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, iswas authenticated by certain means at abase-64 encoded string that is 40 bytes long. 20 bytes consists of the typecode, which is the source id. The remaining 20 bytes consists ofcertain time. With arandom number that servers use to look up an assertion. The source server stores theSAML assertiontemporarily. The destination server receives the artifactcontaining both a SAML attribute statement andpulls the assertion from the source site. The purpose of the artifact is to act asatoken that referencesSAML authentication statement, anassertion for the subject who holds the artifact. Note that artifacts were designed to be used specifically in a web context where the asserting partyissuing authority isclear due to the client/server nature of the protocol. Artifacts are not globally-derefenceable; one cannot tell simply be inspecting an artifact out of context which server generated the artifact. Forasserting themore peer-to-peer architectureunion ofSIP, enhancements are required to makethecontext of artifact generation known to relying parties. 4.3above. 4.2. Abstract Request/Response Protocol SAML definesaan abstract request/response protocol for obtaining assertions.TheSee Section 3 "SAML Protocols" of [OASIS.saml-core-2.0-os]. A request asks for anassertion or makes queries for authentication, attribute and authorization decisions. Theassertion. A responsecarries backreturns the requestedassertion. 4.4 Bindings The bindings in SAML maps between the SAMLassertion or an error. This abstract protocoland a transport and messaging protocol. With SAML Version 1.1 there is only onemay then be cast into particular contexts of use by bindingspecified, which is SAML embedded in SOAP-over-HTTP. In a binding, a transportit to specific underlying protocols, e.g., HTTP or SIP, andmessaging protocol is used only"profiling" it fortransportingtherequest/response mechanism. 4.5 Profiles When using a profile,specific use case at hand. The SAML HTTP- based web single sign-on profile isused to provide assertions about a resource in the bodyone such example (see Section 4.1 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- based SIP communication session establishment, themessage itself. In Version 1.1topic ofSAML, there are twothis specification, is another. 5. Employing SAML in SIP Employing SAML in SIP necessitates devising a new SAML profile or profilesspecified,because theBrowser/Artifact profile andthose already specified in theBrowser/POST profile. The Browser/Artifact profile represents a "pull" model, where a special referenceSAMLv2 specification set are specific tothe assertion called an artifact, is sentother use contexts, e.g., HTTP- based web browsing. Although SIP bears some similarity tothe relying party from the asserting party. The artifactHTTP, it isthen used to "pull" the assertion from the asserting party. The Browser/POST profile representsa"push" model, where an assertionseperately distinct protocol, thus SAML profile specificity isposted (using the HTTP POST command) directlywarranted. However, this should not present any untoward difficulties due tothe relying party. These two models are described in Figure 2SAML's inherent andFigure 1. 5. Assertion Handling Models As mentioned in Section 4.5, two main models can be used in SAMLexplicit extensibility, andthereforealsowith the SIP-SAML extension defined in this document:because SIP is similarly extensible. ThePush and the Pull model. A 'Push' model (or mode) means to transmit information towards another entity. Here we call that transmitting"Authenticated Identity Management in SIP" specification [I-D.ietf-sip-identity] (aka "SIP Identity") facilitates theinformation 'by- value'. An examplecomposition ofthis model (or mode) is an email attachment (file). That attachment is includedSAML and SIP inthe original transmission, as is 'by-value'. Whereas,that it defines a'Pull' model (or mode) means to transmit an identifier for"mediated authentication architecture" wherea piece of information is (located somewhere else). This piece of information still requires retrieval byverifying endpoints verify SIP identity assertions -- i.e., thereceiver of this transmission. Here we call"Identity" header value -- signed by an Authentication Service (AS). The semantic being thattransmittingtheinformation 'by- reference'. An example of this model (or mode)AS isincluding a URI invouching thatemail, to be accessed directly byit did indeed authenticate thereceivercalling party. Such an Authentication Service, which likely has access to various pieces of information concerning theemail incalling party, could also act as asubsequent operation. Either the end host or an intermediate proxy might request an assertion or an artifact. The PushSAML Authority, and make such information available to thePull model used for HTTP does not match withcallee via SAML. Since [I-D.ietf-sip-identity] stipulates that the AS must make itsusage in SIP. Withcertificate available for retrieval and convey the'per-value' model eitheravailability and access mechanism via auser requests an assertion from the Asserting Party or the user triggersURI, in theAsserting Party to attachIdentity-Info header, we have anassertion to the outgoing request. The assertion, which is addedopportunity tothe service request,compose SIP Identity and SAML. Such composition can beverifiedaccomplished by having theRelying Party without additional protocol interactions with the Asserting Party. The assertion therefore contains enough informationresource referred toauthorizeby theservice request. Figure 1 showsURI in theprotocol exchange whereIdentity-Info be a SAML assertion conveying both the AS's certificate and userfetchesprofile attributes. This is theassertion. +----------+ +--------------+approach defined in this specification. Figure 1 illustrates this approach in a high-level summary fashion. Figure 5, further below, illustrates additional details. +--------+ +--------------+ +--------+ |Alice@ |User | | Asserting | | Relying | | | | Party | | Party | +----+-----+ +------+-------+ +------+-------+ | | | | Request Assertion ||Authentication| ||--------------------->|Bob@ | |example | |Service | |example2| |.com | |@example.com |User Authentication|com | | |and Authorization| ||<---------------------|||--------------------->|| +---+----+ +------+-------+ +---+----+ | | | |AssertionINVITE | ||<---------------------||---------------------->| | | From:alice@foo.com | | |Request + Assertion||----------------------+------------------------->|| | 407 Proxy auth. req. | | |<----------------------| | | Challenge |Accept/Reject||<---------------------+--------------------------|| | |Figure 1: Example for a 'Per-value' Interaction With the 'per-reference' model either the user contacts the Asserting Party to obtain an artifact or the user triggers the Asserting Party to attach the artifact to the outgoing request. The artifact is a reference to an assertion is stored at the Asserting Party and can later be dereferenced into the assertion on a request. The Relying Party later fetches the SAML assertion after receiving the artifact by the user. For communicating the SAML request and response messages, a separate message exchange is needed with a protocol, such as SOAP. A description of this protocol interaction is outside the scope of this document. Figure 2 shows an example protocol interaction where the user fetches the artifact. +----------+ +--------------+ +--------------+|UserACK | |Asserting|---------------------->| | |Relying| | | INVITE w/authn creds |Party| |---------------------->| |Party|+----+-----+ +------+-------+ +------+-------+| INVITE | | |Request Assertionw/Identity header | | |--------------------->| | || | | User Authentication | | |andAuthorization | | |<---------------------| | |--------------------->| | | | | | Artifact | | |<---------------------|Identity-Info | | | | |Request + Artifact||----------------------+------------------------->|HTTP GET SAML assn | | |<==================== | | |SAML requestand domain cert | ||<-------------------------|| | | ||SAML responseHTTP 200 OK +Assertionassn | ||------------------------->||=====================>| | | and domain cert | |Accept/Reject200 OK ||<---------------------+--------------------------|| |<----------------------+----------------------| | | | Figure2: Example for a 'Per-reference' Interaction 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 at the Asserting Party and both entities mutually authenticate each other. The requested assertion is sent to1: SIP-SAML-based Network Asserted Identity Since theuser in a confidential mannerAS already being trusted toprevent eavesdroppers from obtaining this assertion. The Relying Party trusts the Asserting Party. It is assumed that the accessed resource is located at the Relying Partycreate andthat this entity does not become malicious or act on behalf ofadd theuser to impersonate him or her to other parties with regard to access to his resources. To prevent some degree of misuse, attributes inIdentity header containing theassertion limit its applicability for certain applications, servers or time frame. Signaling inSIPcan, however, involve a number of entities in more complex scenarios. As an example, the scenario addressed in [I-D.ietf-sip-identity] aimsIdentity Assertion, and toreplace end-to-end authentication via S/MIME bysupply a"mediated authentication architecture". The end hosts only need to be ablepointer toverify assertions signed by an Authentication Service which guarantees that the sender was authenticated. Directly applying SAMLits domain certificate, having it point instead tosuch a scenario, however, causes a problem: a SIP proxy, which securely receivesa SAML assertion(such as confidentially protected to prevent eavesdroppers betweenconveying theSIP UAdomain certificate andthe 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 includepossibly someattributes which restrict its usage (such as recipient(s), unique identifier for the message or a time-based constraint) but they cannot fully prevent impersonation. This problem appears if SAML assertions are not bound to a particular SIP transaction or dialog. Binding the assertion to a particular protocol session isuser profile attributes, does notuseful if the property of single-sign on is required. To provide referential integritysignificantly alter thesolution described in [I-D.ietf- sip-authid-body] can be reused. Such an approach allows a partyfirst-order security considerations examined ina SIP transaction to cryptographically sign the headers that assert the identity of the originator of a message, and provide some other headers necessary for reference integrity. An authenticated identity body (AIB) is a MIME body of type 'message/sipfrag'.[I-D.ietf-sip-identity]. ThisMIME body has a Content-Disposition type of 'aib'. The MIME body is optional. The header fields From, Contact, Date and Call-ID must be used for providing identity. Contact and Date header fields are required for providing reference integrity. AIBs may contain other headers that help to uniquely identify the transaction or thatspecification providesrelated reference integrity. The requirements for a non-INVITE AIB is very much the same as for an INVITE: From, Call-ID, Date and Contact header fields are required. The same that goes for requests also goes for responses withsomesmall differences. The From header field of the AIB in the response to an INVITE must correspond to the address-of-record of the responder and not the From header fieldadditional security considerations analysis below inthe received request. The To header field of the request must not be included. A new Date header field has to be generated for the response while the Call-ID and CSeq are copied from the request. Following is an example of the format of an AIB for an INVITE: Content-Type: message/sipfrag Content-Disposition: aib; handling=optional From: Alice <sip:alice@example.com> To: Bob <sip:bob@example2.com> Contact: <sip:alice@pc33.example.com> Date: Thu, 26 Aug 2004 13:51:34 GMT Call-ID: b76m5l94s90835 CSeq: 435431 INVITE Figure 3: AIB Format for an INVITE The same concept is applicable to this document as well with regard to reference integrity. For a further discussion on this topic seeSection14 and [I-D.peterson-message-identity].10. 6. Use-case Scenarios This section shows message flows based on scenarios in [I-D.ietf- sipping-trait-authz] enriched with a SAML based solution. Section6.1 provides an example of enhanced network asserted identities and Section6.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 4 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[I-D.ietf-sipping-trait-authz]. 6.1. PSTN-to-SIP Phone Call Alice, using a phone connected to theAuthentication Service. Figure 4 shows three entities, Alice@example.com, AS@example.com and Bob@example2.com. If AlicePSTN, wants tocommunicate with Bob, she sendsmake aSIP INVITEcall toher preferred AS. Depending on the chosenBob, which resides in a SIPsecurity mechanism either digest authentication, S/MIME or Transport Layer Securitynetwork. Her call isused to provideswitched through theAS with a strong assurance aboutPSTN by means of PSTN signaling (outside theidentityscope ofAlice. Duringthisstep authorization attributes for inclusion into the SAML assertion can be selected. After Alice is authenticated and authorized, a SAML assertion is attacheddocument) to theSIP message. The Authentication Service can be configured to attach a number of assertions, not limited toPSTN/SIP gateway. At theauthenticated identity. To bindgateway, theSAML assertion to a specific SIP session, itcall isnecessary for the ASconverted from SS7 signaling tocompute a hash of some fields of the message. A list ofSIP signaling. Since Alice's PSTN phone was previously "authenticated" via PSTN signaling mechanisms, thefields to hash is described in [I-D.ietf-sip-identity] and particularly in [I-D.ietf-sip-authid-body]. The hashgateway isdigitally signed and inserted into the SAML assertion and placed into the SAML header. The SAML header also contains information about the entity which created the digital signature. Upon reception of the message, Bob verifies the signature of the SAML assertion and verifies the bindingable totheassert her phone's identity (e.g., her telephone number) via SIPmessageIdentity and SAML-based mechanisms (e.g., in order toprevent cut-and-paste attacks. The provided SAML assertion can then be usedconvey profile attributes) toassist during the authorization procedure. If Bob does not understandBob's SIP proxy, which also dereferences theextension definedURI inthis document, he silently ignores it. When the 200 OK message arrives at Bob's AS,thesame procedure as when Alice sent her INVITE to her AS can be performed, if desired. This exchange is not shownIdentity-Info header inFigure 4. Note that this scenario does not imply thatorder to obtain the SAMLassertions are solely used by SIP UAs. Assertions can also be helpful for SIP proxies or B2B UAs. +--------+ +--------------+ +--------+ |Alice@ | |Authentication| | Bob@ | |example | |Service | |example2| |.com | |@example.com | |com | | | | | | | +---+----+ +------+-------+ +---+----+ | | | | INVITE | | |---------------------->| | | From:alice@foo.com | | | | | | 407 Proxy auth. req. | | |<----------------------| | | Challenge | | | | | | Challenge response | | |---------------------->| | | | | | INVITE | | |---------------------->| | | | INVITE | | | + SAMLassertion| | |--------------------->| | | | | 200 OK | | |<----------------------+----------------------| | | | Figure 4: Network Asserted Identities A variation ofand thescenario presented in Figure 4 is given in Figure 5 where an end host (Alice@example.com) obtains an assertion from its SIP proxy server which acts as an Authentication Service. This assertionPSTN/SIP Gateway's domain certificate. Alice's INVITE is thenattached by the end host to the outgoing INVITE message. Unlike in case of an artifact, Bob@example.com does not need to contactforwarded from theProxy Server. An example of this scenario could beSIP/PSTN gateway topreempt a lower priority call if enough assurance for doing soBob's phone, and ispresented in the attached SAML assertion. This would also mean that theresecured via whatever means isa priority value includedlocally established inthe INVITE (for example in the Resource-Priority Header). +--------+ +--------------+ +--------+ | Alice@Bob's administrative domain. +-----------+ +----------------------+ ||Proxy Server| |Bob@||exampleSS7 ||(ASPSTN/SIP ||example||.comPublic Switched |--------------------->| Gateway ||@example.com||.com| | | | | | |+---+----+ +------+-------+ +---+----+| Telephone Network | +--+-----------+------+ | ^ |INVITE| ||---------------------->|^ V | +---------+------------+ |From:alice@example.com|| ^ V SIP-Ident | | SS7 | v ^ V +SAML |407 Proxy auth. req.| ||<----------------------|+--------+ | O |SAML Auth Header| Bob's | |to useO /|\ <----+----| SIP | | /|\ / \ SIP | | Proxy | |INVITE + SAML assertion/ \ Bob ||-----------------------+--------------------->|| | | Alice |200 OK+--------+ | ||<----------------------+----------------------|SIP based | | Network | +---------------------+ Figure5: End host attaching SAML Assertion2: PSTN to SIP call Note thatBob and Alice do not need tothe INVITE emitted by the PSTN/SIP gateway could alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone, and Bob's phone could take on the SIP Identity "verifier" role, which is being played by Bob's SIP proxy in thesame administrative domain. Itfigure. Whichever approach isfeasible that Bobemployed isinadomain that is federated with Alice's domain. The assertion obtained by Alice@example.com needsdecision local to Bob's administrative domain and can beassociated with a particular SIP messaging session. How to achieve this binding is for further consideration. 6.2made independently. 6.2. SIP Conferencing This section is meant toraise some discussionsfoster discussion about the usage of SAML in the domain of conferencing. A user who routes its SIP message through the Authentication Service (Asserting Party) towards a conferencing server may wantSAML assertionsor need various of her profile attributes included and may also need to beincluded.authenticated by the conference server. The following properties could be provided by this procedure: o The user identity can be replaced to allow the user to be anonymous with regard to theFocusFocus. This can be accomplished via [RFC3323] in combination with [I-D.ietf-sip-identity], per the latter, or, o The user identity could be asserted to theFocusFocus, via [I-D.ietf- sip-identity] mechanisms, and/or, oThethe SAML assertion could provide additional user profile information such as group membership (belongs to the students, staff, faculty group of university X). This could, fornon-identity-basednon- identity-based authorization systems, 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 | |------------------>|INVITE+SAMLw/Identity hdr | | |------------------>| | | | | | HTTP GET SAML assn| | |<==================| | | and domain cert | | | | | | HTTP 200 OK + assn| | |==================>| | | and domain cert | | | | | | | | | Ringing | | Ringing |<------------------| |<------------------| | | | | | | OK | | OK |<------------------| |<------------------| | | | | | ACK | | |------------------>| ACK | | |------------------>| | | | | | | ... many more msgs... Figure6:3: SIP Conferencing and SAML6.3 PSTN-to-SIP Phone Call Alice, using a phone connected toHowever, there are obvious scaling issues with thePSTN, wants to make a callconference server having toBob, which residesdo the outbound requests inaorder to obtain SAML assertions and certificates for conference participants. This could be addressed by creating another SIPnetwork. Her call is switched throughSAML Profile where thePSTN by means of PSTN signaling (outsidecaller obtains thescope of this document)necessary information, e.g., SAML assertions, and places them into its SIP request message prior to sending it. This would obviate thePSTN/SIP gateway. At the gateway,need for thecall is converted from SS7 signalingcallee relying party to make requests in order to obtain said information. This is a topic for future work, and possibly future revisions of this specification. 6.3. Compensation using SIPsignaling. Since Alice was previously 'authenticated' through PSTN signaling mechanisms, the gateway can create an assertion based on signaling information from Aliceanddigitally sign it with his private key. Alice's callSAML This section describes a scenario where SAML isforwarded from the SIP/PSTN gatewayused in SIP toBob's phone. Bob can certifyrealize compensation functionality as described in [I-D.jennings- sipping-pay]. Note thatthe identity of Alicethis scenario iscorrectnot directly addressed byexaminingthe SIP SAMLassertion. +-----------+ +----------------------+ |Profile and SAML SIP Binding presently defined in this specification. Rather, this use case calls for additional such profiles and bindings to be developed. +--------+ +--------+ +--------+ |Payment | | User |SS7|Merchant| |Provider| |SIP/PSTNAlice | |Bob |Public Switched |--------------------->| Gateway| | | | | | | | | |Telephone Network|+--+-----------+----+|^+---+----+ +---+----+ +---+----+ | | | |+---------+------------+| 1) Call |SIP+SAML| |------------------------>| |SS7|v| | |+--------+2) 402 + Payment Offer |O| 3) Request for |<------------------------| | a Payment | |O /|\ <----+----| SIP|<----------------------| | |/|\ / \ SIP+|Proxy| |/ \ Bob4) SAML Assertion | | |Alice(=Receipt) |+--------+| |---------------------->| | | | 5) Call + Receipt | | |------------------------>| | |SIP based| |Network|+-------------------+6) 200 OK | | |<------------------------| | | | Figure7: PSTN to4: Message flow for SIPcall 6.4 Compensationpayment User Alice and the Merchant Bob interacts with each other using SIP andSAML This section briefly elaborates a scenario where SAML is used in SIPthe Alice uses HTTP torealize compensation functionality as described in [I-D.jennings- sipping-pay] Section 1 of [I-D.jennings-sipping-pay] shows a messageexchangewhich is used bymessages with anumber of payment protocols and hence can also be used byPayment Provider. Initially, Alice makes aSAML specified protocol. To avoid repetition in this documentcall to Bob (1). Bob determines that asecond alternativepayment isprovidedrequired and includes information about the payment inFigure 8. Alice initiates a communication withanAuthentication Service which acts asOffer body of afinancial institution. Note that402 (Payment Required) response to Alicedoes not necessarily need(2). Alice looks at this Offer and decides touse SIP for communication withmake a payment. Alice therefore instructs her Payment Provider to make a transfer from theAuthentication Service. Instead, it might be possibleAlice's account touse HTTP or other protocols which offerthenecessary user credential or offer additional information (such asMerchants's account (3) using aweb page). Afterrequest for asuccessful authentication and authorization Alice obtains anSAML assertion with the extensions defined in this document. The Payment Provider returns a receipt for this transfer (4). This receipt is a SAML Assertion (oran artifact) which might contain payment relevant information. Foralater service access, Alice contactsSAML Artifact, if themerchant Bob withexchange is triggered by a proxy or if desired by theassertion. Bob verifiesCustomer). Alice resubmits theassertion and, it might wantcall tocontactBob but this time provides theAuthentication ServiceReceipt fora credit check. A financial settlement betweenthemerchanttransaction (5). Bobanddetermines whether theTrusted Third PartyReceipt isassumed. Depending onvalid (by checking thetypedigital signature and the content ofservice, a one-time paymentthe assertion) and continues withimmediatethe call processing, if the authorization was succesful. The Offer contains information about the three parties, the Payment Provider, that are acceptable to the Merchant Bob, the amountdeduction may take place (e.g., in caseofa prepaid account) ortransaction, theamount is captured asaccount identifier for Bob at the Payment Provider, and abatch transaction. The aspect of lightweight protocol execution is provided by o The alternative usage of an artifact which leadsreplay protection indicator toa lower bandwidth consumption. o The abilitymake it easier for the Merchant Bob touseavoid replay attacks. User Alice includes this information when making the Request for Payment to the Payment Provider; adds its own account information and authorization password; and sends this to the Payment Provider, which produces asingle assertionReceipt formultiple service access protocol executions,the transaction ifdesired. o SAML, furthermore allows a cryptographic key to be boundit is successful. This transfer from Alice toan assertion. A high degree of flexibilitythe Payment Provider isprovidedmade across an encrypted, integrity protected channel. The Receipt includes a timestamp when the Payment Provider made the transaction and protects the Receipt withregard toa digital signature. Alice resubmits thepossible credentials. For example, it might not be necessarycall touse public key cryptographythe Merchant Bob withevery service access. This might be useful ifthecost of public key cryptographic is too expensiveReceipt from the Payment Provier. Merchant Bob can check for replay attacks using the timestamp and acheap service orreplay protection indiciator initially provided with the Offer. Bob can then check the signature is valid using the Payment Provider's public key. 7. SIP SAML Profiles This section defines one SIP SAML profile: The "AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile" 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 7.1.1. Required Information The information given in this section is similar to the info provided whendevices have performance limitations.registering something, a MIME Media Type, say, with IANA. In this case, itmightis for registering this profile with the OASIS SSTC. See Section 2 "Specification of Additional Profiles" in [OASIS.saml- profiles-2.0-os]. Identification: urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 @@ NOTE: This URN must beusefulagreed upon, and then registered with IANA per [RFC3553]. Contact Information: @@ someone's or something's contact info goes here SAML Confirmation Method Identifiers: The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is used in this profile. Description: Given below. Updates: None. 7.1.2. Profile Overview Figure 5 illustrates this profile's overall protocol flow. The following steps correspond torelythe 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, and in [I-D.ietf-sip-identity], may be applied to any SIP request message. Figure 5 begins onsymmetric cryptographic, such as hash chains. +--------+ +--------------+ +--------+ |Userthe next page. +------------------+ +------------------+ +-----------------+ ||Authentication| |Merchant| |AliceCaller ||Server|Authn Service (AS)| ||BobCallee | |Alice@example.com | ||(Trusted Third|@example.com | | Bob@example2.com| +--------+---------+ +--------+---------+ +--------+--------+ - - | | |Party)(steps) ^ ^ | INVITE | | |+---+----+ +------+-------+ +---+----+| |---------------------->| | (1a) | |SIP, HTTP, etc.From:alice@foo.com | ||---------------------->|| C | To:sip:bob@example.com| | | S | | | | e | 407 Proxy auth. req. |Assertion| | q |<----------------------| | (1b) | = | Challenge | | | N | | | | | ACK | | | | |---------------------->| | (1c) | V | | | | - | | | ^ | INVITE +SAML assertionauthorization| | 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 | | Identity: ..... | G = | | Identity-Info: | | | https://example.com| | N | | /assns/?ID=abcde | | | | | | + | |URI resolution (eg. HTTP) | | |<=====================| (4) | 1 | | GET /assns/?ID=abcde | | | | | | | | | HTTP/1.1 200 OK | | | | |=====================>| (5) | | | | <saml:Assertion> | | | | | <saml:Subject> | | | | | <saml:NameID> | | | | | Alice@example.com | | | | <saml:SubjConf> | | ||-----------------------+--------------------->|| <saml:SubjConfData> | | | | <ds:KeyInfo>... | | | | <saml:AttrStatement> | | | | foo=bar | | | | 200 OK | | | V |<----------------------+----------------------| (6) . - | | | V Figure8: Message flow for5: AS-driven SIPpayment The main differenceSAML Attribute Fetch Profile: Example INVITE Transaction Step 1. Initial SIP Transaction betweenthe above-described mechanismCaller andthe one described in Section 1 of [I-D.jennings-sipping-pay]AS This optional initial step isthe degreecomprised ofuser involvementsubsteps 1a, 1b, andthe type of protocol interaction.1c in Figure 5. Inboth cases itthis step, the caller, Alice, sends a SIP request message, illustrated as an INVITE, indicating Bob as the callee (1a), ispossible to providesubsequently challenged by the AS (1b), and sends anindicationACK in response to theuser aboutchallenge (1c). The latter message signals thecostscompletion ofa service access. In fact, the assertion might specify these typethis SIP transaction (which is an optional substep ofconstraints directly or indirectlythis profile). Step 2. Caller sends SIP Request Message with Authorization Credentials to thehelp of recurring service requests/responses. 7. SIP-SAML Extension To carry SAML assertionsAS 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 [I-D.ietf-sip-identity] andartifacts two mechanisms are defined: o The[RFC3261]. Depending on the chosen SIPheader maysecurity mechanism eithercarry an Artifcatdigest authentication, S/MIME ora CID URI [RFC2392] pointingTransport Layer Security is used toan assertion inprovide theSIP body. The nameAS with a strong assurance about the identity ofthis newAlice. Step 3. AS Authorizes the SIPheader is SAML-Assertion. A SAML artifact consists of a TypeCode, SourceIDRequest andan AssertionHandle. ItForwards it to Callee First, the AS authorizes the received INVITE message as specified in [I-D.ietf-sip-identity] and [RFC3261]. If the authorization isthereby assumed thatsuccessful, theRelying PartyAS willmaintain a table of sourceID values as well as URLsform the "identity signature" forAsserting Partiesthe message and add Identity and Identity-Info headers tocontact. This information is communicated out-of-band. This documentthe message. The AS alsoallowsat this time constructs and caches a SAML assertion asserting Alice's profile attributes required by Bob's domain (example2.com), and also containing a theAsserting Party to adddomain's (example.com) public key certificate, or aURLreference topointit. This certificate MUST contain the public key corresponding to theassertionprivate key used toprevent this level of indirection. oconstruct the signature whose value was placed in the Identity header. TheSIP body may carry one or moreAS constructs a HTTP-based SAMLassertions. The MIME typeURI Reference incorporating the assertion's Assertion ID (see section 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses thisSAML assertion is definedURI as the value for the Identity-Info header it adds to the INVITE message. The AS determines which profile attributes (if any) to assert in[I-D.hodges-saml-mediatype]. Athe <AttributeStatement> via local configuration and/or obtaining example2.com's metadata [OASIS.saml-metadata-2.0-os]. The AS then sends the updated INVITE message to Bob. Step 4. Callee Dereferences HTTP-based SAML URI Reference Bob's UAC or SIPuser agent may add an assertionProxy receives the message and begins verifying it per the "Verifier Behavior" specified in [I-D.ietf-sip-identity]. In order to accomplish this task, it needs to obtain Alice's domain certificate. It obtains thebody ofHTTP-based SAML URI Reference from the message's Identity-Info header and dereferences it per Section 8.1. Note that this is not a SIP message, but an HTTP messageor may add a[RFC2616]. Step 5. AS Returns SAML Assertion Upon receipt of the above HTTP request, which contains an embedded reference totheAlice's SAML Assertion, Alice's AS returns her assertionintoin an HTTP response message. Upon receipt of Alice's SAML Assertion, theSIP header. SIP proxies MUST NOT addAS continues its verification of theassertionINVITE message. If successful, it returns a 200 OK message directly tothe body. The SIP header MUST be used instead whenAlice. Otherwise it returns anassertion hasappropriate SIP error response. Step 6. Callee Returns SIP 200 OK tobe added. A SAML assertion SHOULD be protectedCaller If Bob determines, based upon Alice's identity as asserted by the AS, andwhen addedas further substantiated bya SIP entity then S/MIME MUST be used rather than XML digital signatures. To bind athe information in the SAMLassertionassertion, to accept the INVITE, he returns a SIP 200 OK messagea few selected SIP message fields are inputdirectly toa hash function.Alice. 7.1.3. Profile Description Thedigest-string, defined in Section 10 of [I-D.ietf-sip-identity], is included into the conditions extension pointfollowing sections provide detailed definitions of theSAML assertion. Details are for further study. 8. Example Thisindividual profile steps. The relevant illustration isan example of a SAML assertion and how itFigure 6, below. Note that this profile isstructured in XML. <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="P1YaAz/tP6U/fsw/xA+jax5TPxQ=" Issuer="www.example.com" IssueInstant="2004-06-28T17:15:32.753Z"> <saml:Conditions NotBefore="2004-06-28T17:10:32.753Z" NotOnOrAfter="2004-06-28T17:20:32.753Z" /> <saml:AuthenticationStatement AuthenticationMethod="urn:ietf:rfc:3075" AuthenticationInstant="2004-06-28T17:15:12.706Z"> <saml:Subject> <saml:NameIdentifier> NameQualifier=alice@example.com Format="urn:oasis:names:tc:SAML:1.1:nameid- format:emailAddress">uid=alice </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0: cm:SIP-artifact-01 </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> The elements inagnostic to theassertion havespecific SIP request, and also that thefollowing meaning: +---------------------+-----+-------------------------------+Sender and Authentication Service (AS) may be seperate or co-located in actuality. +------------------+ +------------------+ +------------------+ |Tag name |Req-Sender |Description|Authn Service (AS)| | Verifier ||uired||+---------------------+-----+-------------------------------+ |MajorVersion(UAC) |X |Major version of the assertion|+---------------------+-----+-------------------------------+ |MinorVersion(Sender's) |X |Minor version of the assertion|(UAS or Proxy Svr)| +--------+---------+ +--------+---------+ +--------+---------+ |+---------------------+-----+-------------------------------+ |AssertionID|X |ID of the assertion|+---------------------+-----+-------------------------------+ |Issuer(steps) |X |The name of the SAML authoritySIP Request | | |---------------------->| ||that created the assertion(1a) |+---------------------+-----+-------------------------------+ |IssuerInstant|X |Issuing time of the assertion|+---------------------+-----+-------------------------------+| 407 Proxy auth. req. ||Conditions that MUST be taken||Conditions|<----------------------| ||into account when assessing(1b) | Challenge | ||the validity of the assertion|+---------------------+-----+-------------------------------+| ||Specifies||AuthenticationMethodACK |X |what kind of authentication| |---------------------->| | (1c) ||took place|+---------------------+-----+-------------------------------+ |AuthenticationInstant| X |Specifies the time when the| | ||authentication took place|+---------------------+-----+-------------------------------+ |Qualifier|SIP Req + authorization| | | header w/ creds | | |---------------------->| | (2) | | | | | | | | SIP Req + Ident & ||The name by which the subject| | authz headers | | |--------------------->| (3) | ||is recognized|+---------------------+-----+-------------------------------+| ||AURIreference representingresolution ||Format||the format of NameIdentifier|<=====================| (4) | | (via HTTP) | | |+---------------------+-----+-------------------------------+| ||Specifies a subject by supply-||SubjectConfirmationHTTP/1.1 200 OK ||ing data that allows the sub-| |=====================>| (5) | ||ject to be authenticated|+---------------------+-----+-------------------------------+| ||Identifies||ConfirmationMethod||which method to be used for| ? | (6) | ||authenticating the subject|+---------------------+-----+-------------------------------+Figure10: Tag descriptions 9. Requirement Comparison A future version6: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 7.1.3.1. Initial SIP Transaction between Sender and AS This OPTIONAL step maps to Steps 1 and 2 ofthis document will compareSection 5 "Authentication Service Behavior" of [I-D.ietf-sip-identity]. If therequirements listed in [I-D.ietf-sipping-trait-authz] withSIP request sent by thesolution providedcaller inthis document. 10. Security Considerations This section discusses security considerations when using SAML with SIP. 10.1 Stolen Assertion Threat: If an eavesdropper can copysubstep 1a is deemed insufficiently authenticated by thereal user's SAML response and included assertionsAS per the rules stipulated by [I-D.ietf-sip- identity] Steps 1 andconstruct a SIP message of his own,2, then theeavesdropper could be able to impersonateAS MUST authenticate theuser at other SIP entities. Countermeasures: By providing adequate confidentiality, eavesdroppingsender ofa SAML assertion can be stopped. 10.2 MitM Attack Threat: SincetheSAML assertionmessage. The particulars of how this iscarried within a SIP message, a malicious site could impersonate the user at some other SIP entities. Theseaccomplished depend upon implementation and/or deployment instantiation as discussed in [I-D.ietf-sip-identity]. Substeps 1b and 1c as shown in Figure 6 are non-normative and illustrative only. 7.1.3.2. Sender sends SIPentities would believe the adversaryRequest Message with Authorization Credentials tobethesubjectAS This step maps to Steps 1 and 2 ofthe assertion. Countermeasures: If the adversarySection 5 "Authentication Service Behavior" of [I-D.ietf-sip-identity]. This request isa not-participatingpresumed to be made in a context such that theSIP signaling itself (i.e., it isAS will nota SIP proxy or a SIP UA), this threat canchallenge it -- i.e., the AS will consider the sender of the message to beeliminated by employing inherent SIP security mechanisms, such as TLS. However, ifauthenticated. If thisentityispart of the communication itselfnot true, thenreference integrity needsthis procedure reverts back tobe provided. Assertions with tight restrictions (e.g., validity ofStep 1, above. Otherwise, theassertion) can also limitAS carries out all other processing of thepossible damage. 10.3 Forged Assertion Threat: A malicious user could forge or alter a SAML assertionmessage as stipulated inorder[I-D.ietf-sip-identity] Steps 1 and 2, and if successful, this procedure procedes tocommunicate withthe next step below. 7.1.3.3. AS Authorizes the SIPentities. Countermeasures: To avoidRequest and Forwards it to Verifier This first portion of thiskindstep maps to Steps 3 and 4 ofattack,Section 5 "Authentication Service Behavior" of [I-D.ietf-sip-identity], which theentities must assure that proper mechanisms for protectingAS MUST perform, although with the following additional substeps: The AS MUST construct a SAML assertionneedsaccording tobethe "Assertion Profile Description" specified inplace. It is recommended to protectSection 7.1.4 of this specification. The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. The AS MUST use theassertion using a digital signature. 10.4 Replay Attack Threat: InURI constructed in thecase of using SIP with a 'by-reference' model,immediately preceding substep as thethreatvalue ofreplay lies inthefactIdentity-Info header thatthe artifactisa one-time-use subject. The same artifact can be used again to gain accessadded toresources. Countermeasures: Cases where multiple requests are made which referencesthesameSIP requestmust be tracked in order to avoid the threat. 11. Contributors The authors would like to thank Henning Schulzrinne for his contributions to this document. 12. Acknowledgments We would like to thank RL 'Bob' Morgan and Stefan Goeman for their comments to this draft. 13. IANA Considerations This document contains a numbermessage per Step 4 ofIANA considerations. A future versionSection 5 of [I-D.ietf-sip- identity]. Upon successful completion of all of the above, the AS forwards the request message. At thisdocument will list thempoint in thissection. 14. Open Issues This document raises astep, after perhaps traversing some number ofissues with regard tointermediaries, the SIPprotocol interaction. Some of themrequest message arrives at a SIP network entity performing the "verifier" role. This role and its behavior areraisedspecified inthis document (such as reference integrity, who is allowed to add which information, etc.) but a more detailed treatmentSection 6 "Verifier Behavior" ofthis topic[I-D.ietf-sip- identity]. The verifier MUST perform the steps enumerated in the aforementioned section, witha focusthe following modifications: Step 1 ofidentity management[I-D.ietf-sip-identity] Section 6 maps to and isdescribed in [I-D.peterson-message-identity]. In particular,updated by, the followingsections are highly relevant fortwo steps in thisdocument: Assertion Constraintsprocedure. Steps 2, 3, andScope: This aspect deals with the problem4 ofbinding[I-D.ietf-sip-identity] Section 6 may be mapped across this latter portion of this step, and/or the following two steps, as appropriate. 7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 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 toa specific SIP message. The goal is to provide a security property called reference integrity(e.g., due toprevent replay and impersonation attacks. As describedlocal policy), it MUST dereference the the HTTP-based SAML URI Reference found in the SIP message's Identity-Info header. To do so, the verifier MUST employ the "SAML HTTP-URI-based SIP Binding" specified in Section5 that a number of fields can be used for this purpose.8.1. 7.1.3.5. AS Returns SAML Assertion Thisdocumentstep alsoconsiders scenarios whereemploys Section 8.1 "SAML HTTP-URI-based SIP Binding". If theSAML assertion was obtained outsideprior step returns an HTTP error (e.g., 4xx series), then this procedure terminates and the verifier returns (upstream) a SIPprotocol run. In these cases SIP fields are not available to provide reference integrity. The concept of436 'Bad Identity-Info' Response code. Otherwise, theholder-of-the-keyHTTP response message will contain a SAML assertionis described belowandrelevant for this discussion. Canonicalization versus Replication: To provide reference integrity a few selected fields need tobehashed, signed and placed intodenoted as such via theassertion. Two approaches are available forMIME media type of "application/ samlassertion+xml" [IANA.application.samlassertion-xml]. The verifier MUST perform the verification steps specified in Section 7.1.5 "Assertion Verification", below. If successful, then thispurpose. Henceprocedure continues with the next step. 7.1.3.6. Verifier performs 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 itneeds to be studiedreceived. 7.1.4. Assertion Profile Description This section defines the particulars of how theinterworking between reference integrity andsender, i.e., theusageSAML Authority, MUST construct certain portions ofobtainedthe SAML assertions it issues. The schema for SAML assertions themselves is defined in Section 2.3 of [OASIS.saml-core-2.0-os]. An example SAML assertion, formulated according to this profile is given in Section 9. Overall SAML assertioncan be properly accomplished. For example, who indicates which fields are included? Alignment with SIP Identity: It mightprofile requirements: The SAML assertion MUST begoodsigned by the same key as used toavoidsign thedefinitioncontents ofa second setthe Identity header field. Signing ofresponse codes forSAMLconditions which will overlap with the response codesassertions is definedfor SIP Identity draft. Placementin Section 5.4 ofAssertions and Keys[OASIS.saml-core-2.0-os]. In the following subsections, the SAML assertion profile is specified element-by-element, inMessages: This document assumes thata top-down, depth-first manner, beginning with theassertionsoutermost element, "<Assertion>". Where applicable, the requirements for an element's XML attributes areadded toalso stated, as a part of theSIP body and artifactselement's description. Requirements for any given element orreferences to assertions locatedXML attribute are only stated when, in theSIP bodycontext of use of this profile, they areadded tonot already sufficiently defined by [OASIS.saml-core-2.0-os]. 7.1.4.1. Element: <Assertion> Attribute: ID The value for theSIP header. A central question is therefore where these assertions shouldID XML attribute SHOULD beattached? Shouldallocated randomly such that theSIP user agent or intermediate SIP proxies add assertions/artifacts? Invalue meets thescenarios depictedrandomness requirments specified in Section6, we have both approaches depending on what kind1.3.4 ofscenario it is. In Figure 4, they are added[OASIS.saml-core-2.0-os]. Attribute: IssueInstant The value for the IssueInstant XML attribute SHOULD be set at theUA and in contrast we have Figure 7, wheretime theassertions are added atSAML assertion is created (and cached for subsequent retrieval). This time instant value MAY be temporally thePSTN/SIP gateway. MIME bodies can onlysame as that encoded in the SIP message's Date header, and MUST beattachedatthe UA. Proxies by definition do not attach MIME bodies; if an intermediary were to do so,least temporally later, although it is RECOMMENDED that itwouldnot beplaying10 minutes or more later. 7.1.4.1.1. Element: <Issuer> The value for theproxy server roleIssuer XML element MUST be a value that matches either the Issuer or the Issuer Alternative Name fields [RFC3280] in theSIP architecture. The SIP content indirection mechanism [I-D.ietf- sip-content-indirect-mech] is also relevantcertificate conveyed by the SAML assertion in the ds: X509Certificate element located on thisdiscussion. To provide reference integrity (by bindingpath within the SAML assertion: <Assertion <ds:Signature <ds:KeyInfo <ds:X509Data <ds:X509Certificate 7.1.4.1.2. Element: <Subject> The <Subject> element SHOULD contain both aSIP session<NameID> element and aSAML assertion together) two alternative approaches exist: Hashing<SubjectConfirmation> element. The value ofSIP message fields: If a hash is computed over a numberthe <NameID> element MUST be the same as the Address ofselected SIP fields and subsequently digitally signed then there is a some degreeRecord (AoR) value used in computing the "signed-identity-digest" which forms the value ofprotection thattheassertion cannotIdentity header. See Section 9 of [I-D.ietf-sip-identity]. The <SubjectConfirmation> element attribute Method SHOULD be set to the value: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches Although it MAY becopiedset to some other implementation- and/or deployment-specific value. The <SubjectConfirmation> element itself SHOULD be empty. 7.1.4.1.3. Element: <Conditions> The <Conditions> element SHOULD contain an <AudienceRestriction> element, which itself SHOULD contain an <Audience> element. The value of the <Audience> element SHOULD be the same as the addr-spec of the SIPmessages and reused.request's To header field. Thedrawback thereby is thatfollowing XML attributes of theassertion has<Conditions> element MUST be set as follows: Attribute: NotBefore The value of the NotBefore XML attribute MUST be set to avery limitedtimeperiod.instant the same as the value for the IssueInstant XML attribute discussed above, or to a later time. Attribute: NotOnOrAfter Thehashed fields may vary from contextvalue of the NotOnOrAfter XML attribute MUST be set tocontext. Holder-of-the-Key Assertion:a time instant later than the value for NotBefore. 7.1.4.1.4. Element: <AttributeStatement> The SAMLintroducesassertion MAY contain an <AttributeStatement> element. If so, theconcept<AttributeStatement> element will contain attribute-value pairs, e.g., of aholder-of-the-key assertionuser profile nature, encoded according tobindeither one of theassertions (authorization information)"SAML Attribute Profiles" as specified in [OASIS.saml- profiles-2.0-os], 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 acryptographic key. AsSAML assertion formulated per this overall section is stating that they do. 7.1.5. Assertion Verification This section specifies the steps that aresult,verifier participating in this profile MUST perform in addition to theend host which was quite passive when dealing with assertions can be turned into an active protocol participant."Verifier Behavior" specified in Section 6 of [I-D.ietf-sip-identity]. Theend host obtainedsteps are: 1. Before Step 1 in Section 6 of [I-D.ietf-sip-identity], theassertion and attached them to selected messages but did not provide any cryptographic computations with regard toverifier MUST extract theassertion itself. WithAS's domain certificate from the <ds: X509Certificate> XML element at the endhost being activeof the element path given in Section 7.1.4.1.1. 2. Perform Step 1 in Section 6 of [I-D.ietf-sip-identity]. 3. After Step 1 in Section 6 of [I-D.ietf-sip-identity], but before Step 2 of that section, theprotocol exchange security is improvedverifier MUST verify the SAML assertion's signature via the procedures specified in Section 5.4 of [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. @@ TODO: do we need to define alot. Furthermore, itnew SIP error response code for when a SAML assn signature ispossible to combinebad? e.g., '4xx Invalid SAML asssertion'. 4. Perform Step 2 in Section 6 of [I-D.ietf-sip-identity]. 5. Verify that thebenefitssigner of thework done with SIPPING-CERT [I-D.ietf-sipping-certs] and this document by binding a self-signed certificate created bySIP message's Identity header field is theuser and stored atsame as thecredential server to ansigner of the SAML assertion.As noted6. Perform Steps 3 and 4 in Section96 of[I-D.ietf-sipping-certs][I-D.ietf-sip-identity]. 7. Verify that the SAML assertion's <Issuer> element value matches the Issuer or the Issuer Alternative Name fields [RFC3280] in thecontextAS's domain certificate. 8. Verify that the SAML assertion's <NameID> element value is the same as the Address ofsigning SIP messagesRecord (AoR) value in theusage"signed- identity-digest". See Section 9 ofa self-signed certificate[I-D.ietf-sip-identity]. 9. Verify that the SAML assertion's <SubjectConfirmation> element value isnot very helpful except used with an Authentication Service. Combined with aset to whichever value was configured at implementation- or deployment-time. The default value is: urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 10. Verify that the SAML assertion contains an <Audience> element, and that its value matches thesignature would protectvalue of the addr-spec of the SIPmessageTo header field. 11. Verify that the validity period denoted by the NotBefore and NotOnOrAfter attributes of the <Conditions> element meets the requirements given in Section 7.1.4.1.3. 8. SAMLassertion would provide authorization information. A numberSIP Binding This section specifies one SAML SIP Binding at this time. Additional bindings may be specified in future revisions ofcredentialsthis specification. 8.1. SAML HTTP-URI-based SIP Binding 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 [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies a means by which SAML assertions can beusedreferenced by URIs and thus be obtained through resolution of such URIs. This profile of the SAML URI Binding is congruent with theKeyInfo element ofSAML URI Binding -- including support for HTTP-based URIs being mandatory to implement -- except for theHolder-of-the-Key assertion as describedfollowing further restrictions which are specified inSection 4.4the interest of[xmldsig- core]. Further open issues are: o Some work on option-tagsinteroperability (section numbers refer to [OASIS.saml-bindings-2.0-os]): Section 3.7.5.3 Security Considerations: Support for TLS 1.0 or SSL 3.0 isrequired. Are there casesmandatory to implement. Section 3.7.5.4 Error Reporting: All SHOULDs in this section are to be interpreted as MUSTs. 9. Example Signed SAML Assertion Below is an example of a signed SAML assertion: <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2003-04-17T00:46:02Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Issuer> example.com </Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc"> <ds:Transforms> <ds:Transform Algorithm= "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm= "http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces PrefixList="#default saml ds xs xsi" xmlns= "http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue> Kclet6XcaOgOWXM4gty6/UNdviI= </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubnmIfZ6RqVL+wNmeWI4= </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <Subject> <NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> Alice@example.com </NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/> </Subject> <Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2003-04-17T00:51:02Z"> <AudienceRestriction> </AudienceRestriction> </Conditions> <AttributeStatement> ... </AttributeStatement> </Assertion> 10. Security Considerations This section discusses security considerations whenprocessingusing SAML with SIP. 10.1. Man-in-the-middle Attacks and Stolen Assertions Threat: By making SAML assertions available via HTTP-based requests by a potentially unbounded set ofthe assertionrequesters, it is conceivably possible that anyone would berequired byable to simply request one and obtain it. SIP intermediaries on thesender? Or whensignaling path for example. Or, an HTTP intermediary/proxy could intercept the assertion as it is being returned to aproxy server wantsrequester. The attacker could then conceivably attempt tobe ableimpersonate the subject (the putative caller) tosaysome SIP-based target entity. Countermeasures: Such an attack is implausible for several reasons. The primary reason is that aUA must supply thismessage constructed by an imposter using a stolen assertion that conveys the public key certificate of some domain will not verify per [I-D.ietf-sip-identity] because the imposter will not have the corresponding private key with which to generate the signed Identity headerin ordervalue. Also, the SIP SAML assertion profile specified herein that the subject's SAML assertion must adhere toaccess a particular resource? If so, an option-tagcauses it to be not useful to arbitrary parties. The subject's assertion: * should bedefined forsigned, thus causing any alterations to break its integrity and make such alterations detectable. * does not contain an authentication statement. Thus no parties implementing thisextension that canspecification should beused in Require, Supported, 420, etc. o Specificrelying on SAMLconfirmation method identifiersassertions specified herein as sufficient in andidentifiers forof themselves to allow access to resources. * relying party is represented in thebindings or profiles must be defined and registered with OASIS. A confirmation method identifierSAML assertion's Audience Restriction. * Issuer isa URI that specifies which method should be used byrepresented in thetarget domainSAML assertion. * validity period for assertion is restricted. * etc. 10.2. 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 theidentitySAML assertion are employed, e.g., signing the SAML assertion itself. Section 5.1 of [OASIS.saml- core-2.0-os] specifies thesubject is true. This mechanism seemssigning of SAML assertions. Additionally, the assertion content dictated by the SAML assertion profile herein ensures ample evidence for a relying party tobe provideverify thesame reference integrity properties asassertion and its relationship with thehash overreceived SIP request. 10.3. Replay Attack Threat: Theft of SIP message protected by the mechanisms described herein and replay of it at a later time. Countermeasures: There are variousheaders/bodies proposed in the identity draft. o Further use cases would be interesting. For example,provisions within [I-D.ietf-sip-identity] that prevent amechanismreplay attack. 11. Contributors The authors would like toprovide additional securitythank Marcus Tegnander and Henning Schulzrinne forthe SIP REFER method [RFC3515]. o A few new URIs needhis contributions tobe registered. The proposed URIsearlier versions of this document. 12. Acknowledgments We would like to thank RL 'Bob' Morgan and Stefan Goeman foridentification 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 URIstheir comments to this draft. 13. Acknowledgments We thank RL 'Bob' Morgan forConfirmation Method Identifiers are: Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01his inputs to this work. The "AS-driven SIP SAML URI-based Attribute Assertionprofile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer o These areFetch Profile" is based on an idea by Jon Peterson. Addtionally, theURIs already used in the existing SOAP-SAML binding, specified in Section 3following persons provided input to this work: Stefan Goeman, Shida Schubert, Jason Fischl 14. IANA Considerations This document contains a number of[I-D.saml-bindings-1.1]. o An alignment with the work done by Liberty Alliance on Federated Identities as describedIANA considerations. A future version of this document will list them in[I-D.liberty-idff-arch-overview] would be useful. o The security consideration needs more details.this section. 15. Open Issues A list of open issues can be found at: http://www.tschofenig.com:8080/saml-sip/ 16. References15.116.1. Normative References[I-D.hodges-saml-mediatype] Hodges, J., "application/saml+xml Media Type Registration", draft-hodges-saml-mediatype-01[I-D.ietf-sip-identity] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress),June 2004.October 2005. [I-D.ietf-sipping-trait-authz] Peterson, J., "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)",draft-ietf-sipping-trait-authz-01draft-ietf-sipping-trait-authz-02 (work in progress),FebruaryJanuary 2006. [OASIS.saml-bindings-2.0-os] Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Maler, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-bindings-2.0-os, March 2005. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 2005. [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.15.2 Informative References [I-D.ietf-sip-authid-body][RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J.,"SIPSparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003. [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format",draft-ietf-sip-authid-body-03 (work in progress), MayRFC 3893, September 2004. [W3C.xmldsig-core] Eastlake, D., Reagle , J., and D. Solo, "XML-Signature Syntax and Processing", W3C Recommendation xmldsig-core, October 2000, <http://www.w3.org/TR/xmldsig-core/>. 16.2. Informative References [I-D.ietf-sip-content-indirect-mech] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-05 (work in progress), October 2004.[I-D.ietf-sip-identity] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), May 2005.[I-D.ietf-sipping-certs] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)",draft-ietf-sipping-certs-01draft-ietf-sipping-certs-02 (work in progress),FebruaryJuly 2005. [I-D.jennings-sipping-pay] Jennings, C., "Payment for Services in Session Initiation Protocol (SIP)",draft-jennings-sipping-pay-01draft-jennings-sipping-pay-03 (work in progress),FebruaryOctober 2005.[I-D.liberty-idff-arch-overview] Wason, T., "Liberty ID-FF Architecture Overview", 2004.[I-D.peterson-message-identity] Peterson, J., "Security Considerations for Impersonation and Identity in Messaging Systems", draft-peterson-message-identity-00 (work in progress), October 2004.[I-D.saml-bindings-1.1] Maler, E.,[IANA.application.samlassertion-xml] OASIS Security Services Technical Committee (SSTC), "application/samlassertion+xml MIME Media Type Registration", IANA MIME Media Types Registry application/ samlassertion+xml, December 2004. [OASIS.draft-saml-protocol-ext-02] Cantor, S., "SAML Protocol Extensions", OASIS SSTC Working Draft draft-saml-protocol-ext-02, Februrary 2006. [OASIS.saml-conformance-2.0-os] Mishra, P., Philpott, R., andP. Mishra, "Bindings and ProfilesE. Maler, "Conformance Requirements for theOASISSecurity Assertion Markup Language (SAML)V1.1", September 2003. [I-D.saml-core-1.1] Maler, E.,V2.0", OASIS Standard saml-conformance-2.0-os, March 2005. [OASIS.saml-glossary-2.0-os] Hodges, J., Philpott, R., andP. Mishra, "Assertions and ProtocolE. Maler, "Glossary for theOASISSecurity Assertion Markup Language (SAML)V1.1", September 2003. [I-D.saml-sec-consider-1.1] Maler, E. and R.V2.0", OASIS Standard saml-glossary-2.0-os, March 2005. [OASIS.saml-sec-consider-2.0-os] Hirsch, F., Philpott, R., and E. Maler, "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.V2.0", OASIS Standard saml-sec-consider- 2.0-os, March 2005. [OASIS.sstc-saml-exec-overview-2.0-cd-01] Madsen, P. andJ. Hughes, "Technical Overview of theE. Maler, "SAML V2.0 Executive Overview", OASISSecuritySSTC Committee Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. [OASIS.sstc-saml-tech-overview-2.0-draft-08] Hughes, J. and E. Maler, "Security Assertion Markup Language (SAML)V1.1", March 2004.V2.0 Technical Overview", OASIS SSTC Working Draft sstc-saml-tech-overview-2.0-draft-08, September 2005. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.[RFC3515] Sparks, R., "The[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol(SIP) Refer Method",(SIP)", RFC3515, April 2003. [xmldsig-core] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing, W3C Recommendation (available at http://www.w3.org/TR/xmldsig-core/)", February3323, November 2002. Authors' Addresses Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 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 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 430 Boulder, CO 80309 US Email: douglas.sicker@colorado.eduMarcus Tegnander Letterkenny Institute of Technology Port Road Letterkenny, Donegal IrelandJeff Hodges NeuStar, Inc. 2000 Broadway Street Redwood City, CA 94063 US Email:schwed@gmail.comJeff.Hodges@neustar.biz 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(2005).(2006). 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.