idnits 2.17.00 (12 Aug 2021) /tmp/idnits31256/draft-ietf-sip-saml-01.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 1851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1875. ** 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 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 258 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 (October 23, 2006) is 5689 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 1475, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1496, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-content-indirect-mech' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-certs' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-message-identity' is defined on line 1531, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1576, 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-04 -- 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 (~~), 12 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 Networks GmbH & Co KG 4 Intended status: Standards Track J. Hodges 5 Expires: April 26, 2007 J. Peterson 6 NeuStar, Inc. 7 J. Polk 8 Cisco 9 D. Sicker 10 CU Boulder 11 October 23, 2006 13 SIP SAML Profile and Binding 14 draft-ietf-sip-saml-01.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 April 26, 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 61 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 62 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 63 6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14 64 6.1. AS-driven SIP SAML URI-based Attribute Assertion 65 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14 66 6.1.1. Required Information . . . . . . . . . . . . . . . . . 14 67 6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14 68 6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18 69 6.1.4. Assertion Profile Description . . . . . . . . . . . . 21 70 6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 24 71 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26 72 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26 73 8. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 8.1. 425 (Bad SAML Assertion) Response Code . . . . . . . . . . 27 75 8.2. The SAML Reason Protocol . . . . . . . . . . . . . . . . . 27 76 8.3. Failure Reasons to be Registered . . . . . . . . . . . . . 28 77 8.3.1. SAML Assertion Content Not Supported . . . . . . . . . 28 78 8.3.2. Authentication Statements Desired Instead . . . . . . 28 79 8.3.3. Authorization Statements Desired Instead . . . . . . . 29 80 8.3.4. Attribute Statements Desired Instead . . . . . . . . . 29 81 8.3.5. Unsupported Content . . . . . . . . . . . . . . . . . 29 82 8.3.6. Unable to Dereference . . . . . . . . . . . . . . . . 30 83 8.3.7. Cannot Parse SAML Assertion . . . . . . . . . . . . . 30 84 8.3.8. Conflicting SAML Assertions Supplied . . . . . . . . . 30 85 8.3.9. Insufficient SAML Statements . . . . . . . . . . . . . 31 86 8.3.10. Dereference Timeout . . . . . . . . . . . . . . . . . 31 87 9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 32 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 89 10.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 37 90 10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 38 91 10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 38 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 95 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 96 13.1. IANA Registration for Response Code 4XX . . . . . . . . . 41 97 13.2. IANA Registration of the SAML Reason Protocol . . . . . . 41 98 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 100 15.1. Normative References . . . . . . . . . . . . . . . . . . . 43 101 15.2. Informative References . . . . . . . . . . . . . . . . . . 44 102 Appendix A. Appendix: Use-case Scenarios . . . . . . . . . . . . 47 103 A.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 47 104 A.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 48 105 A.3. Compensation using SIP and SAML . . . . . . . . . . . . . 50 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 107 Intellectual Property and Copyright Statements . . . . . . . . . . 53 109 1. Introduction 111 This document specifies composition of the Security Assertion Markup 112 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 113 richer authorization mechanisms and enable "trait-based 114 authorization." Trait-based authorization is where one is authorized 115 to make use of some resource based on roles or traits rather than 116 ones identifier(s). Motivations for trait-based authorization, along 117 with use-case scenarios, are presented in 118 [I-D.ietf-sipping-trait-authz]. 120 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 121 based framework for creating and exchanging security information. 122 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 123 [OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative 124 overviews of SAMLv2. The SAMLv2 specification set is normatively 125 defined by [OASIS.saml-conformance-2.0-os]. 127 Various means of providing trait-based authorization exist: 128 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 129 to the authenticated identity body [RFC3893]. The authors selected 130 SAML due to its increasing use in environments such as the Liberty 131 Alliance, and the Internet2 project, areas where the applicability to 132 SIP is widely desired. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 The SIP network element "Authentication Service" is introduced in 141 [I-D.ietf-sip-identity]. We reuse this term to refer to a network 142 element that authenticates and authorizes a user and creates a "SIP 143 identity assertion". This system entity is the logical equivalent of 144 a "SAML Authority" in the SAML terminology. 146 For overall SIP terminology, see [RFC3261]. 148 In this specification, the term, or term component, "SAML" refers to 149 SAML V2.0 in all cases. For example, the term "SAML assertion" 150 implicitly means "SAMLv2 assertion". For overall SAML terminology, 151 see [OASIS.saml-glossary-2.0-os]. 153 The below list maps other various SIP terms to their SAML 154 (rough-)equivalents: 156 Element, Network Element: 158 System Entity, Entity 160 Authentication Service: 162 SAML Authority 164 Invitee, Invited User, Called Party, Callee: 166 Relying Party 168 Server, User Agent Server (UAS): 170 SAML Responder 172 User Agent Client (UAC), client: 174 SAML Requester 176 Additional terms defined in the context of this specification: 178 profile attribute(s): 180 one or more attributes of a "user profile". 182 user profile, subject profile: 184 the set of various attributes accompanying (i.e., mapped to) a 185 user account in many environments. 187 3. SAML Introduction 189 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 190 [OASIS.sstc-saml-tech-overview-2.0-draft-08] defines an XML-based 191 framework for exchanging "security assertions" between entities. In 192 the course of making, or relying upon such assertions, SAML system 193 entities may use SAML protocols, or other protocols, to communicate 194 an assertion itself, or the subject of an assertion. 196 Thus one can employ SAML to make and encode statements such as "Alice 197 has these profile attributes and her domain's certificate is 198 available over there, and I'm making this statement, and here's who I 199 am." Then one can cause such an assertion to be conveyed to some 200 party who can then rely on it in some fashion for some purpose, for 201 example input it into some local policy evaluation for access to some 202 resource. This is done in a particular "context of use". Such a 203 context of use could be, for example, deciding whether to accept and 204 act upon a SIP-based invitation to initiate a communication session. 206 The specification of how SAML is employed in a particular context of 207 use is known as a "SAML profile". The specification of how SAML 208 assertions and/or protocol messages are conveyed in, or over, another 209 protocol is known as a "SAML Binding". Typically, a SAML profile 210 specifies the SAML bindings that may be used in its context. Both 211 SAML profiles and SAML bindings reference other SAML specifications, 212 especially the SAML Assertions and Protocols, aka "SAML Core", 213 specification [OASIS.saml-core-2.0-os]. 215 There is an additional subtle aspect of SAML profiles that is worth 216 highlighting -- the notion of a "SAML assertion profile". A SAML 217 assertion profile is the specification of the assertion contents in 218 the context of a particular SAML profile. It is possibly further 219 qualified by a particular implementation and/or deployment context. 220 Condensed examples of SAML assertion profiles are: 222 o The SAML assertion must contain at least one authentication 223 statement and no other statements. The relying party must be 224 represented in the element. The 225 SubjectConfirmation Method must be Foo. etc. 227 o The SAML assertion must contain at least one attribute statement 228 and may contain more than one. The values for the subject's 229 profile attributes named "Foo" and "Bar" must be present. An 230 authentication statement may be present. etc. 232 The primary facets of SAML itself are: 234 o Assertions 236 o Abstract Request/Response protocol 238 We describe each in turn below: 240 3.1. SAML Assertions 242 A SAML assertion is a package of information including issuer and 243 subject, conditions and advice, and/or attribute statements, and/or 244 authentication statements and/or other statements. Statements may or 245 may not be present. The SAML assertion "container" itself contains 246 the following information: 248 Issuing information: 250 Who issued the assertion, when was it issued and the assertion 251 identifier. 253 Subject information: 255 The name of the subject, the security domain and optional subject 256 information, like public key. 258 Conditions under which the assertion is valid: 260 Special kind of conditions like assertion validity period, 261 audience restriction and target restriction. 263 Additional advice: 265 Explaining how the assertion was made, for example. 267 In terms of SAML assertions containing SAML attribute statements or 268 SAML authentication statements, here are explanatory examples: 270 With a SAML assertion containing a SAML attribute statement, an 271 issuing authority is asserting that the subject is associated with 272 certain attributes with certain subject profile attribute values. 273 For example, user jon@cs.example.com is associated with the 274 attribute "Department", which has the value "Computer Science". 276 With a SAML assertion containing a SAML authentication statement, 277 an issuing authority is asserting that the subject was 278 authenticated by certain means at a certain time. 280 With a SAML assertion containing both a SAML attribute statement 281 and a SAML authentication statement, an issuing authority is 282 asserting the union of the above. 284 3.2. Abstract Request/Response Protocol 286 SAML defines an abstract request/response protocol for obtaining 287 assertions. See Section 3 "SAML Protocols" of 288 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 289 response returns the requested assertion or an error. This abstract 290 protocol may then be cast into particular contexts of use by binding 291 it to specific underlying protocols, e.g., HTTP or SIP, and 292 "profiling" it for the specific use case at hand. The SAML HTTP- 293 based web single sign-on profile is one such example (see Section 4.1 294 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 295 based SIP communication session establishment, the topic of this 296 specification, is another. 298 4. Specification Scope 300 The scope of this specification is: 302 o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such 303 that a subject's profile attributes, and their domain's 304 certificate, can be conveyed to a relying party using SAML. In 305 doing so, satisfy the requirements outlined in 306 [I-D.ietf-sipping-trait-authz], and compose with 307 [I-D.ietf-sip-identity]. 309 The following are outside the scope of this specification: 311 o Defining a means for configuring the runtime behavior, or 312 deployment characteristics, of the Authentication Service. 314 Discussion: 316 For example, a SIP Authentication Service could be implemented 317 such that its SAML-based features are employed, or not, on a 318 subject-by-subject basis, and/or on a domain-by-domain basis. 320 o The definition of specific conveyed subject profile attributes 321 (aka traits). 323 Discussion: 325 This specification defines a facility enabling "trait-based 326 authorization" as discussed in [I-D.ietf-sipping-trait-authz]. 328 The attributes of interest in trait-based authorization will be 329 ones akin to, for example: roles, organizational membership, 330 access rights, or authentication event context. Definition of 331 such attributes is application- and/or deployment-context- 332 dependent and are not defined in this specification. However, The 333 SAMLv2 specification defines several "SAML Attribute Profiles" for 334 encoding attributes from various application domains, e.g., LDAP, 335 UUID/GUID, DCE PAC, and XACML, in SAML assertions 336 [OASIS.saml-profiles-2.0-os]. 338 In order for any trait-based system to be practical, participating 339 entities must agree on attributes and traits that will be conveyed 340 and subsequently relied upon. Without such agreements, a trait- 341 based system cannot be usefully deployed. This specification does 342 not discuss the manner in which participating entites might 343 discover one another or agree on the syntax and semantics of 344 attributes and traits. 346 Note that SAMLv2 specifies a "metadata" facility that may be 347 useful in addressing this need. 349 5. Employing SAML in SIP 351 Employing SAML in SIP necessitates devising a new SAML profile(s) and 352 binding(s) because the those already specified in the SAMLv2 353 specification set are specific to other use contexts, e.g., HTTP- 354 based web browsing. Although SIP bears some similarity to HTTP, it 355 is a seperately distinct protocol, thus requiring specification of 356 SIP-specific SAML profile(s) and binding(s). This is technically 357 straightforward as both SAML and SIP are explicitly extensible. 359 The "Authenticated Identity Management in SIP" specification 360 [I-D.ietf-sip-identity] (aka "SIP Identity") facilitates the 361 composition of SAML and SIP in that it defines a "mediated 362 authentication architecture" where verifying endpoints verify SIP 363 identity assertions -- i.e., the "Identity" header value -- signed by 364 an Authentication Service (AS). The semantic being that the AS is 365 vouching that it did indeed authenticate the calling party. 367 Such an Authentication Service, which likely has access to various 368 pieces of information concerning the calling party, could also act as 369 a SAML Authority, and make such information available to the callee 370 via SAML. 372 Since [I-D.ietf-sip-identity] stipulates that the AS must make its 373 certificate available for retrieval and convey the availability and 374 access mechanism via a URI, in the Identity-Info header, we have an 375 opportunity to compose SIP Identity and SAML. 377 Such composition can be accomplished by having the resource referred 378 to by the URI in the Identity-Info be a SAML assertion conveying both 379 the AS's certificate and user profile attributes. This is the 380 approach defined in this specification. Figure 1 illustrates this 381 approach in a high-level summary fashion. Figure 2, further below, 382 illustrates additional details. 384 +--------+ +--------------+ +--------+ 385 |Alice@ | |Authentication| | Bob@ | 386 |example | |Service | |example2| 387 |.com | |@example.com | |.com | 388 | | | | | | 389 +---+----+ +------+-------+ +---+----+ 390 | | | 391 | INVITE | | 392 |---------------------->| | 393 | From:alice@foo.com | | 394 | | | 395 | 407 Proxy auth. req. | | 396 |<----------------------| | 397 | Challenge | | 398 | | | 399 | ACK | | 400 |---------------------->| | 401 | | | 402 | INVITE w/authn creds | | 403 |---------------------->| | 404 | | INVITE | 405 | | w/Identity header | 406 | |--------------------->| 407 | | and Identity-Info | 408 | | | 409 | | HTTP GET SAML assn | 410 | |<==================== | 411 | | and domain cert | 412 | | | 413 | | HTTP 200 OK + assn | 414 | |=====================>| 415 | | and domain cert | 416 | 200 OK | | 417 |<----------------------+----------------------| 418 | | | 420 Figure 1: SIP-SAML-based Network Asserted Identity 422 Since the AS already being trusted to create and add the Identity 423 header containing the SIP Identity Assertion, and to supply a pointer 424 to its domain certificate, having it point instead to a SAML 425 assertion conveying the domain certificate and possibly some user 426 profile attributes, does not significantly alter the first-order 427 security considerations examined in [I-D.ietf-sip-identity]. This 428 specification provides some additional security considerations 429 analysis below in Section 10. 431 6. SIP SAML Profiles 433 This section defines one SIP SAML profile: 435 The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 436 Profile" 438 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 440 6.1.1. Required Information 442 The information given in this section is similar to the info provided 443 when registering something, a MIME Media Type, say, with IANA. In 444 this case, it is for registering this profile with the OASIS SSTC. 445 See Section 2 "Specification of Additional Profiles" in 446 [OASIS.saml-profiles-2.0-os]. 448 Identification: 450 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 452 @@ NOTE: This URN must be agreed upon, and then registered with 453 IANA per [RFC3553]. 455 Contact Information: 457 @@ someone's or something's contact info goes here 459 SAML Confirmation Method Identifiers: 461 The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is 462 used in this profile. 464 Description: 466 Given below. 468 Updates: 470 None. 472 6.1.2. Profile Overview 474 Figure 2 illustrates this profile's overall protocol flow. The 475 following steps correspond to the labeled interactions in the figure. 476 Within an individual step, there may be one or more actual message 477 exchanges depending upon the protocol binding employed for that 478 particular step and other implementation-dependent behavior. 480 Although this profile is overview is cast in terms of a SIP INVITE 481 transaction, the reader should note that the mechanism specified 482 herein, and in [I-D.ietf-sip-identity], may be applied to any SIP 483 request message. 485 Figure 2 begins on the next page. 487 +------------------+ +------------------+ +-----------------+ 488 | Caller | |Authn Service (AS)| | Callee | 489 |Alice@example.com | | @example.com | | Bob@example2.com| 490 +--------+---------+ +--------+---------+ +--------+--------+ 491 - - | | | (steps) 492 ^ ^ | INVITE | | 493 | | |---------------------->| | (1a) 494 | | From:alice@foo.com | | 495 | C | To:sip:bob@example.com| | 496 | S | | | 497 | e | 407 Proxy auth. req. | | 498 | q |<----------------------| | (1b) 499 | = | Challenge | | 500 | N | | | 501 | | ACK | | 502 | | |---------------------->| | (1c) 503 | V | | | 504 | - | | | 505 ^ | INVITE + authorization| | 506 D | | header w/ creds | | 507 | |---------------------->| | (2) 508 I | | From:alice@foo.com | | 509 | | To:sip:bob@example.com| | 510 A | Proxy-Authorization:..| | 511 C | | INVITE | 512 L S | |--------------------->| (3) 513 e | | From:alice@foo.com | 514 O q | | To:sip:bob@example2.com 515 | | Identity: ..... | 516 G = | | Identity-Info: | 517 | | https://example.com| 518 | N | | /assns/?ID=abcde | 519 | | | | 520 | + | |URI resolution (eg. HTTP) 521 | | |<=====================| (4) 522 | 1 | | GET /assns/?ID=abcde | 523 | | | | 524 | | | | HTTP/1.1 200 OK | 525 | | | |=====================>| (5) 526 | | | | | 527 | | | | | 528 | | | | | 529 | | | | Alice@example.com 530 | | | | 531 | | | | 532 | | | | ... 533 | | | | 534 | | | | foo=bar | 535 | | | 200 OK | | 536 | V |<----------------------+----------------------| (6) 537 . - | | | 538 V 540 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 541 Transaction 543 Step 1. Initial SIP Transaction between Caller and AS 545 This optional initial step is comprised of substeps 1a, 1b, 546 and 1c in Figure 2. In this step, the caller, Alice, sends 547 a SIP request message, illustrated as an INVITE, indicating 548 Bob as the callee (1a), is subsequently challenged by the AS 549 (1b), and sends an ACK in response to the challenge (1c). 550 The latter message signals the completion of this SIP 551 transaction (which is an optional substep of this profile). 553 Step 2. Caller sends SIP Request Message with Authorization 554 Credentials to the AS 556 Alice then sends an INVITE message in response to the 557 challenge, or uses cached credentials for the domain if step 558 1 was skipped, as specified in [I-D.ietf-sip-identity] and 559 [RFC3261]. Depending on the chosen SIP security mechanism 560 for client authentication either digest authentication, 561 client side authentication of Transport Layer Security, or a 562 combination of both is used to provide the AS with a strong 563 assurance about the identity of Alice. 565 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 567 First, the AS authorizes the received INVITE message as 568 specified in [I-D.ietf-sip-identity] and [RFC3261]. If the 569 authorization is successful, the AS will form the "identity 570 signature" for the message and add Identity and Identity- 571 Info header fields to the message. The AS also at this time 572 constructs and caches a SAML assertion asserting Alice's 573 profile attributes required by Bob's domain (example2.com), 574 and also containing a the domain's (example.com) public key 575 certificate, or a reference to it. This certificate MUST 576 contain the public key corresponding to the private key used 577 to construct the signature whose value was placed in the 578 Identity header. The AS constructs a HTTP-based SAML URI 579 Reference incorporating the assertion's Assertion ID (see 580 section 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses 581 this URI as the value for the Identity-Info header it adds 582 to the INVITE message. 584 The AS determines which profile attributes (if any) to 585 assert in the via local configuration 586 and/or obtaining example2.com's metadata 587 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 588 INVITE message to Bob. 590 Step 4. Callee Dereferences HTTP-based SAML URI Reference 592 Bob's UAC or SIP Proxy receives the message and begins 593 verifying it per the "Verifier Behavior" specified in 594 [I-D.ietf-sip-identity]. In order to accomplish this task, 595 it needs to obtain Alice's domain certificate. It obtains 596 the HTTP-based SAML URI Reference from the message's 597 Identity-Info header and dereferences it per Section 7.1. 598 Note that this is not a SIP message, but an HTTP message 599 [RFC2616]. 601 Step 5. AS Returns SAML Assertion 603 Upon receipt of the above HTTP request, which contains an 604 embedded reference to Alice's SAML Assertion, Alice's AS 605 returns her assertion in an HTTP response message. 607 Upon receipt of Alice's SAML Assertion, the AS continues its 608 verification of the INVITE message. If successful, it 609 returns a 200 OK message directly to Alice. Otherwise it 610 returns an appropriate SIP error response. 612 Step 6. Callee Returns SIP 200 OK to Caller 614 If Bob determines, based upon Alice's identity as asserted 615 by the AS, and as further substantiated by the information 616 in the SAML assertion, to accept the INVITE, he returns a 617 SIP 200 OK message directly to Alice. 619 6.1.3. Profile Description 621 The following sections provide detailed definitions of the individual 622 profile steps. The relevant illustration is Figure 3, below. Note 623 that this profile is agnostic to the specific SIP request, and also 624 that the Sender and Authentication Service (AS) may be seperate or 625 co-located in actuality. 627 +------------------+ +------------------+ +------------------+ 628 | Sender | |Authn Service (AS)| | Verifier | 629 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 630 +--------+---------+ +--------+---------+ +--------+---------+ 631 | | | (steps) 632 | SIP Request | | 633 |---------------------->| | (1a) 634 | | | 635 | 407 Proxy auth. req. | | 636 |<----------------------| | (1b) 637 | Challenge | | 638 | | | 639 | ACK | | 640 |---------------------->| | (1c) 641 | | | 642 | | | 643 |SIP Req + authorization| | 644 | header w/ creds | | 645 |---------------------->| | (2) 646 | | | 647 | | | 648 | | SIP Req + Ident & | 649 | | authz headers | 650 | |--------------------->| (3) 651 | | | 652 | | URI resolution | 653 | |<=====================| (4) 654 | | (via HTTP) | 655 | | | 656 | | HTTP/1.1 200 OK | 657 | |=====================>| (5) 658 | | | 659 | | | 660 | | ? | (6) 661 | | | 663 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 665 6.1.3.1. Initial SIP Transaction between Sender and AS 667 This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication 668 Service Behavior" of [I-D.ietf-sip-identity]. If the SIP request 669 sent by the caller in substep 1a is deemed insufficiently 670 authenticated by the AS per the rules stipulated by 671 [I-D.ietf-sip-identity] Steps 1 and 2, then the AS MUST authenticate 672 the sender of the message. The particulars of how this is 673 accomplished depend upon implementation and/or deployment 674 instantiation as discussed in [I-D.ietf-sip-identity]. Substeps 1b 675 and 1c as shown in Figure 3 are non-normative and illustrative only. 677 6.1.3.2. Sender sends SIP Request Message with Authorization 678 Credentials to the AS 680 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 681 Behavior" of [I-D.ietf-sip-identity]. This request is presumed to be 682 made in a context such that the AS will not challenge it -- i.e., the 683 AS will consider the sender of the message to be authenticated. If 684 this is not true, then this procedure reverts back to Step 1, above. 686 Otherwise, the AS carries out all other processing of the message as 687 stipulated in [I-D.ietf-sip-identity] Steps 1 and 2, and if 688 successful, this procedure procedes to the next step below. 690 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 692 This first portion of this step maps to Steps 3 and 4 of Section 5 693 "Authentication Service Behavior" of [I-D.ietf-sip-identity], which 694 the AS MUST perform, although with the following additional substeps: 696 The AS MUST construct a SAML assertion according to the "Assertion 697 Profile Description" specified in Section 6.1.4 of this 698 specification. 700 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 701 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 703 The AS MUST use the URI constructed in the immediately preceding 704 substep as the value of the Identity-Info header that is added to 705 the SIP request message per Step 4 of Section 5 of 706 [I-D.ietf-sip-identity]. 708 Upon successful completion of all of the above, the AS forwards the 709 request message. 711 At this point in this step, after perhaps traversing some number of 712 intermediaries, the SIP request message arrives at a SIP network 713 entity performing the "verifier" role. This role and its behavior 714 are specified in Section 6 "Verifier Behavior" of 715 [I-D.ietf-sip-identity]. The verifier MUST perform the steps 716 enumerated in the aforementioned section, with the following 717 modifications: 719 Step 1 of [I-D.ietf-sip-identity] Section 6 maps to and is updated 720 by, the following two steps in this procedure. 722 Steps 2, 3, and 4 of [I-D.ietf-sip-identity] Section 6 may be 723 mapped across this latter portion of this step, and/or the 724 following two steps, as appropriate. 726 6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 728 The verifier SHOULD ascertain whether it has a current cached copy of 729 the SIP message sender's SAML assertion and domain certificate. If 730 not, or if the verifier chooses to (e.g., due to local policy), it 731 MUST dereference the the HTTP-based SAML URI Reference found in the 732 SIP message's Identity-Info header. To do so, the verifier MUST 733 employ the "SAML HTTP-URI-based SIP Binding" specified in 734 Section 7.1. 736 6.1.3.5. AS Returns SAML Assertion 738 This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 740 If the prior step returns an HTTP error (e.g., 4xx series), then this 741 procedure terminates and the verifier returns (upstream) a SIP 436 742 'Bad Identity-Info' Response code. 744 Otherwise, the HTTP response message will contain a SAML assertion 745 and be denoted as such via the MIME media type of "application/ 746 samlassertion+xml" [IANA.application.samlassertion-xml]. The 747 verifier MUST perform the verification steps specified in 748 Section 6.1.5 "Assertion Verification", below. If successful, then 749 this procedure continues with the next step. 751 6.1.3.6. Verifier performs Next Step 753 The SIP request was successfully processed. The verifier now 754 performs its next step, which depends at least in part on the type of 755 SIP request it received. 757 6.1.4. Assertion Profile Description 759 This section defines the particulars of how the sender, i.e., the 760 SAML Authority, MUST construct certain portions of the SAML 761 assertions it issues. The schema for SAML assertions themselves is 762 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 764 An example SAML assertion, formulated according to this profile is 765 given in Section 9. 767 Overall SAML assertion profile requirements: 769 The SAML assertion MUST be signed by the same key as used to sign 770 the contents of the Identity header field. Signing of SAML 771 assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. 773 In the following subsections, the SAML assertion profile is specified 774 element-by-element, in a top-down, depth-first manner, beginning with 775 the outermost element, "". Where applicable, the 776 requirements for an element's XML attributes are also stated, as a 777 part of the element's description. Requirements for any given 778 element or XML attribute are only stated when, in the context of use 779 of this profile, they are not already sufficiently defined by 780 [OASIS.saml-core-2.0-os]. 782 6.1.4.1. Element: 784 Attribute: ID 786 The value for the ID XML attribute SHOULD be allocated randomly 787 such that the value meets the randomness requirments specified in 788 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 790 Attribute: IssueInstant 792 The value for the IssueInstant XML attribute SHOULD be set at the 793 time the SAML assertion is created (and cached for subsequent 794 retrieval). This time instant value MAY be temporally the same as 795 that encoded in the SIP message's Date header, and MUST be at 796 least temporally later, although it is RECOMMENDED that it not be 797 10 minutes or more later. 799 6.1.4.1.1. Element: 801 The value for the Issuer XML element MUST be a value that matches 802 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 803 the certificate conveyed by the SAML assertion in the ds: 804 X509Certificate element located on this path within the SAML 805 assertion: 807 815 The element SHOULD contain both a element and a 816 element. 818 The value of the element MUST be the same as the Address of 819 Record (AoR) value used in computing the "signed-identity-digest" 820 which forms the value of the Identity header. See Section 9 of 821 [I-D.ietf-sip-identity]. 823 The element attribute Method SHOULD be set to 824 the value: 826 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 828 Although it MAY be set to some other implementation- and/or 829 deployment-specific value. The element itself 830 SHOULD be empty. 832 6.1.4.1.3. Element: 834 The element SHOULD contain an 835 element, which itself SHOULD contain an element. The 836 value of the element SHOULD be the same as the addr-spec 837 of the SIP request's To header field. 839 The following XML attributes of the element MUST be set 840 as follows: 842 Attribute: NotBefore 844 The value of the NotBefore XML attribute MUST be set to a time 845 instant the same as the value for the IssueInstant XML attribute 846 discussed above, or to a later time. 848 Attribute: NotOnOrAfter 850 The value of the NotOnOrAfter XML attribute MUST be set to a time 851 instant later than the value for NotBefore. 853 6.1.4.1.4. Element: 855 The SAML assertion MAY contain an element. If 856 so, the element will contain attribute-value 857 pairs, e.g., of a user profile nature, encoded according to either 858 one of the "SAML Attribute Profiles" as specified in 859 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 860 and/or deployment-specific attribute profile. 862 The attribute-value pairs SHOULD in fact pertain to the entity 863 identified in the SIP From header field, since a SAML assertion 864 formulated per this overall section is stating that they do. 866 6.1.5. Assertion Verification 868 This section specifies the steps that a verifier participating in 869 this profile MUST perform in addition to the "Verifier Behavior" 870 specified in Section 6 of [I-D.ietf-sip-identity]. 872 The steps are: 874 1. Before Step 1 in Section 6 of [I-D.ietf-sip-identity], the 875 verifier MUST extract the AS's domain certificate from the XML element at the end of the element path 877 given in Section 6.1.4.1.1. 879 2. Perform Step 1 in Section 6 of [I-D.ietf-sip-identity]. 881 3. After Step 1 in Section 6 of [I-D.ietf-sip-identity], but before 882 Step 2 of that section, the verifier MUST verify the SAML 883 assertion's signature via the procedures specified in Section 884 5.4 of [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 886 @@ TODO: do we need to define a new SIP error response code for 887 when a SAML assn signature is bad? e.g., '4xx Invalid SAML 888 asssertion'. 890 4. Perform Step 2 in Section 6 of [I-D.ietf-sip-identity]. 892 5. Verify that the signer of the SIP message's Identity header 893 field is the same as the signer of the SAML assertion. 895 6. Perform Steps 3 and 4 in Section 6 of [I-D.ietf-sip-identity]. 897 7. Verify that the SAML assertion's element value matches 898 the Issuer or the Issuer Alternative Name fields [RFC3280] in 899 the AS's domain certificate. 901 8. Verify that the SAML assertion's element value is the 902 same as the Address of Record (AoR) value in the "signed- 903 identity-digest". See Section 9 of [I-D.ietf-sip-identity]. 905 9. Verify that the SAML assertion's element 906 value is set to whichever value was configured at 907 implementation- or deployment-time. The default value is: 909 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 911 10. Verify that the SAML assertion contains an element, 912 and that its value matches the value of the addr-spec of the SIP 913 To header field. 915 11. Verify that the validity period denoted by the NotBefore and 916 NotOnOrAfter attributes of the element meets the 917 requirements given in Section 6.1.4.1.3. 919 7. SAML SIP Binding 921 This section specifies one SAML SIP Binding at this time. Additional 922 bindings may be specified in future revisions of this specification. 924 7.1. SAML HTTP-URI-based SIP Binding 926 This section specifies the "SAML HTTP-URI-based SIP Binding", 927 (SHUSB). 929 The SHUSB is a profile of the "SAML URI Binding" specified in Section 930 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 931 a means by which SAML assertions can be referenced by URIs and thus 932 be obtained through resolution of such URIs. 934 This profile of the SAML URI Binding is congruent with the SAML URI 935 Binding -- including support for HTTP-based URIs being mandatory to 936 implement -- except for the following further restrictions which are 937 specified in the interest of interoperability (section numbers refer 938 to [OASIS.saml-bindings-2.0-os]): 940 Section 3.7.5.3 Security Considerations: 942 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 944 Section 3.7.5.4 Error Reporting: 946 All SHOULDs in this section are to be interpreted as MUSTs. 948 8. Error Codes 950 8.1. 425 (Bad SAML Assertion) Response Code 952 If a UAS or SIP intermediary detects an error in a request message 953 specific to the location information, a new 4XX level error is 954 created here to indicate a problem with the request message. This 955 document creates and IANA registers the new error code: 957 425 (Bad SAML Assertion) 959 The 425 (Bad SAML Assertion) response code is a rejection of the 960 content of a SAML assertion within the original SIP Request 961 indicating the SAML assertion was malformed or not satisfactory for 962 the recipient's purpose or could not be dereferenced. No further 963 action by the UAC is required. 965 The UAC can use means outside the scope of this document to ensure 966 that subsequent requests are going to contain SAML assertions that 967 are acceptable to the UAS. There is no cross-transaction awareness 968 expected by either the UAS or SIP intermediary as a result of this 969 error message. 971 More resolution of the error for which the 425 was generated MAY be 972 included in a Reason header [RFC3326]. For these more granular 973 location specific errors, the 'protocol' in the Reason header is 974 'SAML', defined in Section 3.4. of RFC 3326 [RFC3326] states that the 975 Reason Header normally is not found in a response. This document 976 extends the use of Reason to include its use within a 425 response. 978 This new error code is IANA registered in Section 9 of this document. 979 An initial set of error codes can be found in Section 8. 981 8.2. The SAML Reason Protocol 983 For use with the Reason header, discussed in Section 8.1, this 984 document defines and IANA registers a new Reason Protocol per RFC 985 3326 [RFC3326]. 987 Protocol Value Protocol Cause Reference 988 SAML Status RFCyyyy (i.e., this document) 990 8.3. Failure Reasons to be Registered 992 Here is the list and description of each IANA registered location 993 error reason code. If the location generator were to receive one of 994 these indications in a SIP response, it would be in a Reason header. 995 The protocol field of this Reason header would be "SAML", as defined 996 in Section 8.2. Examples of the Reason header are given for each 997 indication below. 999 8.3.1. SAML Assertion Content Not Supported 1001 "SAML Assertion Content Not Supported" means the SAML content 1002 supplied in the request was not processed even though the recipient 1003 understood SAML. If the SAML content is understood, but not desired, 1004 a cause=2 or cause=3 response SHOULD be returned. 1006 Cause value: 1 1008 Default text string: SAML Assertion Content Not Supported 1010 An example usage in a SIP Reason header: 1012 Reason: SAML; cause=1; SAML Assertion Content Not Supported 1014 8.3.2. Authentication Statements Desired Instead 1016 "Authentication Statements Desired Instead" means the SAML assertion 1017 supplied in the request was understood and supported, but that the 1018 recipient, or an application on the recipient demands authentication 1019 statements. 1021 Cause value: 2 1023 Default text string: Authentication Statements Desired Instead 1025 An example usage in a SIP Reason header: 1027 Reason: SAML; cause=2; Authentication Statements Desired Instead 1029 8.3.3. Authorization Statements Desired Instead 1031 "Authorization Statements Desired Instead" means the SAML assertion 1032 supplied in the request was understood and supported, but that the 1033 recipient, or an application on the recipient demands authorization 1034 statements. 1036 Cause value: 3 1038 Default text string: Authorization Statements Desired Instead 1040 An example usage in a SIP Reason header: 1042 Reason: SAML; cause=3; Authorization Statements Desired Instead 1044 8.3.4. Attribute Statements Desired Instead 1046 "Attribute Statements Desired Instead" means the SAML assertion 1047 supplied in the request was understood and supported, but that the 1048 recipient, or an application on the recipient demands attribute 1049 statements. 1051 Cause value: 4 1053 Default text string: Attribute Statements Desired Instead 1055 An example usage in a SIP Reason header: 1057 Reason: SAML; cause=4; Attribute Statements Desired Instead 1059 8.3.5. Unsupported Content 1061 "Unsupported Content" means the recipient encounters a problem with 1062 the content of the SAML assertion. 1064 Cause value: 5 1066 Default text string: Unsupported Content 1068 An example usage in a SIP Reason header: 1070 Reason: SAML; cause=5; Unsupported Content 1072 8.3.6. Unable to Dereference 1074 "Unable to Dereference" means the recipient cannot resolve the 1075 reference to a SAML assertion. This may mean the URI is bad, or the 1076 indicated server had some other error or rejected the request. 1078 Cause value: 6 1080 Default text string: Unable to Dereference 1082 An example usage in a SIP Reason header: 1084 Reason: SAML; cause=6; Unable to Dereference 1086 8.3.7. Cannot Parse SAML Assertion 1088 "Cannot Parse SAML Assertion" means the SAML assertion is not well 1089 formed. 1091 Cause value: 7 1093 Default text string: Cannot Parse SAML Assertion 1095 An example usage in a SIP Reason header: 1097 Reason: SAML; cause=7; Cannot Parse SAML Assertion 1099 8.3.8. Conflicting SAML Assertions Supplied 1101 "Conflicting SAML Assertions Supplied" means a recipient received 1102 more than one SAML assertion and their content is conflicting 1104 Cause value: 8 1106 Default text string: Conflicting SAML Assertion Supplied 1108 An example usage in a SIP Reason header: 1110 Reason: SAML; cause=8; Conflicting SAML Assertion Supplied 1112 8.3.9. Insufficient SAML Statements 1114 "Insufficient SAML Statements" means there is not enough information 1115 in the SAML assertion to sufficiently authenticate or authorize the 1116 requesting party. 1118 Cause value: 9 1120 Default text string: Insufficient SAML Statements 1122 An example usage in a SIP Reason header: 1124 Reason: SAML; cause=9; Insufficient SAML Statements 1126 8.3.10. Dereference Timeout 1128 "Dereference Timeout" means that the dereferencing node has not 1129 received a response within a reasonable timeframe. 1131 Cause value: 10 1133 Default text string: Dereference Timeout 1135 An example usage in a SIP Reason header: 1137 Reason: SAML; cause=10; Dereference Timeout 1139 9. Example SAML Assertions 1141 This section presents two examples of a SAML assertion, one unsigned 1142 (for clarity), the other signed (for accuracy). 1144 In the first example, Figure 16, the assertion is attesting with 1145 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 1146 The validity conditions are expressed in lines 16-23, via both a 1147 validity period expressed as temporal endpoints, and an "audience 1148 restriction" stating that this assertion's semantics are valid for 1149 only the relying party named "example2.com". Also, the assertion's 1150 issuer is noted in lines 4-5. 1152 The above items correspond to some aspects of this specification's 1153 SAML assertion profile, as noted below in Security Considerations 1154 dicussions, see: Section 10.1 and Section 10.2. 1156 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 1157 fashion, using LDAP/X.500 schema as the typing means. 1159 1 1162 4 1163 5 example.com 1164 6 1165 7 1166 8 1169 11 Alice@example.com 1170 12 1171 13 1173 15 1174 16 1176 18 1177 19 1178 20 example2.com 1179 21 1180 22 1181 23 1182 24 1183 25 1190 32 1191 33 +1-888-555-1212 1192 34 1193 35 1194 36 1195 37 1197 Figure 16: Unsigned SAML Assertion Illustrating Conveyance of 1198 Subject Attribute 1200 In the second example, Figure 17, the information described above is 1201 the same, the addition is that this version of the assertion is 1202 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 1204 integrity are assured. Since this assertion is the same as the one 1205 in the first example above, other than having a signature added, the 1206 second example below addresses the same Security Considerations 1207 aspects, plus those requiring a Signature. 1209 1 1212 4 1213 5 example.com 1214 6 1215 7 1216 8 1217 9 1219 11 1221 13 1223 15 1224 16 1227 19 1230 22 1234 26 1235 27 1236 28 1238 30 1239 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1240 32 1241 33 1242 34 1243 35 1244 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1245 37 1246 38 1247 39 1248 40 1249 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1250 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1251 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1252 44 1253 45 1254 46 1255 47 1256 48 1257 49 1260 52 Alice@example.com 1261 53 1262 54 1264 56 1265 57 1267 59 1268 60 1269 61 example2.com 1270 62 1271 63 1272 64 1273 65 1274 66 1281 73 1282 74 +1-888-555-1212 1283 75 1284 76 1285 77 1286 78 1288 Figure 17: Signed SAML Assertion Illustrating Conveyance of Subject 1289 Attribute 1291 10. Security Considerations 1293 This section discusses security considerations when using SAML with 1294 SIP. 1296 10.1. Man-in-the-middle Attacks and Stolen Assertions 1298 Threat: 1300 By making SAML assertions available via HTTP-based requests by a 1301 potentially unbounded set of requesters, it is conceivably 1302 possible that anyone would be able to simply request one and 1303 obtain it. By SIP intermediaries on the signaling path for 1304 example. Or, an HTTP intermediary/proxy could intercept the 1305 assertion as it is being returned to a requester. 1307 The attacker could then conceivably attempt to impersonate the 1308 subject (the putative caller) to some SIP-based target entity. 1310 Countermeasures: 1312 Such an attack is implausible for several reasons. The primary 1313 reason is that a message constructed by an imposter using a stolen 1314 assertion that conveys the public key certificate of some domain 1315 will not verify per [I-D.ietf-sip-identity] because the imposter 1316 will not have the corresponding private key with which to generate 1317 the signed Identity header value. 1319 Also, the SIP SAML assertion profile specified herein that the 1320 subject's SAML assertion must adhere to causes it to be not useful 1321 to arbitrary parties. The subject's assertion: 1323 * should be signed, thus causing any alterations to break its 1324 integrity and make such alterations detectable. 1326 * does not contain an authentication statement. Thus no parties 1327 implementing this specification should be relying on SAML 1328 assertions specified herein as sufficient in and of themselves 1329 to allow access to resources. 1331 * relying party is represented in the SAML assertion's Audience 1332 Restriction. 1334 * Issuer is represented in the SAML assertion. 1336 * validity period for assertion is restricted. 1338 * etc. 1340 10.2. Forged Assertion 1342 Threat: 1344 A malicious user could forge or alter a SAML assertion in order to 1345 communicate with the SIP entities. 1347 Countermeasures: 1349 To avoid this kind of attack, the entities must assure that proper 1350 mechanisms for protecting the SAML assertion are employed, e.g., 1351 signing the SAML assertion itself. Section 5.1 of 1352 [OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. 1354 Additionally, the assertion content dictated by the SAML assertion 1355 profile herein ensures ample evidence for a relying party to 1356 verify the assertion and its relationship with the received SIP 1357 request. 1359 10.3. Replay Attack 1361 Threat: 1363 Theft of SIP message protected by the mechanisms described herein 1364 and replay of it at a later time. 1366 Countermeasures: 1368 There are various provisions within [I-D.ietf-sip-identity] that 1369 prevent a replay attack. 1371 11. Contributors 1373 The authors would like to thank Marcus Tegnander and Henning 1374 Schulzrinne for his contributions to earlier versions of this 1375 document. 1377 12. Acknowledgments 1379 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1380 Schubert, Jason Fischl and Vijay Gurbani for their comments to this 1381 draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 1382 Profile" is based on an idea by Jon Peterson. 1384 13. IANA Considerations 1386 13.1. IANA Registration for Response Code 4XX 1388 Reference: RFC-XXXX (i.e. this document) 1389 Response code: 425 1390 Default reason phrase: Bad SAML Assertion 1392 This SIP Response code is defined in Section 8.1 of this document. 1394 13.2. IANA Registration of the SAML Reason Protocol 1396 The Reason Protocol value "SAML" is created by this document, with 1397 the definition and values in Section 8.1. 1399 Cause-Code Optional-Default-Text Reference 1400 ---------- --------------------- --------- 1401 Cause=1 Location Format Not Supported [This doc] 1402 Cause=2 Geo-location Format Desired [This doc] 1403 Cause=3 Civic-location Format Desired [This doc] 1404 Cause=4 Unsupported Schema [This doc] 1405 Cause=5 Cannot Parse Location Supplied [This doc] 1406 Cause=6 Cannot Find Location [This doc] 1407 Cause=7 Cannot Dereference [This doc] 1408 Cause=8 Conflicting Locations Supplied [This doc] 1409 Cause=9 Incomplete Location Supplied [This doc] 1410 Cause=10 Dereference Timeout [This doc] 1411 Cause=11 Cannot Process Dereference [This doc] 1412 Cause=400 Bad Request [This doc] 1413 Cause=403 Forbidden [This doc] 1414 Cause=404 Not Found [This doc] 1415 Cause=414 Location Error [This doc] 1416 Cause=500 Server Internal Error [This doc] 1417 Cause=501 Service Not Implemented [This doc] 1418 Cause=504 Server Time-Out [This doc] 1420 Legend: 1421 ------ 1422 Cause-Code - Cause value for this indication 1423 Optional-Default-Text - optional text string of indication 1424 Reference - document which is the reference for this 1425 cause value 1427 14. Open Issues 1429 A list of open issues can be found at: 1430 http://www.tschofenig.com:8080/saml-sip/ 1432 15. References 1434 15.1. Normative References 1436 [I-D.ietf-sip-identity] 1437 Peterson, J. and C. Jennings, "Enhancements for 1438 Authenticated Identity Management in the Session 1439 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 1440 (work in progress), October 2005. 1442 [I-D.ietf-sipping-trait-authz] 1443 Peterson, J., "Trait-based Authorization Requirements for 1444 the Session Initiation Protocol (SIP)", 1445 draft-ietf-sipping-trait-authz-02 (work in progress), 1446 January 2006. 1448 [OASIS.saml-bindings-2.0-os] 1449 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1450 Maler, "Bindings for the OASIS Security Assertion Markup 1451 Language (SAML) V2.0", OASIS 1452 Standard saml-bindings-2.0-os, March 2005. 1454 [OASIS.saml-core-2.0-os] 1455 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1456 "Assertions and Protocol for the OASIS Security Assertion 1457 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1458 2.0-os, March 2005. 1460 [OASIS.saml-metadata-2.0-os] 1461 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1462 "Metadata for the Security Assertion Markup Language 1463 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1464 March 2005. 1466 [OASIS.saml-profiles-2.0-os] 1467 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1468 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1469 Security Assertion Markup Language (SAML) V2.0", OASIS 1470 Standard OASIS.saml-profiles-2.0-os, March 2005. 1472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1473 Requirement Levels", BCP 14, RFC 2119, March 1997. 1475 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1476 Locators", RFC 2392, August 1998. 1478 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1479 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1480 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1482 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1483 A., Peterson, J., Sparks, R., Handley, M., and E. 1484 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1485 June 2002. 1487 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1488 X.509 Public Key Infrastructure Certificate and 1489 Certificate Revocation List (CRL) Profile", RFC 3280, 1490 April 2002. 1492 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 1493 Header Field for the Session Initiation Protocol (SIP)", 1494 RFC 3326, December 2002. 1496 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1497 Method", RFC 3515, April 2003. 1499 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1500 IETF URN Sub-namespace for Registered Protocol 1501 Parameters", BCP 73, RFC 3553, June 2003. 1503 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1504 Authenticated Identity Body (AIB) Format", RFC 3893, 1505 September 2004. 1507 [W3C.xmldsig-core] 1508 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1509 Syntax and Processing", W3C Recommendation xmldsig-core, 1510 October 2000, . 1512 15.2. Informative References 1514 [I-D.ietf-sip-content-indirect-mech] 1515 Burger, E., "A Mechanism for Content Indirection in 1516 Session Initiation Protocol (SIP) Messages", 1517 draft-ietf-sip-content-indirect-mech-05 (work in 1518 progress), October 2004. 1520 [I-D.ietf-sipping-certs] 1521 Jennings, C. and J. Peterson, "Certificate Management 1522 Service for The Session Initiation Protocol (SIP)", 1523 draft-ietf-sipping-certs-03 (work in progress), 1524 March 2006. 1526 [I-D.jennings-sipping-pay] 1527 Jennings, C., "Payment for Services in Session Initiation 1528 Protocol (SIP)", draft-jennings-sipping-pay-04 (work in 1529 progress), June 2006. 1531 [I-D.peterson-message-identity] 1532 Peterson, J., "Security Considerations for Impersonation 1533 and Identity in Messaging Systems", 1534 draft-peterson-message-identity-00 (work in progress), 1535 October 2004. 1537 [IANA.application.samlassertion-xml] 1538 OASIS Security Services Technical Committee (SSTC), 1539 "application/samlassertion+xml MIME Media Type 1540 Registration", IANA MIME Media Types Registry application/ 1541 samlassertion+xml, December 2004. 1543 [OASIS.saml-conformance-2.0-os] 1544 Mishra, P., Philpott, R., and E. Maler, "Conformance 1545 Requirements for the Security Assertion Markup Language 1546 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1547 March 2005. 1549 [OASIS.saml-glossary-2.0-os] 1550 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1551 Security Assertion Markup Language (SAML) V2.0", OASIS 1552 Standard saml-glossary-2.0-os, March 2005. 1554 [OASIS.saml-sec-consider-2.0-os] 1555 Hirsch, F., Philpott, R., and E. Maler, "Security and 1556 Privacy Considerations for the OASIS Security Markup 1557 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1558 2.0-os, March 2005. 1560 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1561 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1562 OASIS SSTC Committee 1563 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1565 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1566 Cantor, S., "SAML Protocol Extension for Third-Party 1567 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1568 ext-thirdparty-cd-01, March 2006. 1570 [OASIS.sstc-saml-tech-overview-2.0-draft-08] 1571 Hughes, J. and E. Maler, "Security Assertion Markup 1572 Language (SAML) V2.0 Technical Overview", OASIS SSTC 1573 Working Draft sstc-saml-tech-overview-2.0-draft-08, 1574 September 2005. 1576 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1577 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1578 March 1999. 1580 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1581 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1582 September 1999. 1584 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1585 Certificate Profile for Authorization", RFC 3281, 1586 April 2002. 1588 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1589 Initiation Protocol (SIP)", RFC 3323, November 2002. 1591 Appendix A. Appendix: Use-case Scenarios 1593 This Appendix explores message flows based on various use-case 1594 scenarios in [I-D.ietf-sipping-trait-authz], and from various 1595 discussions, to which SAML-based solutions are applied. Appendix A.2 1596 shows a SIP conferencing scenario with role-based access control 1597 using SAML. 1599 Note that we present these scenarios as illustrations of possible 1600 SAML-based use cases in SIP. This document does not provide a 1601 detailed exposition of these scenarios -- that is left for addtional 1602 documents. 1604 A.1. PSTN-to-SIP Phone Call 1606 Alice, using a phone connected to the PSTN, wants to make a call to 1607 Bob, who resides in a SIP network. Her call is switched through the 1608 PSTN by means of PSTN signaling (outside the scope of this document) 1609 to the PSTN/SIP gateway. At the gateway, the call is converted from 1610 SS7 signaling to SIP signaling. Since Alice's PSTN phone was 1611 previously "authenticated" via PSTN signaling mechanisms, the gateway 1612 is able to assert her phone's identity (e.g., her telephone number) 1613 via SIP Identity and SAML-based mechanisms (e.g., in order to convey 1614 profile attributes) to Bob's SIP proxy, which also dereferences the 1615 URI in the Identity-Info header in order to obtain the SAML assertion 1616 and the PSTN/SIP Gateway's domain certificate. Alice's INVITE is 1617 then forwarded from the SIP/PSTN gateway to Bob's phone, and is 1618 secured via whatever means is locally established in Bob's 1619 administrative domain. 1621 +-----------+ 1622 +----------------------+ | | 1623 | | SS7 | PSTN/SIP | 1624 | Public Switched |--------------------->| Gateway | 1625 | | | | 1626 | | | | 1627 | Telephone Network | +--+-----------+------+ 1628 | ^ | | | ^ V | 1629 +---------+------------+ | | ^ V SIP-Ident | 1630 | SS7 | v ^ V +SAML | 1631 | | +--------+ | 1632 O | | Bob's | | 1633 O /|\ <----+----| SIP | | 1634 /|\ / \ SIP | | Proxy | | 1635 / \ Bob | | | | 1636 Alice | +--------+ | 1637 | SIP based | 1638 | Network | 1639 +---------------------+ 1641 Figure 20: PSTN to SIP call 1643 Note that the INVITE emitted by the PSTN/SIP gateway could 1644 alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone, 1645 and Bob's phone could take on the SIP Identity "verifier" role, which 1646 is being played by Bob's SIP proxy in the figure. 1648 Whichever approach is employed is a decision local to Bob's 1649 administrative domain and can be made independently. 1651 A.2. SIP Conferencing 1653 This section is meant to foster discussion about the usage of SAML in 1654 the domain of conferencing. A user agent who routes its SIP message 1655 through the Authentication Service (Asserting Party) towards a 1656 conferencing server may want or need various of her profile 1657 attributes included and may also need to be authenticated by the 1658 conference server. The following properties could be provided by 1659 this procedure: 1661 o The user identity can be replaced to allow the user to be 1662 anonymous with regard to the Focus. This can be accomplished via 1663 [RFC3323] in combination with [I-D.ietf-sip-identity], per the 1664 latter, or, 1666 o The user identity could be asserted to the Focus, via 1667 [I-D.ietf-sip-identity] mechanisms, and/or, 1669 o the SAML assertion could provide additional user profile 1670 information such as group membership (belongs to the students, 1671 staff, faculty group of university X). This could, for non- 1672 identity-based authorization systems, imply certain rights. 1674 The corresponding SIP message flow (in high level detail) could have 1675 the following shape: 1677 +-----+ +-----------+ +-----------+ 1678 | | | SIP Proxy | | Focus | 1679 |User | |(Asserting | | (Relying | 1680 | | | party) | | party) | 1681 +--+--+ +-----+-----+ +-----+-----+ 1682 | INVITE | | 1683 |sip:conf-factory | INVITE | 1684 |------------------>| w/Identity hdr | 1685 | |------------------>| 1686 | | | 1687 | | HTTP GET SAML assn| 1688 | |<==================| 1689 | | and domain cert | 1690 | | | 1691 | | HTTP 200 OK + assn| 1692 | |==================>| 1693 | | and domain cert | 1694 | | | 1695 | | | 1696 | | Ringing | 1697 | Ringing |<------------------| 1698 |<------------------| | 1699 | | | 1700 | | OK | 1701 | OK |<------------------| 1702 |<------------------| | 1703 | | | 1704 | ACK | | 1705 |------------------>| ACK | 1706 | |------------------>| 1707 | | | 1708 | | | 1709 ... many more msgs... 1711 Figure 21: SIP Conferencing and SAML 1713 However, there are obvious scaling issues with the conference server 1714 having to do the outbound requests in order to obtain SAML assertions 1715 and certificates for conference participants. 1717 This could be addressed by creating another SIP SAML Profile where 1718 the caller obtains the necessary information, e.g., SAML assertions, 1719 and places them into its SIP request message prior to sending it. 1720 This would obviate the need for the callee relying party to make 1721 requests in order to obtain said information. This is a topic for 1722 future work, and possibly future revisions of this specification. 1724 A.3. Compensation using SIP and SAML 1726 This section describes a scenario where SAML is used in SIP to 1727 realize compensation functionality as described in 1728 [I-D.jennings-sipping-pay]. 1730 Note that this scenario is not directly addressed by the SIP SAML 1731 Profile and SAML SIP Binding presently defined in this specification. 1732 Rather, this use case calls for additional such profiles and bindings 1733 to be developed. 1735 +--------+ +--------+ +--------+ 1736 |Payment | | User | |Merchant| 1737 |Provider| | Alice | |Bob | 1738 | | | | | | 1739 | | | | | | 1740 +---+----+ +---+----+ +---+----+ 1741 | | | 1742 | | 1) Call | 1743 | |------------------------>| 1744 | | | 1745 | | 2) 402 + Payment Offer | 1746 | 3) Request for |<------------------------| 1747 | a Payment | | 1748 |<----------------------| | 1749 | | | 1750 | 4) SAML Assertion | | 1751 | (=Receipt) | | 1752 |---------------------->| | 1753 | | 5) Call + Receipt | 1754 | |------------------------>| 1755 | | | 1756 | | 6) 200 OK | 1757 | |<------------------------| 1758 | | | 1759 Figure 22: Message flow for SIP payment 1761 User Alice and the Merchant Bob interact with each other using SIP 1762 and the Alice uses HTTP to exchange messages with a Payment Provider. 1763 Initially, Alice makes a call to Bob (1). Bob determines that a 1764 payment is required and includes information about the payment in an 1765 Offer body of a 402 (Payment Required) response to Alice (2). Alice 1766 looks at this Offer and decides to make a payment. Alice therefore 1767 instructs her Payment Provider to make a transfer from Alice"s 1768 account to the Merchants"s account (3) using a request for a SAML 1769 assertion with the extensions defined in this document. The Payment 1770 Provider returns a receipt for this transfer (4). This receipt is a 1771 SAML Assertion. Alice resubmits the call to Bob but this time 1772 provides the Receipt for the transaction (5). Bob determines whether 1773 the Receipt is valid (by checking the digital signature and the 1774 content of the assertion) and continues with the call processing, if 1775 the authorization was succesful. 1777 The Offer contains information about the participating parties (i.e., 1778 the Payment Provider, the Merchant Bob, and the user Alice), the 1779 transaction amount, the account identifier for Bob at the Payment 1780 Provider, and a replay protection indicator to make it easier for the 1781 Merchant Bob to avoid replay attacks. User Alice includes this 1782 information when making the Request for Payment to the Payment 1783 Provider; adds its own account information and authorization 1784 password; and sends this to the Payment Provider, which produces a 1785 Receipt for the transaction if it is successful. This transfer from 1786 Alice to the Payment Provider is made across an encrypted, integrity 1787 protected channel. The Receipt includes a timestamp when the Payment 1788 Provider made the transaction and protects the Receipt with a digital 1789 signature. Alice resubmits the call to the Merchant Bob with the 1790 Receipt from the Payment Provier. Merchant Bob can check for replay 1791 attacks using the timestamp and a replay protection indiciator 1792 initially provided with the Offer. Bob can then check the signature 1793 is valid using the Payment Provider"s public key. 1795 Authors' Addresses 1797 Hannes Tschofenig 1798 Siemens Networks GmbH & Co KG 1799 Otto-Hahn-Ring 6 1800 Munich, Bavaria 81739 1801 Germany 1803 Email: Hannes.Tschofenig@siemens.com 1805 Jeff Hodges 1806 NeuStar, Inc. 1807 2000 Broadway Street 1808 Redwood City, CA 94063 1809 US 1811 Email: Jeff.Hodges@neustar.biz 1813 Jon Peterson 1814 NeuStar, Inc. 1815 1800 Sutter St Suite 570 1816 Concord, CA 94520 1817 US 1819 Email: jon.peterson@neustar.biz 1821 James Polk 1822 Cisco 1823 2200 East President George Bush Turnpike 1824 Richardson, Texas 75082 1825 US 1827 Email: jmpolk@cisco.com 1829 Douglas C. Sicker 1830 University of Colorado at Boulder 1831 ECOT 430 1832 Boulder, CO 80309 1833 US 1835 Email: douglas.sicker@colorado.edu 1837 Full Copyright Statement 1839 Copyright (C) The Internet Society (2006). 1841 This document is subject to the rights, licenses and restrictions 1842 contained in BCP 78, and except as set forth therein, the authors 1843 retain all their rights. 1845 This document and the information contained herein are provided on an 1846 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1847 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1848 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1849 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1850 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1851 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1853 Intellectual Property 1855 The IETF takes no position regarding the validity or scope of any 1856 Intellectual Property Rights or other rights that might be claimed to 1857 pertain to the implementation or use of the technology described in 1858 this document or the extent to which any license under such rights 1859 might or might not be available; nor does it represent that it has 1860 made any independent effort to identify any such rights. Information 1861 on the procedures with respect to rights in RFC documents can be 1862 found in BCP 78 and BCP 79. 1864 Copies of IPR disclosures made to the IETF Secretariat and any 1865 assurances of licenses to be made available, or the result of an 1866 attempt made to obtain a general license or permission for the use of 1867 such proprietary rights by implementers or users of this 1868 specification can be obtained from the IETF on-line IPR repository at 1869 http://www.ietf.org/ipr. 1871 The IETF invites any interested party to bring to its attention any 1872 copyrights, patents or patent applications, or other proprietary 1873 rights that may cover technology that may be required to implement 1874 this standard. Please address the information to the IETF at 1875 ietf-ipr@ietf.org. 1877 Acknowledgment 1879 Funding for the RFC Editor function is provided by the IETF 1880 Administrative Support Activity (IASA).