idnits 2.17.00 (12 Aug 2021) /tmp/idnits29726/draft-ietf-sip-saml-00.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 on line 1618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1608. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 241 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 (June 16, 2006) is 5818 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 1227, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1244, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-content-indirect-mech' is defined on line 1262, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-certs' is defined on line 1268, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-pay' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-message-identity' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1324, but no explicit reference was found in the text == Outdated reference: draft-ietf-sip-identity has been published as RFC 4474 == Outdated reference: draft-ietf-sipping-trait-authz has been published as RFC 4484 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-trait-authz (ref. 'I-D.ietf-sipping-trait-authz') ** 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) == 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-03 -- 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: 6 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP H. Tschofenig 3 Internet-Draft Siemens 4 Expires: December 18, 2006 J. Hodges 5 J. Peterson 6 NeuStar, Inc. 7 J. Polk 8 Cisco 9 D. Sicker 10 CU Boulder 11 June 16, 2006 13 SIP SAML Profile and Binding 14 draft-ietf-sip-saml-00.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 December 18, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . 23 71 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 25 72 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 25 73 8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 26 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 75 9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 31 76 9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 32 77 9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 32 78 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 81 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 83 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 84 14.2. Informative References . . . . . . . . . . . . . . . . . . 38 85 Appendix A. Appendix: Use-case Scenarios . . . . . . . . . . . . 41 86 A.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 41 87 A.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 42 88 A.3. Compensation using SIP and SAML . . . . . . . . . . . . . 44 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 90 Intellectual Property and Copyright Statements . . . . . . . . . . 47 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 [I-D.ietf-sipping-trait- 101 authz]. 103 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 104 based framework for creating and exchanging security information. 105 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-tech- 106 overview-2.0-draft-08] provide non-normative overviews of SAMLv2. 107 The SAMLv2 specification set is normatively defined by [OASIS.saml- 108 conformance-2.0-os]. 110 Various means of providing trait-based authorization exist: 111 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 112 to the authenticated identity body [RFC3893]. The authors selected 113 SAML due to its increasing use in environments such as the Liberty 114 Alliance, and the Internet2 project, areas where the applicability to 115 SIP is widely desired. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 The SIP network element "Authentication Service" is introduced in 124 [I-D.ietf-sip-identity]. We reuse this term to refer to a network 125 element that authenticates and authorizes a user and creates a "SIP 126 identity assertion". This system entity is the logical equivalent of 127 a "SAML Authority" in the SAML terminology. 129 For overall SIP terminology, see [RFC3261]. 131 In this specification, the term, or term component, "SAML" refers to 132 SAML V2.0 in all cases. For example, the term "SAML assertion" 133 implicitly means "SAMLv2 assertion". For overall SAML terminology, 134 see [OASIS.saml-glossary-2.0-os]. 136 The below list maps other various SIP terms to their SAML 137 (rough-)equivalents: 139 Element, Network Element: 141 System Entity, Entity 143 Authentication Service: 145 SAML Authority 147 Invitee, Invited User, Called Party, Callee: 149 Relying Party 151 Server, User Agent Server (UAS): 153 SAML Responder 155 User Agent Client (UAC), client: 157 SAML Requester 159 Additional terms defined in the context of this specification: 161 profile attribute(s): 163 one or more attributes of a "user profile". 165 user profile, subject profile: 167 the set of various attributes accompanying (i.e., mapped to) a 168 user account in many environments. 170 3. SAML Introduction 172 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] [OASIS.sstc-saml-tech- 173 overview-2.0-draft-08] defines an XML-based framework for exchanging 174 "security assertions" between entities. In the course of making, or 175 relying upon such assertions, SAML system entities may use SAML 176 protocols, or other protocols, to communicate an assertion itself, or 177 the subject of an assertion. 179 Thus one can employ SAML to make and encode statements such as "Alice 180 has these profile attributes and her domain's certificate is 181 available over there, and I'm making this statement, and here's who I 182 am." Then one can cause such an assertion to be conveyed to some 183 party who can then rely on it in some fashion for some purpose, for 184 example input it into some local policy evaluation for access to some 185 resource. This is done in a particular "context of use". Such a 186 context of use could be, for example, deciding whether to accept and 187 act upon a SIP-based invitation to initiate a communication session. 189 The specification of how SAML is employed in a particular context of 190 use is known as a "SAML profile". The specification of how SAML 191 assertions and/or protocol messages are conveyed in, or over, another 192 protocol is known as a "SAML Binding". Typically, a SAML profile 193 specifies the SAML bindings that may be used in its context. Both 194 SAML profiles and SAML bindings reference other SAML specifications, 195 especially the SAML Assertions and Protocols, aka "SAML Core", 196 specification [OASIS.saml-core-2.0-os]. 198 There is an additional subtle aspect of SAML profiles that is worth 199 highlighting -- the notion of a "SAML assertion profile". A SAML 200 assertion profile is the specification of the assertion contents in 201 the context of a particular SAML profile. It is possibly further 202 qualified by a particular implementation and/or deployment context. 203 Condensed examples of SAML assertion profiles are: 205 o The SAML assertion must contain at least one authentication 206 statement and no other statements. The relying party must be 207 represented in the element. The 208 SubjectConfirmation Method must be Foo. etc. 210 o The SAML assertion must contain at least one attribute statement 211 and may contain more than one. The values for the subject's 212 profile attributes named "Foo" and "Bar" must be present. An 213 authentication statement may be present. etc. 215 The primary facets of SAML itself are: 217 o Assertions 219 o Abstract Request/Response protocol 221 We describe each in turn below: 223 3.1. SAML Assertions 225 A SAML assertion is a package of information including issuer and 226 subject, conditions and advice, and/or attribute statements, and/or 227 authentication statements and/or other statements. Statements may or 228 may not be present. The SAML assertion "container" itself contains 229 the following information: 231 Issuing information: 233 Who issued the assertion, when was it issued and the assertion 234 identifier. 236 Subject information: 238 The name of the subject, the security domain and optional subject 239 information, like public key. 241 Conditions under which the assertion is valid: 243 Special kind of conditions like assertion validity period, 244 audience restriction and target restriction. 246 Additional advice: 248 Explaining how the assertion was made, for example. 250 In terms of SAML assertions containing SAML attribute statements or 251 SAML authentication statements, here are explanatory examples: 253 With a SAML assertion containing a SAML attribute statement, an 254 issuing authority is asserting that the subject is associated with 255 certain attributes with certain subject profile attribute values. 256 For example, user jon@cs.example.com is associated with the 257 attribute "Department", which has the value "Computer Science". 259 With a SAML assertion containing a SAML authentication statement, 260 an issuing authority is asserting that the subject was 261 authenticated by certain means at a certain time. 263 With a SAML assertion containing both a SAML attribute statement 264 and a SAML authentication statement, an issuing authority is 265 asserting the union of the above. 267 3.2. Abstract Request/Response Protocol 269 SAML defines an abstract request/response protocol for obtaining 270 assertions. See Section 3 "SAML Protocols" of 271 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 272 response returns the requested assertion or an error. This abstract 273 protocol may then be cast into particular contexts of use by binding 274 it to specific underlying protocols, e.g., HTTP or SIP, and 275 "profiling" it for the specific use case at hand. The SAML HTTP- 276 based web single sign-on profile is one such example (see Section 4.1 277 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 278 based SIP communication session establishment, the topic of this 279 specification, is another. 281 4. Specification Scope 283 The scope of this specification is: 285 o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such 286 that a subject's profile attributes, and their domain's 287 certificate, can be conveyed to a relying party using SAML. In 288 doing so, satisfy the requirements outlined in [I-D.ietf-sipping- 289 trait-authz], and compose with [I-D.ietf-sip-identity]. 291 The following are outside the scope of this specification: 293 o Defining a means for configuring the runtime behavior, or 294 deployment characteristics, of the Authentication Service. 296 Discussion: 298 For example, a SIP Authentication Service could be implemented 299 such that its SAML-based features are employed, or not, on a 300 subject-by-subject basis, and/or on a domain-by-domain basis. 302 o The definition of specific conveyed subject profile attributes 303 (aka traits). 305 Discussion: 307 This specification defines a facility enabling "trait-based 308 authorization" as discussed in [I-D.ietf-sipping-trait-authz]. 310 The attributes of interest in trait-based authorization will be 311 ones akin to, for example: roles, organizational membership, 312 access rights, or authentication event context. Definition of 313 such attributes is application- and/or deployment-context- 314 dependent and are not defined in this specification. However, The 315 SAMLv2 specification defines several "SAML Attribute Profiles" for 316 encoding attributes from various application domains, e.g., LDAP, 317 UUID/GUID, DCE PAC, and XACML, in SAML assertions [OASIS.saml- 318 profiles-2.0-os]. 320 In order for any trait-based system to be practical, participating 321 entities must agree on attributes and traits that will be conveyed 322 and subsequently relied upon. Without such agreements, a trait- 323 based system cannot be usefully deployed. This specification does 324 not discuss the manner in which participating entites might 325 discover one another or agree on the syntax and semantics of 326 attributes and traits. 328 Note that SAMLv2 specifies a "metadata" facility that may be 329 useful in addressing this need. 331 5. Employing SAML in SIP 333 Employing SAML in SIP necessitates devising a new SAML profile(s) and 334 binding(s) because the those already specified in the SAMLv2 335 specification set are specific to other use contexts, e.g., HTTP- 336 based web browsing. Although SIP bears some similarity to HTTP, it 337 is a seperately distinct protocol, thus requiring specification of 338 SIP-specific SAML profile(s) and binding(s). This is technically 339 straigh-forward as both SAML and SIP are explicitly extensible. 341 The "Authenticated Identity Management in SIP" specification 342 [I-D.ietf-sip-identity] (aka "SIP Identity") facilitates the 343 composition of SAML and SIP in that it defines a "mediated 344 authentication architecture" where verifying endpoints verify SIP 345 identity assertions -- i.e., the "Identity" header value -- signed by 346 an Authentication Service (AS). The semantic being that the AS is 347 vouching that it did indeed authenticate the calling party. 349 Such an Authentication Service, which likely has access to various 350 pieces of information concerning the calling party, could also act as 351 a SAML Authority, and make such information available to the callee 352 via SAML. 354 Since [I-D.ietf-sip-identity] stipulates that the AS must make its 355 certificate available for retrieval and convey the availability and 356 access mechanism via a URI, in the Identity-Info header, we have an 357 opportunity to compose SIP Identity and SAML. 359 Such composition can be accomplished by having the resource referred 360 to by the URI in the Identity-Info be a SAML assertion conveying both 361 the AS's certificate and user profile attributes. This is the 362 approach defined in this specification. Figure 1 illustrates this 363 approach in a high-level summary fashion. Figure 2, further below, 364 illustrates additional details. 366 +--------+ +--------------+ +--------+ 367 |Alice@ | |Authentication| | Bob@ | 368 |example | |Service | |example2| 369 |.com | |@example.com | |.com | 370 | | | | | | 371 +---+----+ +------+-------+ +---+----+ 372 | | | 373 | INVITE | | 374 |---------------------->| | 375 | From:alice@foo.com | | 376 | | | 377 | 407 Proxy auth. req. | | 378 |<----------------------| | 379 | Challenge | | 380 | | | 381 | ACK | | 382 |---------------------->| | 383 | | | 384 | INVITE w/authn creds | | 385 |---------------------->| | 386 | | INVITE | 387 | | w/Identity header | 388 | |--------------------->| 389 | | and Identity-Info | 390 | | | 391 | | HTTP GET SAML assn | 392 | |<==================== | 393 | | and domain cert | 394 | | | 395 | | HTTP 200 OK + assn | 396 | |=====================>| 397 | | and domain cert | 398 | 200 OK | | 399 |<----------------------+----------------------| 400 | | | 402 Figure 1: SIP-SAML-based Network Asserted Identity 404 Since the AS already being trusted to create and add the Identity 405 header containing the SIP Identity Assertion, and to supply a pointer 406 to its domain certificate, having it point instead to a SAML 407 assertion conveying the domain certificate and possibly some user 408 profile attributes, does not significantly alter the first-order 409 security considerations examined in [I-D.ietf-sip-identity]. This 410 specification provides some additional security considerations 411 analysis below in Section 9. 413 6. SIP SAML Profiles 415 This section defines one SIP SAML profile: 417 The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 418 Profile" 420 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 422 6.1.1. Required Information 424 The information given in this section is similar to the info provided 425 when registering something, a MIME Media Type, say, with IANA. In 426 this case, it is for registering this profile with the OASIS SSTC. 427 See Section 2 "Specification of Additional Profiles" in [OASIS.saml- 428 profiles-2.0-os]. 430 Identification: 432 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 434 @@ NOTE: This URN must be agreed upon, and then registered with 435 IANA per [RFC3553]. 437 Contact Information: 439 @@ someone's or something's contact info goes here 441 SAML Confirmation Method Identifiers: 443 The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is 444 used in this profile. 446 Description: 448 Given below. 450 Updates: 452 None. 454 6.1.2. Profile Overview 456 Figure 2 illustrates this profile's overall protocol flow. The 457 following steps correspond to the labeled interactions in the figure. 458 Within an individual step, there may be one or more actual message 459 exchanges depending upon the protocol binding employed for that 460 particular step and other implementation-dependent behavior. 462 Although this profile is overview is cast in terms of a SIP INVITE 463 transaction, the reader should note that the mechanism specified 464 herein, and in [I-D.ietf-sip-identity], may be applied to any SIP 465 request message. 467 Figure 2 begins on the next page. 469 +------------------+ +------------------+ +-----------------+ 470 | Caller | |Authn Service (AS)| | Callee | 471 |Alice@example.com | | @example.com | | Bob@example2.com| 472 +--------+---------+ +--------+---------+ +--------+--------+ 473 - - | | | (steps) 474 ^ ^ | INVITE | | 475 | | |---------------------->| | (1a) 476 | | From:alice@foo.com | | 477 | C | To:sip:bob@example.com| | 478 | S | | | 479 | e | 407 Proxy auth. req. | | 480 | q |<----------------------| | (1b) 481 | = | Challenge | | 482 | N | | | 483 | | ACK | | 484 | | |---------------------->| | (1c) 485 | V | | | 486 | - | | | 487 ^ | INVITE + authorization| | 488 D | | header w/ creds | | 489 | |---------------------->| | (2) 490 I | | From:alice@foo.com | | 491 | | To:sip:bob@example.com| | 492 A | Proxy-Authorization:..| | 493 C | | INVITE | 494 L S | |--------------------->| (3) 495 e | | From:alice@foo.com | 496 O q | | To:sip:bob@example2.com 497 | | Identity: ..... | 498 G = | | Identity-Info: | 499 | | https://example.com| 500 | N | | /assns/?ID=abcde | 501 | | | | 502 | + | |URI resolution (eg. HTTP) 503 | | |<=====================| (4) 504 | 1 | | GET /assns/?ID=abcde | 505 | | | | 506 | | | | HTTP/1.1 200 OK | 507 | | | |=====================>| (5) 508 | | | | | 509 | | | | | 510 | | | | | 511 | | | | Alice@example.com 512 | | | | 513 | | | | 514 | | | | ... 515 | | | | 516 | | | | foo=bar | 517 | | | 200 OK | | 518 | V |<----------------------+----------------------| (6) 519 . - | | | 520 V 522 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 523 Transaction 525 Step 1. Initial SIP Transaction between Caller and AS 527 This optional initial step is comprised of substeps 1a, 1b, 528 and 1c in Figure 2. In this step, the caller, Alice, sends a 529 SIP request message, illustrated as an INVITE, indicating Bob 530 as the callee (1a), is subsequently challenged by the AS 531 (1b), and sends an ACK in response to the challenge (1c). 532 The latter message signals the completion of this SIP 533 transaction (which is an optional substep of this profile). 535 Step 2. Caller sends SIP Request Message with Authorization 536 Credentials to the AS 538 Alice then sends an INVITE message in response to the 539 challenge, or uses cached credentials for the domain if step 540 1 was skipped, as specified in [I-D.ietf-sip-identity] and 541 [RFC3261]. Depending on the chosen SIP security mechanism 542 either digest authentication, S/MIME or Transport Layer 543 Security is used to provide the AS with a strong assurance 544 about the identity of Alice. 546 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 548 First, the AS authorizes the received INVITE message as 549 specified in [I-D.ietf-sip-identity] and [RFC3261]. If the 550 authorization is successful, the AS will form the "identity 551 signature" for the message and add Identity and Identity-Info 552 headers to the message. The AS also at this time constructs 553 and caches a SAML assertion asserting Alice's profile 554 attributes required by Bob's domain (example2.com), and also 555 containing a the domain's (example.com) public key 556 certificate, or a reference to it. This certificate MUST 557 contain the public key corresponding to the private key used 558 to construct the signature whose value was placed in the 559 Identity header. The AS constructs a HTTP-based SAML URI 560 Reference incorporating the assertion's Assertion ID (see 561 section 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this 562 URI as the value for the Identity-Info header it adds to the 563 INVITE message. 565 The AS determines which profile attributes (if any) to assert 566 in the via local configuration and/or 567 obtaining example2.com's metadata 568 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 569 INVITE message to Bob. 571 Step 4. Callee Dereferences HTTP-based SAML URI Reference 573 Bob's UAC or SIP Proxy receives the message and begins 574 verifying it per the "Verifier Behavior" specified in 575 [I-D.ietf-sip-identity]. In order to accomplish this task, 576 it needs to obtain Alice's domain certificate. It obtains 577 the HTTP-based SAML URI Reference from the message's 578 Identity-Info header and dereferences it per Section 7.1. 579 Note that this is not a SIP message, but an HTTP message 580 [RFC2616]. 582 Step 5. AS Returns SAML Assertion 584 Upon receipt of the above HTTP request, which contains an 585 embedded reference to Alice's SAML Assertion, Alice's AS 586 returns her assertion in an HTTP response message. 588 Upon receipt of Alice's SAML Assertion, the AS continues its 589 verification of the INVITE message. If successful, it 590 returns a 200 OK message directly to Alice. Otherwise it 591 returns an appropriate SIP error response. 593 Step 6. Callee Returns SIP 200 OK to Caller 595 If Bob determines, based upon Alice's identity as asserted by 596 the AS, and as further substantiated by the information in 597 the SAML assertion, to accept the INVITE, he returns a SIP 598 200 OK message directly to Alice. 600 6.1.3. Profile Description 602 The following sections provide detailed definitions of the individual 603 profile steps. The relevant illustration is Figure 3, below. Note 604 that this profile is agnostic to the specific SIP request, and also 605 that the Sender and Authentication Service (AS) may be seperate or 606 co-located in actuality. 608 +------------------+ +------------------+ +------------------+ 609 | Sender | |Authn Service (AS)| | Verifier | 610 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 611 +--------+---------+ +--------+---------+ +--------+---------+ 612 | | | (steps) 613 | SIP Request | | 614 |---------------------->| | (1a) 615 | | | 616 | 407 Proxy auth. req. | | 617 |<----------------------| | (1b) 618 | Challenge | | 619 | | | 620 | ACK | | 621 |---------------------->| | (1c) 622 | | | 623 | | | 624 |SIP Req + authorization| | 625 | header w/ creds | | 626 |---------------------->| | (2) 627 | | | 628 | | | 629 | | SIP Req + Ident & | 630 | | authz headers | 631 | |--------------------->| (3) 632 | | | 633 | | URI resolution | 634 | |<=====================| (4) 635 | | (via HTTP) | 636 | | | 637 | | HTTP/1.1 200 OK | 638 | |=====================>| (5) 639 | | | 640 | | | 641 | | ? | (6) 642 | | | 644 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 646 6.1.3.1. Initial SIP Transaction between Sender and AS 648 This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication 649 Service Behavior" of [I-D.ietf-sip-identity]. If the SIP request 650 sent by the caller in substep 1a is deemed insufficiently 651 authenticated by the AS per the rules stipulated by [I-D.ietf-sip- 652 identity] Steps 1 and 2, then the AS MUST authenticate the sender of 653 the message. The particulars of how this is accomplished depend upon 654 implementation and/or deployment instantiation as discussed in 656 [I-D.ietf-sip-identity]. Substeps 1b and 1c as shown in Figure 3 are 657 non-normative and illustrative only. 659 6.1.3.2. Sender sends SIP Request Message with Authorization 660 Credentials to the AS 662 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 663 Behavior" of [I-D.ietf-sip-identity]. This request is presumed to be 664 made in a context such that the AS will not challenge it -- i.e., the 665 AS will consider the sender of the message to be authenticated. If 666 this is not true, then this procedure reverts back to Step 1, above. 668 Otherwise, the AS carries out all other processing of the message as 669 stipulated in [I-D.ietf-sip-identity] Steps 1 and 2, and if 670 successful, this procedure procedes to the next step below. 672 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 674 This first portion of this step maps to Steps 3 and 4 of Section 5 675 "Authentication Service Behavior" of [I-D.ietf-sip-identity], which 676 the AS MUST perform, although with the following additional substeps: 678 The AS MUST construct a SAML assertion according to the "Assertion 679 Profile Description" specified in Section 6.1.4 of this 680 specification. 682 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 683 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 685 The AS MUST use the URI constructed in the immediately preceding 686 substep as the value of the Identity-Info header that is added to 687 the SIP request message per Step 4 of Section 5 of [I-D.ietf-sip- 688 identity]. 690 Upon successful completion of all of the above, the AS forwards the 691 request message. 693 At this point in this step, after perhaps traversing some number of 694 intermediaries, the SIP request message arrives at a SIP network 695 entity performing the "verifier" role. This role and its behavior 696 are specified in Section 6 "Verifier Behavior" of [I-D.ietf-sip- 697 identity]. The verifier MUST perform the steps enumerated in the 698 aforementioned section, with the following modifications: 700 Step 1 of [I-D.ietf-sip-identity] Section 6 maps to and is updated 701 by, the following two steps in this procedure. 703 Steps 2, 3, and 4 of [I-D.ietf-sip-identity] Section 6 may be 704 mapped across this latter portion of this step, and/or the 705 following two steps, as appropriate. 707 6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 709 The verifier SHOULD ascertain whether it has a current cached copy of 710 the SIP message sender's SAML assertion and domain certificate. If 711 not, or if the verifier chooses to (e.g., due to local policy), it 712 MUST dereference the the HTTP-based SAML URI Reference found in the 713 SIP message's Identity-Info header. To do so, the verifier MUST 714 employ the "SAML HTTP-URI-based SIP Binding" specified in 715 Section 7.1. 717 6.1.3.5. AS Returns SAML Assertion 719 This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 721 If the prior step returns an HTTP error (e.g., 4xx series), then this 722 procedure terminates and the verifier returns (upstream) a SIP 436 723 'Bad Identity-Info' Response code. 725 Otherwise, the HTTP response message will contain a SAML assertion 726 and be denoted as such via the MIME media type of "application/ 727 samlassertion+xml" [IANA.application.samlassertion-xml]. The 728 verifier MUST perform the verification steps specified in 729 Section 6.1.5 "Assertion Verification", below. If successful, then 730 this procedure continues with the next step. 732 6.1.3.6. Verifier performs Next Step 734 The SIP request was successfully processed. The verifier now 735 performs its next step, which depends at least in part on the type of 736 SIP request it received. 738 6.1.4. Assertion Profile Description 740 This section defines the particulars of how the sender, i.e., the 741 SAML Authority, MUST construct certain portions of the SAML 742 assertions it issues. The schema for SAML assertions themselves is 743 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 745 An example SAML assertion, formulated according to this profile is 746 given in Section 8. 748 Overall SAML assertion profile requirements: 750 The SAML assertion MUST be signed by the same key as used to sign 751 the contents of the Identity header field. Signing of SAML 752 assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. 754 In the following subsections, the SAML assertion profile is specified 755 element-by-element, in a top-down, depth-first manner, beginning with 756 the outermost element, "". Where applicable, the 757 requirements for an element's XML attributes are also stated, as a 758 part of the element's description. Requirements for any given 759 element or XML attribute are only stated when, in the context of use 760 of this profile, they are not already sufficiently defined by 761 [OASIS.saml-core-2.0-os]. 763 6.1.4.1. Element: 765 Attribute: ID 767 The value for the ID XML attribute SHOULD be allocated randomly 768 such that the value meets the randomness requirments specified in 769 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 771 Attribute: IssueInstant 773 The value for the IssueInstant XML attribute SHOULD be set at the 774 time the SAML assertion is created (and cached for subsequent 775 retrieval). This time instant value MAY be temporally the same as 776 that encoded in the SIP message's Date header, and MUST be at 777 least temporally later, although it is RECOMMENDED that it not be 778 10 minutes or more later. 780 6.1.4.1.1. Element: 782 The value for the Issuer XML element MUST be a value that matches 783 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 784 the certificate conveyed by the SAML assertion in the ds: 785 X509Certificate element located on this path within the SAML 786 assertion: 788 796 The element SHOULD contain both a element and a 797 element. 799 The value of the element MUST be the same as the Address of 800 Record (AoR) value used in computing the "signed-identity-digest" 801 which forms the value of the Identity header. See Section 9 of 802 [I-D.ietf-sip-identity]. 804 The element attribute Method SHOULD be set to 805 the value: 807 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 809 Although it MAY be set to some other implementation- and/or 810 deployment-specific value. The element itself 811 SHOULD be empty. 813 6.1.4.1.3. Element: 815 The element SHOULD contain an 816 element, which itself SHOULD contain an element. The 817 value of the element SHOULD be the same as the addr-spec 818 of the SIP request's To header field. 820 The following XML attributes of the element MUST be set 821 as follows: 823 Attribute: NotBefore 825 The value of the NotBefore XML attribute MUST be set to a time 826 instant the same as the value for the IssueInstant XML attribute 827 discussed above, or to a later time. 829 Attribute: NotOnOrAfter 831 The value of the NotOnOrAfter XML attribute MUST be set to a time 832 instant later than the value for NotBefore. 834 6.1.4.1.4. Element: 836 The SAML assertion MAY contain an element. If 837 so, the element will contain attribute-value 838 pairs, e.g., of a user profile nature, encoded according to either 839 one of the "SAML Attribute Profiles" as specified in [OASIS.saml- 840 profiles-2.0-os], or encoded in some implementation- and/or 841 deployment-specific attribute profile. 843 The attribute-value pairs SHOULD in fact pertain to the entity 844 identified in the SIP From header field, since a SAML assertion 845 formulated per this overall section is stating that they do. 847 6.1.5. Assertion Verification 849 This section specifies the steps that a verifier participating in 850 this profile MUST perform in addition to the "Verifier Behavior" 851 specified in Section 6 of [I-D.ietf-sip-identity]. 853 The steps are: 855 1. Before Step 1 in Section 6 of [I-D.ietf-sip-identity], the 856 verifier MUST extract the AS's domain certificate from the XML element at the end of the element path 858 given in Section 6.1.4.1.1. 860 2. Perform Step 1 in Section 6 of [I-D.ietf-sip-identity]. 862 3. After Step 1 in Section 6 of [I-D.ietf-sip-identity], but before 863 Step 2 of that section, the verifier MUST verify the SAML 864 assertion's signature via the procedures specified in Section 865 5.4 of [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 867 @@ TODO: do we need to define a new SIP error response code for 868 when a SAML assn signature is bad? e.g., '4xx Invalid SAML 869 asssertion'. 871 4. Perform Step 2 in Section 6 of [I-D.ietf-sip-identity]. 873 5. Verify that the signer of the SIP message's Identity header 874 field is the same as the signer of the SAML assertion. 876 6. Perform Steps 3 and 4 in Section 6 of [I-D.ietf-sip-identity]. 878 7. Verify that the SAML assertion's element value matches 879 the Issuer or the Issuer Alternative Name fields [RFC3280] in 880 the AS's domain certificate. 882 8. Verify that the SAML assertion's element value is the 883 same as the Address of Record (AoR) value in the "signed- 884 identity-digest". See Section 9 of [I-D.ietf-sip-identity]. 886 9. Verify that the SAML assertion's element 887 value is set to whichever value was configured at 888 implementation- or deployment-time. The default value is: 890 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 892 10. Verify that the SAML assertion contains an element, 893 and that its value matches the value of the addr-spec of the SIP 894 To header field. 896 11. Verify that the validity period denoted by the NotBefore and 897 NotOnOrAfter attributes of the element meets the 898 requirements given in Section 6.1.4.1.3. 900 7. SAML SIP Binding 902 This section specifies one SAML SIP Binding at this time. Additional 903 bindings may be specified in future revisions of this specification. 905 7.1. SAML HTTP-URI-based SIP Binding 907 This section specifies the "SAML HTTP-URI-based SIP Binding", 908 (SHUSB). 910 The SHUSB is a profile of the "SAML URI Binding" specified in Section 911 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 912 a means by which SAML assertions can be referenced by URIs and thus 913 be obtained through resolution of such URIs. 915 This profile of the SAML URI Binding is congruent with the SAML URI 916 Binding -- including support for HTTP-based URIs being mandatory to 917 implement -- except for the following further restrictions which are 918 specified in the interest of interoperability (section numbers refer 919 to [OASIS.saml-bindings-2.0-os]): 921 Section 3.7.5.3 Security Considerations: 923 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 925 Section 3.7.5.4 Error Reporting: 927 All SHOULDs in this section are to be interpreted as MUSTs. 929 8. Example SAML Assertions 931 This section presents two examples of a SAML assertion, one unsigned 932 (for clarity), the other signed (for accuracy). 934 In the first example, Figure 5, the assertion is attesting with 935 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 936 The validity conditions are expressed in lines 16-23, via both a 937 validity period expressed as temporal endpoints, and an "audience 938 restriction" stating that this assertion's semantics are valid for 939 only the relying party named "example2.com". Also, the assertion's 940 issuer is noted in lines 4-5. 942 The above items correspond to some aspects of this specification's 943 SAML assertion profile, as noted below in Security Considerations 944 dicussions, see: Section 9.1 and Section 9.2. 946 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 947 fashion, using LDAP/X.500 schema as the typing means. 949 1 952 4 953 5 example.com 954 6 955 7 956 8 959 11 Alice@example.com 960 12 961 13 963 15 964 16 966 18 967 19 968 20 example2.com 969 21 970 22 971 23 972 24 973 25 980 32 981 33 +1-888-555-1212 982 34 983 35 984 36 985 37 987 Figure 5: Unsigned SAML Assertion Illustrating Conveyance of 988 Subject Attribute 990 In the second example, Figure 6, the information described above is 991 the same, the addition is that this version of the assertion is 992 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 994 integrity are assured. Since this assertion is the same as the one 995 in the first example above, other than having a signature added, the 996 second example below addresses the same Security Considerations 997 aspects, plus those requiring a Signature. 999 1 1002 4 1003 5 example.com 1004 6 1005 7 1006 8 1007 9 1009 11 1011 13 1013 15 1014 16 1017 19 1020 22 1024 26 1025 27 1026 28 1028 30 1029 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1030 32 1031 33 1032 34 1033 35 1034 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1035 37 1036 38 1037 39 1038 40 1039 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1040 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1041 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1042 44 1043 45 1044 46 1045 47 1046 48 1047 49 1050 52 Alice@example.com 1051 53 1052 54 1054 56 1055 57 1057 59 1058 60 1059 61 example2.com 1060 62 1061 63 1062 64 1063 65 1064 66 1071 73 1072 74 +1-888-555-1212 1073 75 1074 76 1075 77 1076 78 1078 Figure 6: Signed SAML Assertion Illustrating Conveyance of Subject 1079 Attribute 1081 9. Security Considerations 1083 This section discusses security considerations when using SAML with 1084 SIP. 1086 9.1. Man-in-the-middle Attacks and Stolen Assertions 1088 Threat: 1090 By making SAML assertions available via HTTP-based requests by a 1091 potentially unbounded set of requesters, it is conceivably 1092 possible that anyone would be able to simply request one and 1093 obtain it. By SIP intermediaries on the signaling path for 1094 example. Or, an HTTP intermediary/proxy could intercept the 1095 assertion as it is being returned to a requester. 1097 The attacker could then conceivably attempt to impersonate the 1098 subject (the putative caller) to some SIP-based target entity. 1100 Countermeasures: 1102 Such an attack is implausible for several reasons. The primary 1103 reason is that a message constructed by an imposter using a stolen 1104 assertion that conveys the public key certificate of some domain 1105 will not verify per [I-D.ietf-sip-identity] because the imposter 1106 will not have the corresponding private key with which to generate 1107 the signed Identity header value. 1109 Also, the SIP SAML assertion profile specified herein that the 1110 subject's SAML assertion must adhere to causes it to be not useful 1111 to arbitrary parties. The subject's assertion: 1113 * should be signed, thus causing any alterations to break its 1114 integrity and make such alterations detectable. 1116 * does not contain an authentication statement. Thus no parties 1117 implementing this specification should be relying on SAML 1118 assertions specified herein as sufficient in and of themselves 1119 to allow access to resources. 1121 * relying party is represented in the SAML assertion's Audience 1122 Restriction. 1124 * Issuer is represented in the SAML assertion. 1126 * validity period for assertion is restricted. 1128 * etc. 1130 9.2. Forged Assertion 1132 Threat: 1134 A malicious user could forge or alter a SAML assertion in order to 1135 communicate with the SIP entities. 1137 Countermeasures: 1139 To avoid this kind of attack, the entities must assure that proper 1140 mechanisms for protecting the SAML assertion are employed, e.g., 1141 signing the SAML assertion itself. Section 5.1 of [OASIS.saml- 1142 core-2.0-os] specifies the signing of SAML assertions. 1144 Additionally, the assertion content dictated by the SAML assertion 1145 profile herein ensures ample evidence for a relying party to 1146 verify the assertion and its relationship with the received SIP 1147 request. 1149 9.3. Replay Attack 1151 Threat: 1153 Theft of SIP message protected by the mechanisms described herein 1154 and replay of it at a later time. 1156 Countermeasures: 1158 There are various provisions within [I-D.ietf-sip-identity] that 1159 prevent a replay attack. 1161 10. Contributors 1163 The authors would like to thank Marcus Tegnander and Henning 1164 Schulzrinne for his contributions to earlier versions of this 1165 document. 1167 11. Acknowledgments 1169 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1170 Schubert, Jason Fischl and Vijay Gurbani for their comments to this 1171 draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 1172 Profile" is based on an idea by Jon Peterson. 1174 12. IANA Considerations 1176 [Editor's Note: A future version of this document will provide IANA 1177 considerations.] 1179 13. Open Issues 1181 A list of open issues can be found at: 1182 http://www.tschofenig.com:8080/saml-sip/ 1184 14. References 1186 14.1. Normative References 1188 [I-D.ietf-sip-identity] 1189 Peterson, J. and C. Jennings, "Enhancements for 1190 Authenticated Identity Management in the Session 1191 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 1192 (work in progress), October 2005. 1194 [I-D.ietf-sipping-trait-authz] 1195 Peterson, J., "Trait-based Authorization Requirements for 1196 the Session Initiation Protocol (SIP)", 1197 draft-ietf-sipping-trait-authz-02 (work in progress), 1198 January 2006. 1200 [OASIS.saml-bindings-2.0-os] 1201 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1202 Maler, "Bindings for the OASIS Security Assertion Markup 1203 Language (SAML) V2.0", OASIS 1204 Standard saml-bindings-2.0-os, March 2005. 1206 [OASIS.saml-core-2.0-os] 1207 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1208 "Assertions and Protocol for the OASIS Security Assertion 1209 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1210 2.0-os, March 2005. 1212 [OASIS.saml-metadata-2.0-os] 1213 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1214 "Metadata for the Security Assertion Markup Language 1215 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1216 March 2005. 1218 [OASIS.saml-profiles-2.0-os] 1219 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1220 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1221 Security Assertion Markup Language (SAML) V2.0", OASIS 1222 Standard OASIS.saml-profiles-2.0-os, March 2005. 1224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1225 Requirement Levels", BCP 14, RFC 2119, March 1997. 1227 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1228 Locators", RFC 2392, August 1998. 1230 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1231 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1232 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1234 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1235 A., Peterson, J., Sparks, R., Handley, M., and E. 1236 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1237 June 2002. 1239 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1240 X.509 Public Key Infrastructure Certificate and 1241 Certificate Revocation List (CRL) Profile", RFC 3280, 1242 April 2002. 1244 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1245 Method", RFC 3515, April 2003. 1247 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1248 IETF URN Sub-namespace for Registered Protocol 1249 Parameters", BCP 73, RFC 3553, June 2003. 1251 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1252 Authenticated Identity Body (AIB) Format", RFC 3893, 1253 September 2004. 1255 [W3C.xmldsig-core] 1256 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1257 Syntax and Processing", W3C Recommendation xmldsig-core, 1258 October 2000, . 1260 14.2. Informative References 1262 [I-D.ietf-sip-content-indirect-mech] 1263 Burger, E., "A Mechanism for Content Indirection in 1264 Session Initiation Protocol (SIP) Messages", 1265 draft-ietf-sip-content-indirect-mech-05 (work in 1266 progress), October 2004. 1268 [I-D.ietf-sipping-certs] 1269 Jennings, C. and J. Peterson, "Certificate Management 1270 Service for The Session Initiation Protocol (SIP)", 1271 draft-ietf-sipping-certs-03 (work in progress), 1272 March 2006. 1274 [I-D.jennings-sipping-pay] 1275 Jennings, C., "Payment for Services in Session Initiation 1276 Protocol (SIP)", draft-jennings-sipping-pay-03 (work in 1277 progress), October 2005. 1279 [I-D.peterson-message-identity] 1280 Peterson, J., "Security Considerations for Impersonation 1281 and Identity in Messaging Systems", 1282 draft-peterson-message-identity-00 (work in progress), 1283 October 2004. 1285 [IANA.application.samlassertion-xml] 1286 OASIS Security Services Technical Committee (SSTC), 1287 "application/samlassertion+xml MIME Media Type 1288 Registration", IANA MIME Media Types Registry application/ 1289 samlassertion+xml, December 2004. 1291 [OASIS.saml-conformance-2.0-os] 1292 Mishra, P., Philpott, R., and E. Maler, "Conformance 1293 Requirements for the Security Assertion Markup Language 1294 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1295 March 2005. 1297 [OASIS.saml-glossary-2.0-os] 1298 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1299 Security Assertion Markup Language (SAML) V2.0", OASIS 1300 Standard saml-glossary-2.0-os, March 2005. 1302 [OASIS.saml-sec-consider-2.0-os] 1303 Hirsch, F., Philpott, R., and E. Maler, "Security and 1304 Privacy Considerations for the OASIS Security Markup 1305 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1306 2.0-os, March 2005. 1308 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1309 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1310 OASIS SSTC Committee 1311 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1313 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1314 Cantor, S., "SAML Protocol Extension for Third-Party 1315 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1316 ext-thirdparty-cd-01, March 2006. 1318 [OASIS.sstc-saml-tech-overview-2.0-draft-08] 1319 Hughes, J. and E. Maler, "Security Assertion Markup 1320 Language (SAML) V2.0 Technical Overview", OASIS SSTC 1321 Working Draft sstc-saml-tech-overview-2.0-draft-08, 1322 September 2005. 1324 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1325 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1326 March 1999. 1328 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1329 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1330 September 1999. 1332 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1333 Certificate Profile for Authorization", RFC 3281, 1334 April 2002. 1336 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1337 Initiation Protocol (SIP)", RFC 3323, November 2002. 1339 Appendix A. Appendix: Use-case Scenarios 1341 This Appendix explores message flows based on various use-case 1342 scenarios in [I-D.ietf-sipping-trait-authz], and from various 1343 discussions, to which SAML-based solutions are applied. Appendix A.2 1344 shows a SIP conferencing scenario with role-based access control 1345 using SAML. 1347 Note that we present these scenarios as illustrations of possible 1348 SAML-based use cases in SIP. This document does not provide a 1349 detailed exposition of these scenarios -- that is left for addtional 1350 documents. 1352 A.1. PSTN-to-SIP Phone Call 1354 Alice, using a phone connected to the PSTN, wants to make a call to 1355 Bob, who resides in a SIP network. Her call is switched through the 1356 PSTN by means of PSTN signaling (outside the scope of this document) 1357 to the PSTN/SIP gateway. At the gateway, the call is converted from 1358 SS7 signaling to SIP signaling. Since Alice's PSTN phone was 1359 previously "authenticated" via PSTN signaling mechanisms, the gateway 1360 is able to assert her phone's identity (e.g., her telephone number) 1361 via SIP Identity and SAML-based mechanisms (e.g., in order to convey 1362 profile attributes) to Bob's SIP proxy, which also dereferences the 1363 URI in the Identity-Info header in order to obtain the SAML assertion 1364 and the PSTN/SIP Gateway's domain certificate. Alice's INVITE is 1365 then forwarded from the SIP/PSTN gateway to Bob's phone, and is 1366 secured via whatever means is locally established in Bob's 1367 administrative domain. 1369 +-----------+ 1370 +----------------------+ | | 1371 | | SS7 | PSTN/SIP | 1372 | Public Switched |--------------------->| Gateway | 1373 | | | | 1374 | | | | 1375 | Telephone Network | +--+-----------+------+ 1376 | ^ | | | ^ V | 1377 +---------+------------+ | | ^ V SIP-Ident | 1378 | SS7 | v ^ V +SAML | 1379 | | +--------+ | 1380 O | | Bob's | | 1381 O /|\ <----+----| SIP | | 1382 /|\ / \ SIP | | Proxy | | 1383 / \ Bob | | | | 1384 Alice | +--------+ | 1385 | SIP based | 1386 | Network | 1387 +---------------------+ 1389 Figure 7: PSTN to SIP call 1391 Note that the INVITE emitted by the PSTN/SIP gateway could 1392 alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone, 1393 and Bob's phone could take on the SIP Identity "verifier" role, which 1394 is being played by Bob's SIP proxy in the figure. 1396 Whichever approach is employed is a decision local to Bob's 1397 administrative domain and can be made independently. 1399 A.2. SIP Conferencing 1401 This section is meant to foster discussion about the usage of SAML in 1402 the domain of conferencing. A user agent who routes its SIP message 1403 through the Authentication Service (Asserting Party) towards a 1404 conferencing server may want or need various of her profile 1405 attributes included and may also need to be authenticated by the 1406 conference server. The following properties could be provided by 1407 this procedure: 1409 o The user identity can be replaced to allow the user to be 1410 anonymous with regard to the Focus. This can be accomplished via 1411 [RFC3323] in combination with [I-D.ietf-sip-identity], per the 1412 latter, or, 1414 o The user identity could be asserted to the Focus, via [I-D.ietf- 1415 sip-identity] mechanisms, and/or, 1417 o the SAML assertion could provide additional user profile 1418 information such as group membership (belongs to the students, 1419 staff, faculty group of university X). This could, for non- 1420 identity-based authorization systems, imply certain rights. 1422 The corresponding SIP message flow (in high level detail) could have 1423 the following shape: 1425 +-----+ +-----------+ +-----------+ 1426 | | | SIP Proxy | | Focus | 1427 |User | |(Asserting | | (Relying | 1428 | | | party) | | party) | 1429 +--+--+ +-----+-----+ +-----+-----+ 1430 | INVITE | | 1431 |sip:conf-factory | INVITE | 1432 |------------------>| w/Identity hdr | 1433 | |------------------>| 1434 | | | 1435 | | HTTP GET SAML assn| 1436 | |<==================| 1437 | | and domain cert | 1438 | | | 1439 | | HTTP 200 OK + assn| 1440 | |==================>| 1441 | | and domain cert | 1442 | | | 1443 | | | 1444 | | Ringing | 1445 | Ringing |<------------------| 1446 |<------------------| | 1447 | | | 1448 | | OK | 1449 | OK |<------------------| 1450 |<------------------| | 1451 | | | 1452 | ACK | | 1453 |------------------>| ACK | 1454 | |------------------>| 1455 | | | 1456 | | | 1457 ... many more msgs... 1459 Figure 8: SIP Conferencing and SAML 1461 However, there are obvious scaling issues with the conference server 1462 having to do the outbound requests in order to obtain SAML assertions 1463 and certificates for conference participants. 1465 This could be addressed by creating another SIP SAML Profile where 1466 the caller obtains the necessary information, e.g., SAML assertions, 1467 and places them into its SIP request message prior to sending it. 1468 This would obviate the need for the callee relying party to make 1469 requests in order to obtain said information. This is a topic for 1470 future work, and possibly future revisions of this specification. 1472 A.3. Compensation using SIP and SAML 1474 This section describes a scenario where SAML is used in SIP to 1475 realize compensation functionality as described in [I-D.jennings- 1476 sipping-pay]. 1478 Note that this scenario is not directly addressed by the SIP SAML 1479 Profile and SAML SIP Binding presently defined in this specification. 1480 Rather, this use case calls for additional such profiles and bindings 1481 to be developed. 1483 +--------+ +--------+ +--------+ 1484 |Payment | | User | |Merchant| 1485 |Provider| | Alice | |Bob | 1486 | | | | | | 1487 | | | | | | 1488 +---+----+ +---+----+ +---+----+ 1489 | | | 1490 | | 1) Call | 1491 | |------------------------>| 1492 | | | 1493 | | 2) 402 + Payment Offer | 1494 | 3) Request for |<------------------------| 1495 | a Payment | | 1496 |<----------------------| | 1497 | | | 1498 | 4) SAML Assertion | | 1499 | (=Receipt) | | 1500 |---------------------->| | 1501 | | 5) Call + Receipt | 1502 | |------------------------>| 1503 | | | 1504 | | 6) 200 OK | 1505 | |<------------------------| 1506 | | | 1508 Figure 9: Message flow for SIP payment 1510 User Alice and the Merchant Bob interact with each other using SIP 1511 and the Alice uses HTTP to exchange messages with a Payment Provider. 1512 Initially, Alice makes a call to Bob (1). Bob determines that a 1513 payment is required and includes information about the payment in an 1514 Offer body of a 402 (Payment Required) response to Alice (2). Alice 1515 looks at this Offer and decides to make a payment. Alice therefore 1516 instructs her Payment Provider to make a transfer from Alice"s 1517 account to the Merchants"s account (3) using a request for a SAML 1518 assertion with the extensions defined in this document. The Payment 1519 Provider returns a receipt for this transfer (4). This receipt is a 1520 SAML Assertion. Alice resubmits the call to Bob but this time 1521 provides the Receipt for the transaction (5). Bob determines whether 1522 the Receipt is valid (by checking the digital signature and the 1523 content of the assertion) and continues with the call processing, if 1524 the authorization was succesful. 1526 The Offer contains information about the participating parties (i.e., 1527 the Payment Provider, the Merchant Bob, and the user Alice), the 1528 transaction amount, the account identifier for Bob at the Payment 1529 Provider, and a replay protection indicator to make it easier for the 1530 Merchant Bob to avoid replay attacks. User Alice includes this 1531 information when making the Request for Payment to the Payment 1532 Provider; adds its own account information and authorization 1533 password; and sends this to the Payment Provider, which produces a 1534 Receipt for the transaction if it is successful. This transfer from 1535 Alice to the Payment Provider is made across an encrypted, integrity 1536 protected channel. The Receipt includes a timestamp when the Payment 1537 Provider made the transaction and protects the Receipt with a digital 1538 signature. Alice resubmits the call to the Merchant Bob with the 1539 Receipt from the Payment Provier. Merchant Bob can check for replay 1540 attacks using the timestamp and a replay protection indiciator 1541 initially provided with the Offer. Bob can then check the signature 1542 is valid using the Payment Provider"s public key. 1544 Authors' Addresses 1546 Hannes Tschofenig 1547 Siemens 1548 Otto-Hahn-Ring 6 1549 Munich, Bavaria 81739 1550 Germany 1552 Email: Hannes.Tschofenig@siemens.com 1554 Jeff Hodges 1555 NeuStar, Inc. 1556 2000 Broadway Street 1557 Redwood City, CA 94063 1558 US 1560 Email: Jeff.Hodges@neustar.biz 1562 Jon Peterson 1563 NeuStar, Inc. 1564 1800 Sutter St Suite 570 1565 Concord, CA 94520 1566 US 1568 Email: jon.peterson@neustar.biz 1570 James Polk 1571 Cisco 1572 2200 East President George Bush Turnpike 1573 Richardson, Texas 75082 1574 US 1576 Email: jmpolk@cisco.com 1578 Douglas C. Sicker 1579 University of Colorado at Boulder 1580 ECOT 430 1581 Boulder, CO 80309 1582 US 1584 Email: douglas.sicker@colorado.edu 1586 Intellectual Property Statement 1588 The IETF takes no position regarding the validity or scope of any 1589 Intellectual Property Rights or other rights that might be claimed to 1590 pertain to the implementation or use of the technology described in 1591 this document or the extent to which any license under such rights 1592 might or might not be available; nor does it represent that it has 1593 made any independent effort to identify any such rights. Information 1594 on the procedures with respect to rights in RFC documents can be 1595 found in BCP 78 and BCP 79. 1597 Copies of IPR disclosures made to the IETF Secretariat and any 1598 assurances of licenses to be made available, or the result of an 1599 attempt made to obtain a general license or permission for the use of 1600 such proprietary rights by implementers or users of this 1601 specification can be obtained from the IETF on-line IPR repository at 1602 http://www.ietf.org/ipr. 1604 The IETF invites any interested party to bring to its attention any 1605 copyrights, patents or patent applications, or other proprietary 1606 rights that may cover technology that may be required to implement 1607 this standard. Please address the information to the IETF at 1608 ietf-ipr@ietf.org. 1610 Disclaimer of Validity 1612 This document and the information contained herein are provided on an 1613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1615 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1616 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1617 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1620 Copyright Statement 1622 Copyright (C) The Internet Society (2006). This document is subject 1623 to the rights, licenses and restrictions contained in BCP 78, and 1624 except as set forth therein, the authors retain all their rights. 1626 Acknowledgment 1628 Funding for the RFC Editor function is currently provided by the 1629 Internet Society.