idnits 2.17.00 (12 Aug 2021) /tmp/idnits27593/draft-ietf-sip-saml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1599. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1612. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 240 has weird spacing: '...ich the asser...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 28, 2007) is 5472 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2392' is defined on line 1210, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-content-indirect-mech' is defined on line 1253, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-certs' is defined on line 1259, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-message-identity' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1315, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Downref: Normative reference to an Informational RFC: RFC 4484 == Outdated reference: draft-ietf-sip-content-indirect-mech has been published as RFC 4483 == Outdated reference: A later version (-06) exists of draft-jennings-sipping-pay-05 -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track J. Hodges 5 Expires: November 29, 2007 J. Peterson 6 NeuStar, Inc. 7 J. Polk 8 Cisco 9 D. Sicker 10 CU Boulder 11 May 28, 2007 13 SIP SAML Profile and Binding 14 draft-ietf-sip-saml-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on November 29, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document specifies a Session Initiation Protocol (SIP) profile 48 of Security Assertion Markup Language (SAML) as well as a SAML SIP 49 binding. The defined SIP SAML Profile composes with the mechanisms 50 defined in the SIP Identity specification and satisfy requirements 51 presented in "Trait-based Authorization Requirements for the Session 52 Initiation Protocol (SIP)". 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 8 61 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9 62 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 11 63 6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. AS-driven SIP SAML URI-based Attribute Assertion 65 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1.1. Required Information . . . . . . . . . . . . . . . . . 13 67 6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 13 68 6.1.3. Profile Description . . . . . . . . . . . . . . . . . 17 69 6.1.4. Assertion Profile Description . . . . . . . . . . . . 20 70 6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 22 71 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 24 72 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 24 73 8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 25 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 75 9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 30 76 9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 31 77 9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 31 78 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 81 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 84 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 85 Appendix A. Appendix: Use-case Scenarios . . . . . . . . . . . . 40 86 A.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 40 87 A.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 41 88 A.3. Compensation using SIP and SAML . . . . . . . . . . . . . 43 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 90 Intellectual Property and Copyright Statements . . . . . . . . . . 46 92 1. Introduction 94 This document specifies composition of the Security Assertion Markup 95 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 96 richer authorization mechanisms and enable "trait-based 97 authorization." Trait-based authorization is where one is authorized 98 to make use of some resource based on roles or traits rather than 99 ones identifier(s). Motivations for trait-based authorization, along 100 with use-case scenarios, are presented in [RFC4484]. 102 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 103 based framework for creating and exchanging security information. 104 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 105 [OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative 106 overviews of SAMLv2. The SAMLv2 specification set is normatively 107 defined by [OASIS.saml-conformance-2.0-os]. 109 Various means of providing trait-based authorization exist: 110 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 111 to the authenticated identity body [RFC3893]. The authors selected 112 SAML due to its increasing use in environments such as the Liberty 113 Alliance, and the Internet2 project, areas where the applicability to 114 SIP is widely desired. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 The SIP network element "Authentication Service" is introduced in 123 [RFC4474]. We reuse this term to refer to a network element that 124 authenticates and authorizes a user and creates a "SIP identity 125 assertion". This system entity is the logical equivalent of a "SAML 126 Authority" in the SAML terminology. 128 For overall SIP terminology, see [RFC3261]. 130 In this specification, the term, or term component, "SAML" refers to 131 SAML V2.0 in all cases. For example, the term "SAML assertion" 132 implicitly means "SAMLv2 assertion". For overall SAML terminology, 133 see [OASIS.saml-glossary-2.0-os]. 135 The below list maps other various SIP terms to their SAML 136 (rough-)equivalents: 138 Element, Network Element: 140 System Entity, Entity 142 Authentication Service: 144 SAML Authority 146 Invitee, Invited User, Called Party, Callee: 148 Relying Party 150 Server, User Agent Server (UAS): 152 SAML Responder 154 User Agent Client (UAC), client: 156 SAML Requester 158 Additional terms defined in the context of this specification: 160 profile attribute(s): 162 one or more attributes of a "user profile". 164 user profile, subject profile: 166 the set of various attributes accompanying (i.e., mapped to) a 167 user account in many environments. 169 3. SAML Introduction 171 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 172 [OASIS.sstc-saml-tech-overview-2.0-draft-08] defines an XML-based 173 framework for exchanging "security assertions" between entities. In 174 the course of making, or relying upon such assertions, SAML system 175 entities may use SAML protocols, or other protocols, to communicate 176 an assertion itself, or the subject of an assertion. 178 Thus one can employ SAML to make and encode statements such as "Alice 179 has these profile attributes and her domain's certificate is 180 available over there, and I'm making this statement, and here's who I 181 am." Then one can cause such an assertion to be conveyed to some 182 party who can then rely on it in some fashion for some purpose, for 183 example input it into some local policy evaluation for access to some 184 resource. This is done in a particular "context of use". Such a 185 context of use could be, for example, deciding whether to accept and 186 act upon a SIP-based invitation to initiate a communication session. 188 The specification of how SAML is employed in a particular context of 189 use is known as a "SAML profile". The specification of how SAML 190 assertions and/or protocol messages are conveyed in, or over, another 191 protocol is known as a "SAML Binding". Typically, a SAML profile 192 specifies the SAML bindings that may be used in its context. Both 193 SAML profiles and SAML bindings reference other SAML specifications, 194 especially the SAML Assertions and Protocols, aka "SAML Core", 195 specification [OASIS.saml-core-2.0-os]. 197 There is an additional subtle aspect of SAML profiles that is worth 198 highlighting -- the notion of a "SAML assertion profile". A SAML 199 assertion profile is the specification of the assertion contents in 200 the context of a particular SAML profile. It is possibly further 201 qualified by a particular implementation and/or deployment context. 202 Condensed examples of SAML assertion profiles are: 204 o The SAML assertion must contain at least one authentication 205 statement and no other statements. The relying party must be 206 represented in the element. The 207 SubjectConfirmation Method must be Foo. etc. 209 o The SAML assertion must contain at least one attribute statement 210 and may contain more than one. The values for the subject's 211 profile attributes named "Foo" and "Bar" must be present. An 212 authentication statement may be present. etc. 214 The primary facets of SAML itself are: 216 o Assertions 218 o Abstract Request/Response protocol 220 We describe each in turn below: 222 3.1. SAML Assertions 224 A SAML assertion is a package of information including issuer and 225 subject, conditions and advice, and/or attribute statements, and/or 226 authentication statements and/or other statements. Statements may or 227 may not be present. The SAML assertion "container" itself contains 228 the following information: 230 Issuing information: 232 Who issued the assertion, when was it issued and the assertion 233 identifier. 235 Subject information: 237 The name of the subject, the security domain and optional subject 238 information, like public key. 240 Conditions under which the assertion is valid: 242 Special kind of conditions like assertion validity period, 243 audience restriction and target restriction. 245 Additional advice: 247 Explaining how the assertion was made, for example. 249 In terms of SAML assertions containing SAML attribute statements or 250 SAML authentication statements, here are explanatory examples: 252 With a SAML assertion containing a SAML attribute statement, an 253 issuing authority is asserting that the subject is associated with 254 certain attributes with certain subject profile attribute values. 255 For example, user jon@cs.example.com is associated with the 256 attribute "Department", which has the value "Computer Science". 258 With a SAML assertion containing a SAML authentication statement, 259 an issuing authority is asserting that the subject was 260 authenticated by certain means at a certain time. 262 With a SAML assertion containing both a SAML attribute statement 263 and a SAML authentication statement, an issuing authority is 264 asserting the union of the above. 266 3.2. Abstract Request/Response Protocol 268 SAML defines an abstract request/response protocol for obtaining 269 assertions. See Section 3 "SAML Protocols" of 270 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 271 response returns the requested assertion or an error. This abstract 272 protocol may then be cast into particular contexts of use by binding 273 it to specific underlying protocols, e.g., HTTP or SIP, and 274 "profiling" it for the specific use case at hand. The SAML HTTP- 275 based web single sign-on profile is one such example (see Section 4.1 276 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 277 based SIP communication session establishment, the topic of this 278 specification, is another. 280 4. Specification Scope 282 The scope of this specification is: 284 o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such 285 that a subject's profile attributes, and their domain's 286 certificate, can be conveyed to a relying party using SAML. In 287 doing so, satisfy the requirements outlined in [RFC4484], and 288 compose with [RFC4474]. 290 The following are outside the scope of this specification: 292 o Defining a means for configuring the runtime behavior, or 293 deployment characteristics, of the Authentication Service. 295 Discussion: 297 For example, a SIP Authentication Service could be implemented 298 such that its SAML-based features are employed, or not, on a 299 subject-by-subject basis, and/or on a domain-by-domain basis. 301 o The definition of specific conveyed subject profile attributes 302 (aka traits). 304 Discussion: 306 This specification defines a facility enabling "trait-based 307 authorization" as discussed in [RFC4484]. 309 The attributes of interest in trait-based authorization will be 310 ones akin to, for example: roles, organizational membership, 311 access rights, or authentication event context. Definition of 312 such attributes is application- and/or deployment-context- 313 dependent and are not defined in this specification. However, The 314 SAMLv2 specification defines several "SAML Attribute Profiles" for 315 encoding attributes from various application domains, e.g., LDAP, 316 UUID/GUID, DCE PAC, and XACML, in SAML assertions 317 [OASIS.saml-profiles-2.0-os]. 319 In order for any trait-based system to be practical, participating 320 entities must agree on attributes and traits that will be conveyed 321 and subsequently relied upon. Without such agreements, a trait- 322 based system cannot be usefully deployed. This specification does 323 not discuss the manner in which participating entites might 324 discover one another or agree on the syntax and semantics of 325 attributes and traits. 327 Note that SAMLv2 specifies a "metadata" facility that may be 328 useful in addressing this need. 330 5. Employing SAML in SIP 332 Employing SAML in SIP necessitates devising a new SAML profile(s) and 333 binding(s) because the those already specified in the SAMLv2 334 specification set are specific to other use contexts, e.g., HTTP- 335 based web browsing. Although SIP bears some similarity to HTTP, it 336 is a seperately distinct protocol, thus requiring specification of 337 SIP-specific SAML profile(s) and binding(s). This is technically 338 straightforward as both SAML and SIP are explicitly extensible. 340 The "Authenticated Identity Management in SIP" specification 341 [RFC4474] (aka "SIP Identity") facilitates the composition of SAML 342 and SIP in that it defines a "mediated authentication architecture" 343 where verifying endpoints verify SIP identity assertions -- i.e., the 344 "Identity" header value -- signed by an Authentication Service (AS). 345 The semantic being that the AS is vouching that it did indeed 346 authenticate the calling party. 348 Such an Authentication Service, which likely has access to various 349 pieces of information concerning the calling party, could also act as 350 a SAML Authority, and make such information available to the callee 351 via SAML. 353 Since [RFC4474] stipulates that the AS must make its certificate 354 available for retrieval and convey the availability and access 355 mechanism via a URI, in the Identity-Info header, we have an 356 opportunity to compose SIP Identity and SAML. 358 Such composition can be accomplished by having the resource referred 359 to by the URI in the Identity-Info be a SAML assertion conveying both 360 the AS's certificate and user profile attributes. This is the 361 approach defined in this specification. Figure 1 illustrates this 362 approach in a high-level summary fashion. Figure 2, further below, 363 illustrates additional details. 365 +--------+ +--------------+ +--------+ 366 |Alice@ | |Authentication| | Bob@ | 367 |example | |Service | |example2| 368 |.com | |@example.com | |.com | 369 | | | | | | 370 +---+----+ +------+-------+ +---+----+ 371 | | | 372 | INVITE | | 373 |---------------------->| | 374 | From:alice@foo.com | | 375 | | | 376 | 407 Proxy auth. req. | | 377 |<----------------------| | 378 | Challenge | | 379 | | | 380 | ACK | | 381 |---------------------->| | 382 | | | 383 | INVITE w/authn creds | | 384 |---------------------->| | 385 | | INVITE | 386 | | w/Identity header | 387 | |--------------------->| 388 | | and Identity-Info | 389 | | | 390 | | HTTP GET SAML assn | 391 | |<==================== | 392 | | and domain cert | 393 | | | 394 | | HTTP 200 OK + assn | 395 | |=====================>| 396 | | and domain cert | 397 | 200 OK | | 398 |<----------------------+----------------------| 399 | | | 401 Figure 1: SIP-SAML-based Network Asserted Identity 403 Since the AS already being trusted to create and add the Identity 404 header containing the SIP Identity Assertion, and to supply a pointer 405 to its domain certificate, having it point instead to a SAML 406 assertion conveying the domain certificate and possibly some user 407 profile attributes, does not significantly alter the first-order 408 security considerations examined in [RFC4474]. This specification 409 provides some additional security considerations analysis below in 410 Section 9. 412 6. SIP SAML Profiles 414 This section defines one SIP SAML profile: 416 The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 417 Profile" 419 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 421 6.1.1. Required Information 423 The information given in this section is similar to the info provided 424 when registering something, a MIME Media Type, say, with IANA. In 425 this case, it is for registering this profile with the OASIS SSTC. 426 See Section 2 "Specification of Additional Profiles" in 427 [OASIS.saml-profiles-2.0-os]. 429 Identification: 431 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 433 @@ NOTE: This URN must be agreed upon, and then registered with 434 IANA per [RFC3553]. 436 Contact Information: 438 @@ someone's or something's contact info goes here 440 SAML Confirmation Method Identifiers: 442 The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is 443 used in this profile. 445 Description: 447 Given below. 449 Updates: 451 None. 453 6.1.2. Profile Overview 455 Figure 2 illustrates this profile's overall protocol flow. The 456 following steps correspond to the labeled interactions in the figure. 457 Within an individual step, there may be one or more actual message 458 exchanges depending upon the protocol binding employed for that 459 particular step and other implementation-dependent behavior. 461 Although this profile is overview is cast in terms of a SIP INVITE 462 transaction, the reader should note that the mechanism specified 463 herein, and in [RFC4474], may be applied to any SIP request message. 465 Figure 2 begins on the next page. 467 +------------------+ +------------------+ +-----------------+ 468 | Caller | |Authn Service (AS)| | Callee | 469 |Alice@example.com | | @example.com | | Bob@example2.com| 470 +--------+---------+ +--------+---------+ +--------+--------+ 471 - - | | | (steps) 472 ^ ^ | INVITE | | 473 | | |---------------------->| | (1a) 474 | | From:alice@foo.com | | 475 | C | To:sip:bob@example.com| | 476 | S | | | 477 | e | 407 Proxy auth. req. | | 478 | q |<----------------------| | (1b) 479 | = | Challenge | | 480 | N | | | 481 | | ACK | | 482 | | |---------------------->| | (1c) 483 | V | | | 484 | - | | | 485 ^ | INVITE + authorization| | 486 D | | header w/ creds | | 487 | |---------------------->| | (2) 488 I | | From:alice@foo.com | | 489 | | To:sip:bob@example.com| | 490 A | Proxy-Authorization:..| | 491 C | | INVITE | 492 L S | |--------------------->| (3) 493 e | | From:alice@foo.com | 494 O q | | To:sip:bob@example2.com 495 | | Identity: ..... | 496 G = | | Identity-Info: | 497 | | https://example.com| 498 | N | | /assns/?ID=abcde | 499 | | | | 500 | + | |URI resolution (eg. HTTP) 501 | | |<=====================| (4) 502 | 1 | | GET /assns/?ID=abcde | 503 | | | | 504 | | | | HTTP/1.1 200 OK | 505 | | | |=====================>| (5) 506 | | | | | 507 | | | | | 508 | | | | | 509 | | | | Alice@example.com 510 | | | | 511 | | | | 512 | | | | ... 513 | | | | 514 | | | | foo=bar | 515 | | | 200 OK | | 516 | V |<----------------------+----------------------| (6) 517 . - | | | 518 V 520 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 521 Transaction 523 Step 1. Initial SIP Transaction between Caller and AS 525 This optional initial step is comprised of substeps 1a, 1b, 526 and 1c in Figure 2. In this step, the caller, Alice, sends 527 a SIP request message, illustrated as an INVITE, indicating 528 Bob as the callee (1a), is subsequently challenged by the AS 529 (1b), and sends an ACK in response to the challenge (1c). 530 The latter message signals the completion of this SIP 531 transaction (which is an optional substep of this profile). 533 Step 2. Caller sends SIP Request Message with Authorization 534 Credentials to the AS 536 Alice then sends an INVITE message in response to the 537 challenge, or uses cached credentials for the domain if step 538 1 was skipped, as specified in [RFC4474] and [RFC3261]. 539 Depending on the chosen SIP security mechanism for client 540 authentication either digest authentication, client side 541 authentication of Transport Layer Security, or a combination 542 of both is used to provide the AS with a strong assurance 543 about the identity of Alice. 545 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 547 First, the AS authorizes the received INVITE message as 548 specified in [RFC4474] and [RFC3261]. If the authorization 549 is successful, the AS will form the "identity signature" for 550 the message and add Identity and Identity-Info header fields 551 to the message. The AS also at this time constructs and 552 caches a SAML assertion asserting Alice's profile attributes 553 required by Bob's domain (example2.com), and also containing 554 a the domain's (example.com) public key certificate, or a 555 reference to it. This certificate MUST contain the public 556 key corresponding to the private key used to construct the 557 signature whose value was placed in the Identity header. 558 The AS constructs a HTTP-based SAML URI Reference 559 incorporating the assertion's Assertion ID (see section 560 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as 561 the value for the Identity-Info header it adds to the INVITE 562 message. 564 The AS determines which profile attributes (if any) to 565 assert in the via local configuration 566 and/or obtaining example2.com's metadata 567 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 568 INVITE message to Bob. 570 Step 4. Callee Dereferences HTTP-based SAML URI Reference 572 Bob's UAC or SIP Proxy receives the message and begins 573 verifying it per the "Verifier Behavior" specified in 574 [RFC4474]. In order to accomplish this task, it needs to 575 obtain Alice's domain certificate. It obtains the HTTP- 576 based SAML URI Reference from the message's Identity-Info 577 header and dereferences it per Section 7.1. Note that this 578 is not a SIP message, but an HTTP message [RFC2616]. 580 Step 5. AS Returns SAML Assertion 582 Upon receipt of the above HTTP request, which contains an 583 embedded reference to Alice's SAML Assertion, Alice's AS 584 returns her assertion in an HTTP response message. 586 Upon receipt of Alice's SAML Assertion, the AS continues its 587 verification of the INVITE message. If successful, it 588 returns a 200 OK message directly to Alice. Otherwise it 589 returns an appropriate SIP error response. 591 Step 6. Callee Returns SIP 200 OK to Caller 593 If Bob determines, based upon Alice's identity as asserted 594 by the AS, and as further substantiated by the information 595 in the SAML assertion, to accept the INVITE, he returns a 596 SIP 200 OK message directly to Alice. 598 6.1.3. Profile Description 600 The following sections provide detailed definitions of the individual 601 profile steps. The relevant illustration is Figure 3, below. Note 602 that this profile is agnostic to the specific SIP request, and also 603 that the Sender and Authentication Service (AS) may be seperate or 604 co-located in actuality. 606 +------------------+ +------------------+ +------------------+ 607 | Sender | |Authn Service (AS)| | Verifier | 608 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 609 +--------+---------+ +--------+---------+ +--------+---------+ 610 | | | (steps) 611 | SIP Request | | 612 |---------------------->| | (1a) 613 | | | 614 | 407 Proxy auth. req. | | 615 |<----------------------| | (1b) 616 | Challenge | | 617 | | | 618 | ACK | | 619 |---------------------->| | (1c) 620 | | | 621 | | | 622 |SIP Req + authorization| | 623 | header w/ creds | | 624 |---------------------->| | (2) 625 | | | 626 | | | 627 | | SIP Req + Ident & | 628 | | authz headers | 629 | |--------------------->| (3) 630 | | | 631 | | URI resolution | 632 | |<=====================| (4) 633 | | (via HTTP) | 634 | | | 635 | | HTTP/1.1 200 OK | 636 | |=====================>| (5) 637 | | | 638 | | | 639 | | ? | (6) 640 | | | 642 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 644 6.1.3.1. Initial SIP Transaction between Sender and AS 646 This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication 647 Service Behavior" of [RFC4474]. If the SIP request sent by the 648 caller in substep 1a is deemed insufficiently authenticated by the AS 649 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 650 authenticate the sender of the message. The particulars of how this 651 is accomplished depend upon implementation and/or deployment 652 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 653 in Figure 3 are non-normative and illustrative only. 655 6.1.3.2. Sender sends SIP Request Message with Authorization 656 Credentials to the AS 658 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 659 Behavior" of [RFC4474]. This request is presumed to be made in a 660 context such that the AS will not challenge it -- i.e., the AS will 661 consider the sender of the message to be authenticated. If this is 662 not true, then this procedure reverts back to Step 1, above. 664 Otherwise, the AS carries out all other processing of the message as 665 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 666 procedure procedes to the next step below. 668 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 670 This first portion of this step maps to Steps 3 and 4 of Section 5 671 "Authentication Service Behavior" of [RFC4474], which the AS MUST 672 perform, although with the following additional substeps: 674 The AS MUST construct a SAML assertion according to the "Assertion 675 Profile Description" specified in Section 6.1.4 of this 676 specification. 678 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 679 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 681 The AS MUST use the URI constructed in the immediately preceding 682 substep as the value of the Identity-Info header that is added to 683 the SIP request message per Step 4 of Section 5 of [RFC4474]. 685 Upon successful completion of all of the above, the AS forwards the 686 request message. 688 At this point in this step, after perhaps traversing some number of 689 intermediaries, the SIP request message arrives at a SIP network 690 entity performing the "verifier" role. This role and its behavior 691 are specified in Section 6 "Verifier Behavior" of [RFC4474]. The 692 verifier MUST perform the steps enumerated in the aforementioned 693 section, with the following modifications: 695 Step 1 of [RFC4474] Section 6 maps to and is updated by, the 696 following two steps in this procedure. 698 Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this 699 latter portion of this step, and/or the following two steps, as 700 appropriate. 702 6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 704 The verifier SHOULD ascertain whether it has a current cached copy of 705 the SIP message sender's SAML assertion and domain certificate. If 706 not, or if the verifier chooses to (e.g., due to local policy), it 707 MUST dereference the the HTTP-based SAML URI Reference found in the 708 SIP message's Identity-Info header. To do so, the verifier MUST 709 employ the "SAML HTTP-URI-based SIP Binding" specified in 710 Section 7.1. 712 6.1.3.5. AS Returns SAML Assertion 714 This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 716 If the prior step returns an HTTP error (e.g., 4xx series), then this 717 procedure terminates and the verifier returns (upstream) a SIP 436 718 'Bad Identity-Info' Response code. 720 Otherwise, the HTTP response message will contain a SAML assertion 721 and be denoted as such via the MIME media type of "application/ 722 samlassertion+xml" [IANA.application.samlassertion-xml]. The 723 verifier MUST perform the verification steps specified in 724 Section 6.1.5 "Assertion Verification", below. If successful, then 725 this procedure continues with the next step. 727 6.1.3.6. Verifier performs Next Step 729 The SIP request was successfully processed. The verifier now 730 performs its next step, which depends at least in part on the type of 731 SIP request it received. 733 6.1.4. Assertion Profile Description 735 This section defines the particulars of how the sender, i.e., the 736 SAML Authority, MUST construct certain portions of the SAML 737 assertions it issues. The schema for SAML assertions themselves is 738 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 740 An example SAML assertion, formulated according to this profile is 741 given in Section 8. 743 Overall SAML assertion profile requirements: 745 The SAML assertion MUST be signed by the same key as used to sign 746 the contents of the Identity header field. Signing of SAML 747 assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. 749 In the following subsections, the SAML assertion profile is specified 750 element-by-element, in a top-down, depth-first manner, beginning with 751 the outermost element, "". Where applicable, the 752 requirements for an element's XML attributes are also stated, as a 753 part of the element's description. Requirements for any given 754 element or XML attribute are only stated when, in the context of use 755 of this profile, they are not already sufficiently defined by 756 [OASIS.saml-core-2.0-os]. 758 6.1.4.1. Element: 760 Attribute: ID 762 The value for the ID XML attribute SHOULD be allocated randomly 763 such that the value meets the randomness requirments specified in 764 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 766 Attribute: IssueInstant 768 The value for the IssueInstant XML attribute SHOULD be set at the 769 time the SAML assertion is created (and cached for subsequent 770 retrieval). This time instant value MAY be temporally the same as 771 that encoded in the SIP message's Date header, and MUST be at 772 least temporally later, although it is RECOMMENDED that it not be 773 10 minutes or more later. 775 6.1.4.1.1. Element: 777 The value for the Issuer XML element MUST be a value that matches 778 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 779 the certificate conveyed by the SAML assertion in the ds: 780 X509Certificate element located on this path within the SAML 781 assertion: 783 791 The element SHOULD contain both a element and a 792 element. 794 The value of the element MUST be the same as the Address of 795 Record (AoR) value used in computing the "signed-identity-digest" 796 which forms the value of the Identity header. See Section 9 of 797 [RFC4474]. 799 The element attribute Method SHOULD be set to 800 the value: 802 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 804 Although it MAY be set to some other implementation- and/or 805 deployment-specific value. The element itself 806 SHOULD be empty. 808 6.1.4.1.3. Element: 810 The element SHOULD contain an 811 element, which itself SHOULD contain an element. The 812 value of the element SHOULD be the same as the addr-spec 813 of the SIP request's To header field. 815 The following XML attributes of the element MUST be set 816 as follows: 818 Attribute: NotBefore 820 The value of the NotBefore XML attribute MUST be set to a time 821 instant the same as the value for the IssueInstant XML attribute 822 discussed above, or to a later time. 824 Attribute: NotOnOrAfter 826 The value of the NotOnOrAfter XML attribute MUST be set to a time 827 instant later than the value for NotBefore. 829 6.1.4.1.4. Element: 831 The SAML assertion MAY contain an element. If 832 so, the element will contain attribute-value 833 pairs, e.g., of a user profile nature, encoded according to either 834 one of the "SAML Attribute Profiles" as specified in 835 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 836 and/or deployment-specific attribute profile. 838 The attribute-value pairs SHOULD in fact pertain to the entity 839 identified in the SIP From header field, since a SAML assertion 840 formulated per this overall section is stating that they do. 842 6.1.5. Assertion Verification 844 This section specifies the steps that a verifier participating in 845 this profile MUST perform in addition to the "Verifier Behavior" 846 specified in Section 6 of [RFC4474]. 848 The steps are: 850 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 851 extract the AS's domain certificate from the XML element at the end of the element path 853 given in Section 6.1.4.1.1. 855 2. Perform Step 1 in Section 6 of [RFC4474]. 857 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 858 that section, the verifier MUST verify the SAML assertion's 859 signature via the procedures specified in Section 5.4 of 860 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 862 @@ TODO: do we need to define a new SIP error response code for 863 when a SAML assn signature is bad? e.g., '4xx Invalid SAML 864 asssertion'. 866 4. Perform Step 2 in Section 6 of [RFC4474]. 868 5. Verify that the signer of the SIP message's Identity header 869 field is the same as the signer of the SAML assertion. 871 6. Perform Steps 3 and 4 in Section 6 of [RFC4474]. 873 7. Verify that the SAML assertion's element value matches 874 the Issuer or the Issuer Alternative Name fields [RFC3280] in 875 the AS's domain certificate. 877 8. Verify that the SAML assertion's element value is the 878 same as the Address of Record (AoR) value in the "signed- 879 identity-digest". See Section 9 of [RFC4474]. 881 9. Verify that the SAML assertion's element 882 value is set to whichever value was configured at 883 implementation- or deployment-time. The default value is: 885 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 887 10. Verify that the SAML assertion contains an element, 888 and that its value matches the value of the addr-spec of the SIP 889 To header field. 891 11. Verify that the validity period denoted by the NotBefore and 892 NotOnOrAfter attributes of the element meets the 893 requirements given in Section 6.1.4.1.3. 895 7. SAML SIP Binding 897 This section specifies one SAML SIP Binding at this time. Additional 898 bindings may be specified in future revisions of this specification. 900 7.1. SAML HTTP-URI-based SIP Binding 902 This section specifies the "SAML HTTP-URI-based SIP Binding", 903 (SHUSB). 905 The SHUSB is a profile of the "SAML URI Binding" specified in Section 906 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 907 a means by which SAML assertions can be referenced by URIs and thus 908 be obtained through resolution of such URIs. 910 This profile of the SAML URI Binding is congruent with the SAML URI 911 Binding -- including support for HTTP-based URIs being mandatory to 912 implement -- except for the following further restrictions which are 913 specified in the interest of interoperability (section numbers refer 914 to [OASIS.saml-bindings-2.0-os]): 916 Section 3.7.5.3 Security Considerations: 918 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 920 Section 3.7.5.4 Error Reporting: 922 All SHOULDs in this section are to be interpreted as MUSTs. 924 8. Example SAML Assertions 926 This section presents two examples of a SAML assertion, one unsigned 927 (for clarity), the other signed (for accuracy). 929 In the first example, Figure 5, the assertion is attesting with 930 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 931 The validity conditions are expressed in lines 16-23, via both a 932 validity period expressed as temporal endpoints, and an "audience 933 restriction" stating that this assertion's semantics are valid for 934 only the relying party named "example2.com". Also, the assertion's 935 issuer is noted in lines 4-5. 937 The above items correspond to some aspects of this specification's 938 SAML assertion profile, as noted below in Security Considerations 939 dicussions, see: Section 9.1 and Section 9.2. 941 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 942 fashion, using LDAP/X.500 schema as the typing means. 944 1 947 4 948 5 example.com 949 6 950 7 951 8 954 11 Alice@example.com 955 12 956 13 958 15 959 16 961 18 962 19 963 20 example2.com 964 21 965 22 966 23 967 24 968 25 975 32 976 33 +1-888-555-1212 977 34 978 35 979 36 980 37 982 Figure 5: Unsigned SAML Assertion Illustrating Conveyance of 983 Subject Attribute 985 In the second example, Figure 6, the information described above is 986 the same, the addition is that this version of the assertion is 987 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 989 integrity are assured. Since this assertion is the same as the one 990 in the first example above, other than having a signature added, the 991 second example below addresses the same Security Considerations 992 aspects, plus those requiring a Signature. 994 1 997 4 998 5 example.com 999 6 1000 7 1001 8 1002 9 1004 11 1006 13 1008 15 1009 16 1012 19 1015 22 1019 26 1020 27 1021 28 1023 30 1024 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1025 32 1026 33 1027 34 1028 35 1029 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1030 37 1031 38 1032 39 1033 40 1034 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1035 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1036 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1037 44 1038 45 1039 46 1040 47 1041 48 1042 49 1045 52 Alice@example.com 1046 53 1047 54 1049 56 1050 57 1052 59 1053 60 1054 61 example2.com 1055 62 1056 63 1057 64 1058 65 1059 66 1066 73 1067 74 +1-888-555-1212 1068 75 1069 76 1070 77 1071 78 1073 Figure 6: Signed SAML Assertion Illustrating Conveyance of Subject 1074 Attribute 1076 9. Security Considerations 1078 This section discusses security considerations when using SAML with 1079 SIP. 1081 9.1. Man-in-the-middle Attacks and Stolen Assertions 1083 Threat: 1085 By making SAML assertions available via HTTP-based requests by a 1086 potentially unbounded set of requesters, it is conceivably 1087 possible that anyone would be able to simply request one and 1088 obtain it. By SIP intermediaries on the signaling path for 1089 example. Or, an HTTP intermediary/proxy could intercept the 1090 assertion as it is being returned to a requester. 1092 The attacker could then conceivably attempt to impersonate the 1093 subject (the putative caller) to some SIP-based target entity. 1095 Countermeasures: 1097 Such an attack is implausible for several reasons. The primary 1098 reason is that a message constructed by an imposter using a stolen 1099 assertion that conveys the public key certificate of some domain 1100 will not verify per [RFC4474] because the imposter will not have 1101 the corresponding private key with which to generate the signed 1102 Identity header value. 1104 Also, the SIP SAML assertion profile specified herein that the 1105 subject's SAML assertion must adhere to causes it to be not useful 1106 to arbitrary parties. The subject's assertion: 1108 * should be signed, thus causing any alterations to break its 1109 integrity and make such alterations detectable. 1111 * does not contain an authentication statement. Thus no parties 1112 implementing this specification should be relying on SAML 1113 assertions specified herein as sufficient in and of themselves 1114 to allow access to resources. 1116 * relying party is represented in the SAML assertion's Audience 1117 Restriction. 1119 * Issuer is represented in the SAML assertion. 1121 * validity period for assertion is restricted. 1123 * etc. 1125 9.2. Forged Assertion 1127 Threat: 1129 A malicious user could forge or alter a SAML assertion in order to 1130 communicate with the SIP entities. 1132 Countermeasures: 1134 To avoid this kind of attack, the entities must assure that proper 1135 mechanisms for protecting the SAML assertion are employed, e.g., 1136 signing the SAML assertion itself. Section 5.1 of 1137 [OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. 1139 Additionally, the assertion content dictated by the SAML assertion 1140 profile herein ensures ample evidence for a relying party to 1141 verify the assertion and its relationship with the received SIP 1142 request. 1144 9.3. Replay Attack 1146 Threat: 1148 Theft of SIP message protected by the mechanisms described herein 1149 and replay of it at a later time. 1151 Countermeasures: 1153 There are various provisions within [RFC4474] that prevent a 1154 replay attack. 1156 10. Contributors 1158 The authors would like to thank Marcus Tegnander and Henning 1159 Schulzrinne for his contributions to earlier versions of this 1160 document. 1162 11. Acknowledgments 1164 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1165 Schubert, Jason Fischl and Vijay Gurbani for their comments to this 1166 draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 1167 Profile" is based on an idea by Jon Peterson. 1169 12. IANA Considerations 1171 [Editor's Note: A future version of this document will provide IANA 1172 considerations.] 1174 13. Open Issues 1176 A list of open issues can be found at: 1177 http://www.tschofenig.com:8080/saml-sip/ 1179 14. References 1181 14.1. Normative References 1183 [OASIS.saml-bindings-2.0-os] 1184 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1185 Maler, "Bindings for the OASIS Security Assertion Markup 1186 Language (SAML) V2.0", OASIS 1187 Standard saml-bindings-2.0-os, March 2005. 1189 [OASIS.saml-core-2.0-os] 1190 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1191 "Assertions and Protocol for the OASIS Security Assertion 1192 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1193 2.0-os, March 2005. 1195 [OASIS.saml-metadata-2.0-os] 1196 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1197 "Metadata for the Security Assertion Markup Language 1198 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1199 March 2005. 1201 [OASIS.saml-profiles-2.0-os] 1202 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1203 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1204 Security Assertion Markup Language (SAML) V2.0", OASIS 1205 Standard OASIS.saml-profiles-2.0-os, March 2005. 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, March 1997. 1210 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1211 Locators", RFC 2392, August 1998. 1213 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1214 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1215 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1217 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1218 A., Peterson, J., Sparks, R., Handley, M., and E. 1219 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1220 June 2002. 1222 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1223 X.509 Public Key Infrastructure Certificate and 1224 Certificate Revocation List (CRL) Profile", RFC 3280, 1225 April 2002. 1227 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1228 Method", RFC 3515, April 2003. 1230 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1231 IETF URN Sub-namespace for Registered Protocol 1232 Parameters", BCP 73, RFC 3553, June 2003. 1234 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1235 Authenticated Identity Body (AIB) Format", RFC 3893, 1236 September 2004. 1238 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1239 Authenticated Identity Management in the Session 1240 Initiation Protocol (SIP)", RFC 4474, August 2006. 1242 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1243 "Trait-Based Authorization Requirements for the Session 1244 Initiation Protocol (SIP)", RFC 4484, August 2006. 1246 [W3C.xmldsig-core] 1247 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1248 Syntax and Processing", W3C Recommendation xmldsig-core, 1249 October 2000, . 1251 14.2. Informative References 1253 [I-D.ietf-sip-content-indirect-mech] 1254 Burger, E., "A Mechanism for Content Indirection in 1255 Session Initiation Protocol (SIP) Messages", 1256 draft-ietf-sip-content-indirect-mech-05 (work in 1257 progress), October 2004. 1259 [I-D.ietf-sipping-certs] 1260 Jennings, C. and J. Peterson, "Certificate Management 1261 Service for The Session Initiation Protocol (SIP)", 1262 draft-ietf-sipping-certs-03 (work in progress), 1263 March 2006. 1265 [I-D.jennings-sipping-pay] 1266 Jennings, C., "Payment for Services in Session Initiation 1267 Protocol (SIP)", draft-jennings-sipping-pay-05 (work in 1268 progress), October 2006. 1270 [I-D.peterson-message-identity] 1271 Peterson, J., "Security Considerations for Impersonation 1272 and Identity in Messaging Systems", 1273 draft-peterson-message-identity-00 (work in progress), 1274 October 2004. 1276 [IANA.application.samlassertion-xml] 1277 OASIS Security Services Technical Committee (SSTC), 1278 "application/samlassertion+xml MIME Media Type 1279 Registration", IANA MIME Media Types Registry application/ 1280 samlassertion+xml, December 2004. 1282 [OASIS.saml-conformance-2.0-os] 1283 Mishra, P., Philpott, R., and E. Maler, "Conformance 1284 Requirements for the Security Assertion Markup Language 1285 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1286 March 2005. 1288 [OASIS.saml-glossary-2.0-os] 1289 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1290 Security Assertion Markup Language (SAML) V2.0", OASIS 1291 Standard saml-glossary-2.0-os, March 2005. 1293 [OASIS.saml-sec-consider-2.0-os] 1294 Hirsch, F., Philpott, R., and E. Maler, "Security and 1295 Privacy Considerations for the OASIS Security Markup 1296 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1297 2.0-os, March 2005. 1299 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1300 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1301 OASIS SSTC Committee 1302 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1304 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1305 Cantor, S., "SAML Protocol Extension for Third-Party 1306 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1307 ext-thirdparty-cd-01, March 2006. 1309 [OASIS.sstc-saml-tech-overview-2.0-draft-08] 1310 Hughes, J. and E. Maler, "Security Assertion Markup 1311 Language (SAML) V2.0 Technical Overview", OASIS SSTC 1312 Working Draft sstc-saml-tech-overview-2.0-draft-08, 1313 September 2005. 1315 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1316 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1317 March 1999. 1319 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1320 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1321 September 1999. 1323 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1324 Certificate Profile for Authorization", RFC 3281, 1325 April 2002. 1327 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1328 Initiation Protocol (SIP)", RFC 3323, November 2002. 1330 Appendix A. Appendix: Use-case Scenarios 1332 This Appendix explores message flows based on various use-case 1333 scenarios in [RFC4484], and from various discussions, to which SAML- 1334 based solutions are applied. Appendix A.2 shows a SIP conferencing 1335 scenario with role-based access control using SAML. 1337 Note that we present these scenarios as illustrations of possible 1338 SAML-based use cases in SIP. This document does not provide a 1339 detailed exposition of these scenarios -- that is left for addtional 1340 documents. 1342 A.1. PSTN-to-SIP Phone Call 1344 Alice, using a phone connected to the PSTN, wants to make a call to 1345 Bob, who resides in a SIP network. Her call is switched through the 1346 PSTN by means of PSTN signaling (outside the scope of this document) 1347 to the PSTN/SIP gateway. At the gateway, the call is converted from 1348 SS7 signaling to SIP signaling. Since Alice's PSTN phone was 1349 previously "authenticated" via PSTN signaling mechanisms, the gateway 1350 is able to assert her phone's identity (e.g., her telephone number) 1351 via SIP Identity and SAML-based mechanisms (e.g., in order to convey 1352 profile attributes) to Bob's SIP proxy, which also dereferences the 1353 URI in the Identity-Info header in order to obtain the SAML assertion 1354 and the PSTN/SIP Gateway's domain certificate. Alice's INVITE is 1355 then forwarded from the SIP/PSTN gateway to Bob's phone, and is 1356 secured via whatever means is locally established in Bob's 1357 administrative domain. 1359 +-----------+ 1360 +----------------------+ | | 1361 | | SS7 | PSTN/SIP | 1362 | Public Switched |--------------------->| Gateway | 1363 | | | | 1364 | | | | 1365 | Telephone Network | +--+-----------+------+ 1366 | ^ | | | ^ V | 1367 +---------+------------+ | | ^ V SIP-Ident | 1368 | SS7 | v ^ V +SAML | 1369 | | +--------+ | 1370 O | | Bob's | | 1371 O /|\ <----+----| SIP | | 1372 /|\ / \ SIP | | Proxy | | 1373 / \ Bob | | | | 1374 Alice | +--------+ | 1375 | SIP based | 1376 | Network | 1377 +---------------------+ 1379 Figure 7: PSTN to SIP call 1381 Note that the INVITE emitted by the PSTN/SIP gateway could 1382 alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone, 1383 and Bob's phone could take on the SIP Identity "verifier" role, which 1384 is being played by Bob's SIP proxy in the figure. 1386 Whichever approach is employed is a decision local to Bob's 1387 administrative domain and can be made independently. 1389 A.2. SIP Conferencing 1391 This section is meant to foster discussion about the usage of SAML in 1392 the domain of conferencing. A user agent who routes its SIP message 1393 through the Authentication Service (Asserting Party) towards a 1394 conferencing server may want or need various of her profile 1395 attributes included and may also need to be authenticated by the 1396 conference server. The following properties could be provided by 1397 this procedure: 1399 o The user identity can be replaced to allow the user to be 1400 anonymous with regard to the Focus. This can be accomplished via 1401 [RFC3323] in combination with [RFC4474], per the latter, or, 1403 o The user identity could be asserted to the Focus, via [RFC4474] 1404 mechanisms, and/or, 1406 o the SAML assertion could provide additional user profile 1407 information such as group membership (belongs to the students, 1408 staff, faculty group of university X). This could, for non- 1409 identity-based authorization systems, imply certain rights. 1411 The corresponding SIP message flow (in high level detail) could have 1412 the following shape: 1414 +-----+ +-----------+ +-----------+ 1415 | | | SIP Proxy | | Focus | 1416 |User | |(Asserting | | (Relying | 1417 | | | party) | | party) | 1418 +--+--+ +-----+-----+ +-----+-----+ 1419 | INVITE | | 1420 |sip:conf-factory | INVITE | 1421 |------------------>| w/Identity hdr | 1422 | |------------------>| 1423 | | | 1424 | | HTTP GET SAML assn| 1425 | |<==================| 1426 | | and domain cert | 1427 | | | 1428 | | HTTP 200 OK + assn| 1429 | |==================>| 1430 | | and domain cert | 1431 | | | 1432 | | | 1433 | | Ringing | 1434 | Ringing |<------------------| 1435 |<------------------| | 1436 | | | 1437 | | OK | 1438 | OK |<------------------| 1439 |<------------------| | 1440 | | | 1441 | ACK | | 1442 |------------------>| ACK | 1443 | |------------------>| 1444 | | | 1445 | | | 1446 ... many more msgs... 1448 Figure 8: SIP Conferencing and SAML 1450 However, there are obvious scaling issues with the conference server 1451 having to do the outbound requests in order to obtain SAML assertions 1452 and certificates for conference participants. 1454 This could be addressed by creating another SIP SAML Profile where 1455 the caller obtains the necessary information, e.g., SAML assertions, 1456 and places them into its SIP request message prior to sending it. 1457 This would obviate the need for the callee relying party to make 1458 requests in order to obtain said information. This is a topic for 1459 future work, and possibly future revisions of this specification. 1461 A.3. Compensation using SIP and SAML 1463 This section describes a scenario where SAML is used in SIP to 1464 realize compensation functionality as described in 1465 [I-D.jennings-sipping-pay]. 1467 Note that this scenario is not directly addressed by the SIP SAML 1468 Profile and SAML SIP Binding presently defined in this specification. 1469 Rather, this use case calls for additional such profiles and bindings 1470 to be developed. 1472 +--------+ +--------+ +--------+ 1473 |Payment | | User | |Merchant| 1474 |Provider| | Alice | |Bob | 1475 | | | | | | 1476 | | | | | | 1477 +---+----+ +---+----+ +---+----+ 1478 | | | 1479 | | 1) Call | 1480 | |------------------------>| 1481 | | | 1482 | | 2) 402 + Payment Offer | 1483 | 3) Request for |<------------------------| 1484 | a Payment | | 1485 |<----------------------| | 1486 | | | 1487 | 4) SAML Assertion | | 1488 | (=Receipt) | | 1489 |---------------------->| | 1490 | | 5) Call + Receipt | 1491 | |------------------------>| 1492 | | | 1493 | | 6) 200 OK | 1494 | |<------------------------| 1495 | | | 1496 Figure 9: Message flow for SIP payment 1498 User Alice and the Merchant Bob interact with each other using SIP 1499 and the Alice uses HTTP to exchange messages with a Payment Provider. 1500 Initially, Alice makes a call to Bob (1). Bob determines that a 1501 payment is required and includes information about the payment in an 1502 Offer body of a 402 (Payment Required) response to Alice (2). Alice 1503 looks at this Offer and decides to make a payment. Alice therefore 1504 instructs her Payment Provider to make a transfer from Alice"s 1505 account to the Merchants"s account (3) using a request for a SAML 1506 assertion with the extensions defined in this document. The Payment 1507 Provider returns a receipt for this transfer (4). This receipt is a 1508 SAML Assertion. Alice resubmits the call to Bob but this time 1509 provides the Receipt for the transaction (5). Bob determines whether 1510 the Receipt is valid (by checking the digital signature and the 1511 content of the assertion) and continues with the call processing, if 1512 the authorization was succesful. 1514 The Offer contains information about the participating parties (i.e., 1515 the Payment Provider, the Merchant Bob, and the user Alice), the 1516 transaction amount, the account identifier for Bob at the Payment 1517 Provider, and a replay protection indicator to make it easier for the 1518 Merchant Bob to avoid replay attacks. User Alice includes this 1519 information when making the Request for Payment to the Payment 1520 Provider; adds its own account information and authorization 1521 password; and sends this to the Payment Provider, which produces a 1522 Receipt for the transaction if it is successful. This transfer from 1523 Alice to the Payment Provider is made across an encrypted, integrity 1524 protected channel. The Receipt includes a timestamp when the Payment 1525 Provider made the transaction and protects the Receipt with a digital 1526 signature. Alice resubmits the call to the Merchant Bob with the 1527 Receipt from the Payment Provier. Merchant Bob can check for replay 1528 attacks using the timestamp and a replay protection indiciator 1529 initially provided with the Offer. Bob can then check the signature 1530 is valid using the Payment Provider"s public key. 1532 Authors' Addresses 1534 Hannes Tschofenig 1535 Nokia Siemens Networks 1536 Otto-Hahn-Ring 6 1537 Munich, Bavaria 81739 1538 Germany 1540 Email: Hannes.Tschofenig@siemens.com 1542 Jeff Hodges 1543 NeuStar, Inc. 1544 2000 Broadway Street 1545 Redwood City, CA 94063 1546 US 1548 Email: Jeff.Hodges@neustar.biz 1550 Jon Peterson 1551 NeuStar, Inc. 1552 1800 Sutter St Suite 570 1553 Concord, CA 94520 1554 US 1556 Email: jon.peterson@neustar.biz 1558 James Polk 1559 Cisco 1560 2200 East President George Bush Turnpike 1561 Richardson, Texas 75082 1562 US 1564 Email: jmpolk@cisco.com 1566 Douglas C. Sicker 1567 University of Colorado at Boulder 1568 ECOT 430 1569 Boulder, CO 80309 1570 US 1572 Email: douglas.sicker@colorado.edu 1574 Full Copyright Statement 1576 Copyright (C) The IETF Trust (2007). 1578 This document is subject to the rights, licenses and restrictions 1579 contained in BCP 78, and except as set forth therein, the authors 1580 retain all their rights. 1582 This document and the information contained herein are provided on an 1583 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1584 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1585 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1586 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1587 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1588 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1590 Intellectual Property 1592 The IETF takes no position regarding the validity or scope of any 1593 Intellectual Property Rights or other rights that might be claimed to 1594 pertain to the implementation or use of the technology described in 1595 this document or the extent to which any license under such rights 1596 might or might not be available; nor does it represent that it has 1597 made any independent effort to identify any such rights. Information 1598 on the procedures with respect to rights in RFC documents can be 1599 found in BCP 78 and BCP 79. 1601 Copies of IPR disclosures made to the IETF Secretariat and any 1602 assurances of licenses to be made available, or the result of an 1603 attempt made to obtain a general license or permission for the use of 1604 such proprietary rights by implementers or users of this 1605 specification can be obtained from the IETF on-line IPR repository at 1606 http://www.ietf.org/ipr. 1608 The IETF invites any interested party to bring to its attention any 1609 copyrights, patents or patent applications, or other proprietary 1610 rights that may cover technology that may be required to implement 1611 this standard. Please address the information to the IETF at 1612 ietf-ipr@ietf.org. 1614 Acknowledgment 1616 Funding for the RFC Editor function is provided by the IETF 1617 Administrative Support Activity (IASA).