idnits 2.17.00 (12 Aug 2021) /tmp/idnits28175/draft-ietf-sip-saml-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 259 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 (March 8, 2010) is 4457 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2392' is defined on line 1392, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1413, but no explicit reference was found in the text == Unused Reference: 'RFC3553' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1491, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1503, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Experimental J. Hodges 5 Expires: September 9, 2010 6 J. Peterson 7 NeuStar, Inc. 8 J. Polk 9 Cisco 10 D. Sicker 11 CU Boulder 12 March 8, 2010 14 SIP SAML Profile and Binding 15 draft-ietf-sip-saml-07.txt 17 Abstract 19 This document specifies a Session Initiation Protocol (SIP) profile 20 of Security Assertion Markup Language (SAML) as well as a SAML SIP 21 binding. The defined SIP SAML Profile composes with the mechanisms 22 defined in the SIP Identity specification and satisfy requirements 23 presented in "Trait-based Authorization Requirements for the Session 24 Initiation Protocol (SIP)". 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 9, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 70 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 71 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 72 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 73 6. URI Parameter Definition . . . . . . . . . . . . . . . . . . . 14 74 7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 15 75 7.1. AS-driven SIP SAML URI-based Attribute Assertion 76 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 15 77 7.1.1. Required Information . . . . . . . . . . . . . . . . . 15 78 7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 16 79 7.1.3. Profile Description . . . . . . . . . . . . . . . . . 19 80 7.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 22 81 8. Assertion Profile . . . . . . . . . . . . . . . . . . . . . . 23 82 8.1. Assertion Profile Description . . . . . . . . . . . . . . 23 83 8.1.1. Element: . . . . . . . . . . . . . . . . . 23 84 8.2. Assertion Verification . . . . . . . . . . . . . . . . . . 25 85 9. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 27 86 9.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 27 87 10. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 28 88 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 89 11.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 33 90 11.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 11.3. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 34 92 11.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 35 93 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 94 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 95 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 96 14.1. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 38 97 14.2. 477 'Binding to SIP Message failed' Response Code . . . . 38 98 14.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 38 99 14.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 39 100 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 101 15.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 40 102 15.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 40 103 15.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 40 104 15.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40 105 15.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40 106 15.6. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 41 107 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 108 16.1. Normative References . . . . . . . . . . . . . . . . . . . 42 109 16.2. Informative References . . . . . . . . . . . . . . . . . . 43 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 112 1. Introduction 114 This document specifies composition of the Security Assertion Markup 115 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 116 richer authorization mechanisms and enable "trait-based 117 authorization". Trait-based authorization is where one is authorized 118 to make use of some resource based on roles or traits rather than 119 ones identity. Motivations for trait-based authorization, along with 120 use-case scenarios, are presented in [RFC4484]. 122 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 123 based framework for creating and exchanging security information. 124 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 125 [OASIS.sstc-saml-tech-overview-2.0-draft-16] provide non-normative 126 overviews of SAMLv2. The SAMLv2 specification set is normatively 127 defined by [OASIS.saml-conformance-2.0-os]. 129 Various means for encoding authorization information exists, such as 130 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 131 to the authenticated identity body [RFC3893]. This document focuses 132 on an encoding of the authorization information using SAML assertions 133 but does not exclude other formats to be used utilized in the future. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 The SIP network element "Authentication Service" is introduced in 142 [RFC4474]. We reuse this term to refer to a network element that 143 authenticates and authorizes a user and creates a "SIP identity 144 assertion". This system entity is the logical equivalent of a "SAML 145 Authority" in the SAML terminology. 147 For overall SIP terminology, see [RFC3261]. 149 In this specification, the term, or term component, "SAML" refers to 150 SAML V2.0 in all cases. For example, the term "SAML assertion" 151 implicitly means "SAMLv2 assertion". For overall SAML terminology, 152 see [OASIS.saml-glossary-2.0-os]. 154 The below list maps other various SIP terms to their SAML 155 (rough-)equivalents: 157 Element, Network Element: 159 System Entity, Entity 161 Authentication Service: 163 SAML Authority 165 Invitee, Invited User, Called Party, Callee: 167 Relying Party 169 Server, User Agent Server (UAS): 171 SAML Responder 173 User Agent Client (UAC), client: 175 SAML Requester 177 Additional terms defined in the context of this specification: 179 profile attribute(s): 181 one or more attributes of a "user profile". 183 user profile, subject profile: 185 the set of various attributes accompanying (i.e., mapped to) a 186 user account in many environments. 188 3. SAML Introduction 190 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 191 [OASIS.sstc-saml-tech-overview-2.0-draft-16] defines an XML-based 192 framework for exchanging "security assertions" between entities. In 193 the course of making, or relying upon such assertions, SAML system 194 entities may use SAML protocols, or other protocols, to communicate 195 an assertion itself, or the subject of an assertion. 197 Thus one can employ SAML to make and encode statements such as "Alice 198 has these profile attributes and her domain's certificate is 199 available over there, and I'm making this statement, and here's who I 200 am." Then one can cause such an assertion to be conveyed to some 201 party who can then rely on it in some fashion for some purpose, for 202 example input it into some local policy evaluation for access to some 203 resource. This is done in a particular "context of use". Such a 204 context of use could be, for example, deciding whether to accept and 205 act upon a SIP-based invitation to initiate a communication session. 207 The specification of how SAML is employed in a particular context of 208 use is known as a "SAML profile". The specification of how SAML 209 assertions and/or protocol messages are conveyed in, or over, another 210 protocol is known as a "SAML Binding". Typically, a SAML profile 211 specifies the SAML bindings that may be used in its context. Both 212 SAML profiles and SAML bindings reference other SAML specifications, 213 especially the SAML Assertions and Protocols, aka "SAML Core", 214 specification [OASIS.saml-core-2.0-os]. 216 There is an additional subtle aspect of SAML profiles that is worth 217 highlighting -- the notion of a "SAML assertion profile". A SAML 218 assertion profile is the specification of the assertion contents in 219 the context of a particular SAML profile. It is possibly further 220 qualified by a particular implementation and/or deployment context. 221 Condensed examples of SAML assertion profiles are: 223 o The SAML assertion must contain at least one authentication 224 statement and no other statements. The relying party must be 225 represented in the element. The 226 SubjectConfirmation Method must be Foo. etc. 228 o The SAML assertion must contain at least one attribute statement 229 and may contain more than one. The values for the subject's 230 profile attributes named "Foo" and "Bar" must be present. An 231 authentication statement may be present. etc. 233 The primary facets of SAML itself are: 235 o Assertions 237 o Abstract Request/Response protocol 239 We describe each in turn below: 241 3.1. SAML Assertions 243 A SAML assertion is a package of information including issuer and 244 subject, conditions and advice, and/or attribute statements, and/or 245 authentication statements and/or other statements. Statements may or 246 may not be present. The SAML assertion "container" itself contains 247 the following information: 249 Issuing information: 251 Who issued the assertion, when was it issued and the assertion 252 identifier. 254 Subject information: 256 The name of the subject, the security domain and optional subject 257 information, like public key. 259 Conditions under which the assertion is valid: 261 Special kind of conditions like assertion validity period, 262 audience restriction and target restriction. 264 Additional advice: 266 Explaining how the assertion was made, for example. 268 In terms of SAML assertions containing SAML attribute statements or 269 SAML authentication statements, here are explanatory examples: 271 With a SAML assertion containing a SAML attribute statement, an 272 issuing authority is asserting that the subject is associated with 273 certain attributes with certain subject profile attribute values. 274 For example, user jon@cs.example.com is associated with the 275 attribute "Department", which has the value "Computer Science". 277 With a SAML assertion containing a SAML authentication statement, 278 an issuing authority is asserting that the subject was 279 authenticated by certain means at a certain time. 281 With a SAML assertion containing both a SAML attribute statement 282 and a SAML authentication statement, an issuing authority is 283 asserting the union of the above. 285 3.2. Abstract Request/Response Protocol 287 SAML defines an abstract request/response protocol for obtaining 288 assertions. See Section 3 "SAML Protocols" of 289 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 290 response returns the requested assertion or an error. This abstract 291 protocol may then be cast into particular contexts of use by binding 292 it to specific underlying protocols, e.g., HTTP or SIP, and 293 "profiling" it for the specific use case at hand. The SAML HTTP- 294 based web single sign-on profile is one such example (see Section 4.1 295 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 296 based SIP communication session establishment, the topic of this 297 specification, is another. 299 4. Specification Scope 301 The scope of this specification is: 303 o Specify a SIP profile of SAML -- also known as a "SIP SAML 304 profile" -- such that a subject's profile attributes, and their 305 domain's certificate, can be conveyed to a relying party using 306 SAML. In doing so, satisfy the requirements outlined in 307 [RFC4484], and compose with [RFC4474]. 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 [RFC4484]. 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 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 SIP SAML Profiles defined in this document make use of concepts 360 defined by [RFC4474] "Enhancements for Authenticated Identity 361 Management in the Session Initiation Protocol (SIP)" -- also known as 362 "SIP Identity". SIP Identity allows the SIP UA client and an entity 363 on behalf of the UA client to attach a SAML assertion (or a reference 364 to it). Since intermediaries, like an outbound SIP proxy, are not 365 allowed to modify the body of a SIP message such an intermediary 366 would attach a pointer to the assertion instead. 368 The specific details on how the SAML assertion is requested are 369 outside the scope of this document. Possible mechanisms are to use a 370 software library that can be accessed via an API, a separate 371 authorization server that can be queried via HTTP (as envisioned the 372 'OAuth Web Resource Authorization Profiles' specification 373 [I-D.hardt-oauth]), or any other mechanism. As such, this document 374 does not further describe the functional split between the party that 375 attaches the SAML assertion to the SIP message and the party that 376 creates the SAML assertion. The SIP Identity specification calls the 377 party that makes identity assertions about the caller "Authentication 378 Service (AS)". Such an Authentication Service, which likely has 379 access to various pieces of information concerning the calling party, 380 could also act as a SAML Authority, and make such information 381 available to the callee via SAML. This document uses the term SAML 382 Authority and Authentication Service interchangable particularly 383 because of the fact that the entity that attaches the SAML assertion 384 to the SIP message also uses the SIP Identity mechanism to bind it to 385 the message. 387 Note that technically there is a difference between attaching a 388 reference to a SAML assertion and attaching a SAML assertion to the 389 body of a message. We define two different profiles to cover these 390 two cases: 392 AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile: 394 In case of this profile the AS attaches a reference to a SAML 395 assertion to the SIP message and makes it available to the 396 verifier. More details about this profile can be found in 397 Section 7.1. 399 Assertion-by-Value Profile: 401 In case of this profile the SAML assertion is made available to 402 the verifying party directly without the additional step of 403 utilizing a reference. This approach is described in Section 7.2. 405 6. URI Parameter Definition 407 This document represents the URL pointing to the authorization 408 information using a URI parameter. The grammar for this parameter is 409 (following the ABNF [RFC4234] in Section 25 of RFC 3261 [RFC3261]): 411 token-info = 412 "token-info" HCOLON ident-info *( SEMI ident-info-params ) 414 ident-info = LAQUOT absoluteURI RAQUOT 416 ident-info-params = generic-param 418 Figure 1: 'token-info' ABNF Grammar 420 The "absoluteURI" MUST contain a URI which dereferences to a resource 421 containing a SAML assertion. All implementations of this 422 specification MUST support the use of HTTP and HTTPS URIs. Such HTTP 423 and HTTPS URIs MUST follow the conventions of RFC 2585 [RFC2585], and 424 for those URIs the indicated resource MUST be of the form 425 'application/samlassertion+xml' described in that specification. 427 An example of the syntax of the "token-info" parameter is given 428 below: 430 From: ; 432 tag=1928301774 434 7. SIP SAML Profiles 436 This section defines two "SIP SAML profiles": 438 o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 439 Profile" 441 o The "Assertion-by-Value" Profile 443 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 445 7.1.1. Required Information 447 The information given in this section is similar to the info provided 448 when registering something, a MIME Media Type, say, with IANA. In 449 this case, it is for registering this profile with the OASIS SSTC. 450 See Section 2 "Specification of Additional Profiles" in 451 [OASIS.saml-profiles-2.0-os]. 453 Identification: 455 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 457 Contact Information: 459 Hannes Tschofenig (Hannes.Tschofenig@nsn.com) 461 SAML Confirmation Method Identifiers: 463 The SAML V2.0 confirmation method identifier is used in this 464 profile. 466 Description: 468 Given below. 470 Updates: 472 None. 474 7.1.2. Profile Overview 476 Figure 2 illustrates this profile's overall protocol flow. The 477 following steps correspond to the labeled interactions in the figure. 478 Within an individual step, there may be one or more actual message 479 exchanges depending upon the protocol binding employed for that 480 particular step and other implementation-dependent behavior. 482 Although this profile is overview is cast in terms of a SIP INVITE 483 transaction, the reader should note that the mechanism specified 484 herein, may be applied to any SIP request message. 486 Figure 2 begins on the next page. 488 +------------------+ +------------------+ +-----------------+ 489 | Caller | |Authn Service (AS)| | Callee | 490 |Alice@example.com | | @example.com | | Bob@example2.com| 491 +--------+---------+ +--------+---------+ +--------+--------+ 492 - - | | | (steps) 493 ^ ^ | INVITE | | 494 | | |---------------------->| | (1a) 495 | | From:alice@foo.com | | 496 | C | To:sip:bob@example.com| | 497 | S | | | 498 | e | 407 Proxy auth. req. | | 499 | q |<----------------------| | (1b) 500 | = | Challenge | | 501 | N | | | 502 | | ACK | | 503 | | |---------------------->| | (1c) 504 | V | | | 505 | - | | | 506 ^ | INVITE + authorization| | 507 D | | header w/ creds | | 508 | |---------------------->| | (2) 509 I | | From:alice@foo.com | | 510 | | To:sip:bob@example.com| | 511 A | Proxy-Authorization:..| | 512 C | | INVITE | 513 L S | |--------------------->| (3) 514 e | | From:alice@foo.com | 515 O q | | To:sip:bob@example2.com 516 | | | 517 G = | | token-info: | 518 | | https://example.com| 519 | N | | /assns/?ID=abcde | 520 | | | | 521 | + | |URI resolution (eg. HTTP) 522 | | |<=====================| (4) 523 | 1 | | GET /assns/?ID=abcde | 524 | | | | 525 | | | | HTTP/1.1 200 OK | 526 | | | |=====================>| (5) 527 | | | | | 528 | | | | | 529 | | | | | 530 | | | | Alice@example.com 531 | | | | 532 | | | | 533 | | | | ... 534 | | | | 535 | | | | foo=bar | 536 | | | 200 OK | | 537 | V |<----------------------+----------------------| (6) 538 . - | | | 539 V 541 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 542 Transaction 544 Step 1. Initial SIP Transaction between Caller and AS 546 This optional initial step is comprised of substeps 1a, 1b, 547 and 1c in Figure 2. In this step, the caller, Alice, sends 548 a SIP request message, illustrated as an INVITE, indicating 549 Bob as the callee (1a), is subsequently challenged by the AS 550 (1b), and sends an ACK in response to the challenge (1c). 551 The latter message signals the completion of this SIP 552 transaction (which is an optional substep of this profile). 554 Step 2. Caller sends SIP Request Message with Authorization 555 Credentials to the AS 557 Alice then sends an INVITE message in response to the 558 challenge, or uses cached credentials for the domain if step 559 1 was skipped, as specified in [RFC4474] and [RFC3261]. 560 Depending on the chosen SIP security mechanism for client 561 authentication either digest authentication, client side 562 authentication of Transport Layer Security, or a combination 563 of both is used to provide the AS with a strong assurance 564 about the identity of Alice. 566 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 568 First, the AS authorizes the received INVITE message as 569 specified in [RFC4474] and [RFC3261]. If the authorization 570 is successful, the AS constructs and caches a SAML assertion 571 asserting Alice's profile attributes required by Bob's 572 domain (example2.com), and also containing a the domain's 573 (example.com) public key certificate, or a reference to it. 574 The AS constructs a HTTP-based SAML URI Reference 575 incorporating the assertion's Assertion ID (see Section 576 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI 577 and puts the value into the token-info parameter. 579 The AS determines which profile attributes (if any) to 580 assert in the via local configuration 581 and/or obtaining example2.com's metadata 582 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 583 INVITE message to Bob. 585 Step 4. Callee Dereferences HTTP-based SAML URI Reference 587 Bob's UAC or SIP Proxy receives the message and begins 588 verifying it per the "Verifier Behavior" specified in 589 [RFC4474]. In order to accomplish this task, it needs to 590 obtain Alice's domain certificate. It obtains the HTTP- 591 based SAML URI reference from the message's token-info 592 parameter and dereferences it per Section 9.1. Note that 593 this is not a SIP message, but an HTTP message [RFC2616]. 595 Step 5. AS Returns SAML Assertion 597 Upon receipt of the above HTTP request, which contains an 598 embedded reference to Alice's SAML Assertion, Alice's AS 599 returns her assertion in an HTTP response message. 601 Upon receipt of Alice's SAML Assertion, the AS continues its 602 verification of the INVITE message. If successful, it 603 returns a 200 OK message directly to Alice. Otherwise it 604 returns an appropriate SIP error response. 606 Step 6. Callee Returns SIP 200 OK to Caller 608 If Bob determines, based upon Alice's identity as asserted 609 by the AS, and as further substantiated by the information 610 in the SAML assertion, to accept the INVITE, he returns a 611 SIP 200 OK message directly to Alice. 613 7.1.3. Profile Description 615 The following sections provide detailed definitions of the individual 616 profile steps. The relevant illustration is Figure 3, below. Note 617 that this profile is agnostic to the specific SIP request, and also 618 that the Sender and Authentication Service (AS) may be seperate or 619 co-located in actuality. 621 +------------------+ +------------------+ +------------------+ 622 | Sender | |Authn Service (AS)| | Verifier | 623 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 624 +--------+---------+ +--------+---------+ +--------+---------+ 625 | | | (steps) 626 | SIP Request | | 627 |---------------------->| | (1a) 628 | | | 629 | 407 Proxy auth. req. | | 630 |<----------------------| | (1b) 631 | Challenge | | 632 | | | 633 | ACK | | 634 |---------------------->| | (1c) 635 | | | 636 | | | 637 |SIP Req + authorization| | 638 | header w/ creds | | 639 |---------------------->| | (2) 640 | | | 641 | | | 642 | | SIP Req + token-info | 643 | |--------------------->| (3) 644 | | | 645 | | URI resolution | 646 | |<=====================| (4) 647 | | (via HTTP) | 648 | | | 649 | | HTTP/1.1 200 OK | 650 | |=====================>| (5) 651 | | | 652 | | | 653 | | ? | (6) 654 | | | 656 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 658 7.1.3.1. Initial SIP Transaction between Sender and AS 660 This optional step maps to Steps 1 and 2 of Section 5 "Authentication 661 Service Behavior" of [RFC4474]. If the SIP request sent by the 662 caller in substep 1a is deemed insufficiently authenticated by the AS 663 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 664 authenticate the sender of the message. The particulars of how this 665 is accomplished depend upon implementation and/or deployment 666 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 667 in Figure 3 are non-normative and illustrative only. 669 7.1.3.2. Sender sends SIP Request Message with Authorization 670 Credentials to the AS 672 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 673 Behavior" of [RFC4474]. This request is presumed to be made in a 674 context such that the AS will not challenge it -- i.e., the AS will 675 consider the sender of the message to be authenticated. If this is 676 not true, then this procedure reverts back to Step 1, above. 678 Otherwise, the AS carries out all other processing of the message as 679 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 680 procedure procedes to the next step below. 682 7.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 684 This first portion of this step maps to Steps 3 and 4 of Section 5 685 "Authentication Service Behavior" of [RFC4474], which the AS MUST 686 perform, although with the following additional substeps: 688 The AS MUST construct a SAML assertion according to the "Assertion 689 Profile Description" specified in Section 8.1 of this 690 specification. 692 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 693 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 695 The AS MUST use the URI constructed in the immediately preceding 696 substep as the value of the token-info parameter that is added to 697 the SIP request message. 699 Upon successful completion of all of the above, the AS forwards the 700 request message. 702 At this point in this step, after perhaps traversing some number of 703 intermediaries, the SIP request message arrives at a SIP network 704 entity performing the "verifier" role. This role and its behavior 705 are specified in Section 6 "Verifier Behavior" of [RFC4474]. The 706 verifier MUST perform the steps enumerated in the aforementioned 707 section, with the following modifications: 709 Step 1 of [RFC4474] Section 6 maps to and is updated by, the 710 following two steps in this procedure. 712 Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this 713 latter portion of this step, and/or the following two steps, as 714 appropriate. 716 7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 718 The verifier SHOULD ascertain whether it has a current cached copy of 719 the SIP message sender's SAML assertion and domain certificate. If 720 not, or if the verifier chooses to (e.g., due to local policy), it 721 MUST dereference the the HTTP-based SAML URI Reference found in the 722 SIP message's token-info parameter. To do so, the verifier MUST 723 employ the "SAML HTTP-URI-based SIP Binding" specified in 724 Section 9.1. 726 7.1.3.5. AS Returns SAML Assertion 728 This step also employs Section 9.1 "SAML HTTP-URI-based SIP Binding". 730 If the prior step returns an HTTP error (e.g., 4xx series), then this 731 procedure terminates and the verifier returns (upstream) a SIP 436 732 'Bad token-info' Response code. 734 Otherwise, the HTTP response message will contain a SAML assertion 735 and be denoted as such via the MIME media type of "application/ 736 samlassertion+xml" [IANA.application.samlassertion-xml]. The 737 verifier MUST perform the verification steps specified in Section 8.2 738 "Assertion Verification", below. If successful, then this procedure 739 continues with the next step. 741 7.1.3.6. Verifier performs Next Step 743 The SIP request was successfully processed. The verifier now 744 performs its next step, which depends at least in part on the type of 745 SIP request it received. 747 7.2. Caller-driven SIP SAML Conveyed Assertion Profile 749 For the "Assertion-by-value" profile we assume that a SAML assertion 750 is obtained out-of-band and attached to the body of the SIP message. 751 Note that any SIP message may be used to convey the SAML assertion 752 even though SIP INVITE may be the most appropriate candiate. The 753 verification step described in Section 8.2 is applicable to this 754 profile as well as the description on the content of the assertion 755 illustrated in Section 8.1. 757 8. Assertion Profile 759 This section provides some guidance on what information should be put 760 into a SAML assertion by the SAML Authority and how that information 761 is then used by the Verifier. 763 8.1. Assertion Profile Description 765 The schema for SAML assertions themselves is defined in Section 2.3 766 of [OASIS.saml-core-2.0-os]. 768 An example SAML assertion, formulated according to this profile is 769 given in Section 10. 771 Overall SAML assertion profile requirements: 773 If a SAML assertion is signed then it MUST be signed by the same 774 key that is used in the Transport Layer Security mechanism 775 utilized with HTTPS. Signing of SAML assertions is defined in 776 Section 5.4 of [OASIS.saml-core-2.0-os]. 778 In the following subsections, the SAML assertion profile is specified 779 element-by-element, in a top-down, depth-first manner, beginning with 780 the outermost element, "". Where applicable, the 781 requirements for an element's XML attributes are also stated, as a 782 part of the element's description. Requirements for any given 783 element or XML attribute are only stated when, in the context of use 784 of this profile, they are not already sufficiently defined by 785 [OASIS.saml-core-2.0-os]. 787 8.1.1. Element: 789 Attribute: ID 791 The value for the ID XML attribute SHOULD be allocated randomly 792 such that the value meets the randomness requirments specified in 793 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 795 Attribute: IssueInstant 797 The value for the IssueInstant XML attribute SHOULD be set at the 798 time the SAML assertion is created (and cached for subsequent 799 retrieval). This time instant value MAY be temporally the same as 800 that encoded in the SIP message's Date header, and MUST be at 801 least temporally later, although it is RECOMMENDED that it not be 802 10 minutes or more later. 804 8.1.1.1. Element: 806 The value for the Issuer XML element MUST be a value that matches 807 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 808 the certificate conveyed by the SAML assertion in the ds: 809 X509Certificate element located on this path within the SAML 810 assertion: 812 820 The element SHOULD contain both a element and a 821 element. 823 The value of the element MUST be the Address of Record 824 (AoR). 826 The element attribute Method SHOULD be set to 827 the value: 829 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 831 Although it MAY be set to some other implementation- and/or 832 deployment-specific value. The element itself 833 SHOULD be empty. 835 8.1.1.3. Element: 837 The element SHOULD contain an 838 element, which itself SHOULD contain an element. When 839 included the value of the element MUST be the same as the 840 addr-spec of the SIP request's To header field. 842 The following XML attributes of the element MUST be set 843 as follows: 845 Attribute: NotBefore 847 The value of the NotBefore XML attribute MUST be set to a time 848 instant the same as the value for the IssueInstant XML attribute 849 discussed above, or to a later time. 851 Attribute: NotOnOrAfter 853 The value of the NotOnOrAfter XML attribute MUST be set to a time 854 instant later than the value for NotBefore. 856 8.1.1.4. Element: 858 The SAML assertion MAY contain an element. If 859 so, the element will contain attribute-value 860 pairs, e.g., of a user profile nature, encoded according to either 861 one of the "SAML Attribute Profiles" as specified in 862 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 863 and/or deployment-specific attribute profile. 865 The attribute-value pairs SHOULD in fact pertain to the entity 866 identified in the SIP From header field, since a SAML assertion 867 formulated per this overall section is stating that they do. 869 8.2. Assertion Verification 871 This section specifies the steps that a verifier has to perform to 872 verify a SAML assertion created according to the profile from 873 Section 8.1.1. 875 The steps are: 877 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 878 extract the AS's domain certificate from the XML element at the end of the element path 880 given in Section 8.1.1.1. 882 2. Perform Step 1 in Section 6 of [RFC4474]. 884 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 885 that section, the verifier MUST verify the SAML assertion's 886 signature via the procedures specified in Section 5.4 of 887 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. The 479 888 'Invalid SAML Assertion' response code is used when the verifier 889 is unable to process the SAML assertion. 891 4. Perform Step 2 in Section 6 of [RFC4474]. 893 5. Verify that the signer of the SIP message's Identity header 894 field is the same as the signer of the SAML assertion, if SIP 895 Identity is used to bind the token-info parameter to the SIP 896 signaling message. Note that without such protection certain 897 attacks are feasible as described in Section 11. 899 6. Verify that the content of the SAML assertion matches with the 900 information carried in the SIP message. This may include the 901 following checks: 903 7. Verify that the SAML assertion's element value matches 904 the Issuer or the Issuer Alternative Name fields [RFC3280] in 905 the AS's domain certificate. 907 8. Verify that the SAML assertion's element value is the 908 same as the Address of Record (AoR) value. 910 9. Verify that the SAML assertion's element 911 value is set to whichever value was configured at 912 implementation- or deployment-time. The default value is: 914 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 916 10. Verify that the SAML assertion contains an element, 917 and that its value matches the value of the addr-spec of the SIP 918 To header field. 920 11. Verify that the validity period denoted by the NotBefore and 921 NotOnOrAfter attributes of the element meets the 922 requirements given in Section 8.1.1.3. 924 9. SAML SIP Binding 926 This section specifies one SAML SIP Binding at this time. Additional 927 bindings may be specified in future revisions of this specification. 928 The description in Section 8.1 is applicable to this profile. 930 9.1. SAML HTTP-URI-based SIP Binding 932 This section specifies the "SAML HTTP-URI-based SIP Binding", 933 (SHUSB). 935 The SHUSB is a profile of the "SAML URI Binding" specified in Section 936 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 937 a means by which SAML assertions can be referenced by URIs and thus 938 be obtained through resolution of such URIs. 940 This profile of the SAML URI Binding is congruent with the SAML URI 941 Binding -- including support for HTTP-based URIs being mandatory to 942 implement -- except for the following further restrictions which are 943 specified in the interest of interoperability (section numbers refer 944 to [OASIS.saml-bindings-2.0-os]): 946 Section 3.7.5.3 Security Considerations: 948 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 950 Section 3.7.5.4 Error Reporting: 952 All SHOULDs in this section are to be interpreted as MUSTs. 954 10. Example SAML Assertions 956 This section presents two examples of a SAML assertion, one unsigned 957 (for clarity), the other signed (for accuracy). 959 In the first example, Figure 4, the assertion is attesting with 960 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 961 The validity conditions are expressed in lines 16-23, via both a 962 validity period expressed as temporal endpoints, and an "audience 963 restriction" stating that this assertion's semantics are valid for 964 only the relying party named "example2.com". Also, the assertion's 965 issuer is noted in lines 4-5. 967 The above items correspond to some aspects of this specification's 968 SAML assertion profile, as noted below in Security Considerations 969 dicussions, see: Section 11.1 and Section 11.3. 971 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 972 fashion, using LDAP/X.500 schema as the typing means. 974 1 977 4 978 5 example.com 979 6 980 7 981 8 984 11 Alice@example.com 985 12 986 13 988 15 989 16 991 18 992 19 993 20 example2.com 994 21 995 22 996 23 997 24 998 25 1005 32 1006 33 +1-888-555-1212 1007 34 1008 35 1009 36 1010 37 1012 Figure 4: Unsigned SAML Assertion Illustrating Conveyance of 1013 Subject Attribute 1015 In the second example, Figure 5, the information described above is 1016 the same, the addition is that this version of the assertion is 1017 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 1019 integrity are assured. Since this assertion is the same as the one 1020 in the first example above, other than having a signature added, the 1021 second example below addresses the same Security Considerations 1022 aspects, plus those requiring a Signature. 1024 1 1027 4 1028 5 example.com 1029 6 1030 7 1031 8 1032 9 1034 11 1036 13 1038 15 1039 16 1042 19 1045 22 1049 26 1050 27 1051 28 1053 30 1054 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1055 32 1056 33 1057 34 1058 35 1059 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1060 37 1061 38 1062 39 1063 40 1064 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1065 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1066 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1067 44 1068 45 1069 46 1070 47 1071 48 1072 49 1075 52 Alice@example.com 1076 53 1077 54 1079 56 1080 57 1082 59 1083 60 1084 61 example2.com 1085 62 1086 63 1087 64 1088 65 1089 66 1096 73 1097 74 +1-888-555-1212 1098 75 1099 76 1100 77 1101 78 1103 Figure 5: Signed SAML Assertion Illustrating Conveyance of Subject 1104 Attribute 1106 11. Security Considerations 1108 This section discusses security considerations when using SAML with 1109 SIP. 1111 11.1. Man-in-the-Middle Attacks and Stolen Assertions 1113 Threat: 1115 By making SAML assertions available via HTTP-based requests by a 1116 potentially unbounded set of requesters, it is conceivably 1117 possible that anyone would be able to simply request one and 1118 obtain it. By SIP intermediaries on the signaling path for 1119 example. Or, an HTTP intermediary/proxy could intercept the 1120 assertion as it is being returned to a requester. 1122 The attacker could then attempt to utilize the SAML assertion in 1123 another exchange in order to impersonate the subject (the putative 1124 caller) to some SIP-based target entity. 1126 Countermeasures: 1128 Such an attack is implausible for several reasons. The primary 1129 reason is that a message constructed by an imposter using a stolen 1130 assertion that conveys the public key certificate of some domain 1131 will not verify because the values in the SAML assertion, which 1132 are tied to the SIP message, will not verify. 1134 Furthermore, the SIP SAML assertion may contain restrictions 1135 regarding the parties it can be used by. Finally, the assertion 1136 should be signed and thus causing any alterations to break its 1137 integrity and make such alterations detectable. 1139 11.2. Privacy 1141 Threat: 1143 The ability for other entities to obtain additional information 1144 about an individual, such as role in an organization or other 1145 authorization relevant information raises privacy concerns. 1147 Since the SAML assertion itself is not confidentiality protected 1148 nor the exchange of the reference to the SAML assertion an 1149 intermediary or a third party adversary would be allowed to gain 1150 additional information about an individual 1152 Countermeasures: 1154 To address the threats three cases need to be differentiated. 1156 First, a third party that did not participate in any of the 1157 exchange is prevented from eavesdropping on the content of the 1158 SAML assertion by employing confidentiality protection of the SIP 1159 signaling exchange as well as the HTTP exchange. This ensures 1160 that an eavesdropper on the wire is unable to obtain information. 1161 However, this does not prevent intermediaries, such as SIP proxies 1162 from observing a URL to a SAML assertion (in the token-info 1163 parameter). To deal with this second type of attacker depending 1164 on the environment where such a threat must be addressed it is 1165 necessary to authenticate the entity that tries to resolve the 1166 reference to a SAML assertion and to only provide a positive 1167 response (with the SAML assertion) if the requestor is authorized 1168 to obtain the desired information. When a SAML assertion is 1169 carried inband then such a protection is more difficult to 1170 accomplish as the SAML assertion would have to be confidentiality 1171 protected with the key of the intented recipient, for example 1172 using S/MIME. Finally, the last type of threat concerns the 1173 intented recipient of the SAML assertion itself. Proper 1174 permissions for the distribution of information about the caller 1175 via the content of the SAML assertion to certain recipients need 1176 to be available. This permission must be provided by the caller 1177 itself or, in certain circumstances, by someone on behalf of the 1178 caller. From a technical point of view, some form of 1179 authorization policies will be required. 1181 11.3. Forged Assertion 1183 Threat: 1185 A malicious user could forge or alter a SAML assertion in order to 1186 communicate with the SIP entities. 1188 Countermeasures: 1190 To avoid this kind of attack, the entities must assure that proper 1191 mechanisms for protecting the SAML assertion are employed, e.g., 1192 signing the SAML assertion itself or protecting the transport of 1193 the SAML assertion from the AS to the verifying party using TLS. 1194 Section 5.1 of [OASIS.saml-core-2.0-os] specifies the signing of 1195 SAML assertions. 1197 Additionally, the assertion content dictated by the SAML assertion 1198 profile herein ensures ample evidence for a relying party to 1199 verify the assertion and its relationship with the received SIP 1200 request. 1202 11.4. Replay Attack 1204 Threat: 1206 Theft of SIP message protected by the mechanisms described herein 1207 and replay of it at a later time. 1209 Countermeasures: 1211 The SAML assertion may contain several elements to prevent replay 1212 attacks. There is, however, a clear tradeoff between the 1213 replaying an assertion and re-using it over multiple SIP 1214 exchanges/sessions. 1216 Additionally, the SAML assertion can be tied to the SIP exchange 1217 with the help of the SIP Identity mechanism. RFC 4474 [RFC4474] 1218 signs certain header fields and the SIP message body and thereby 1219 helps to protect message modifications. If a recipient knows that 1220 all messages from a certain originator arrive with SIP Identity 1221 protection applies then downgrading attacks are not possible. 1223 12. Contributors 1225 The authors would like to thank Marcus Tegnander and Henning 1226 Schulzrinne for his contributions to earlier versions of this 1227 document. 1229 13. Acknowledgments 1231 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1232 Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki 1233 Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen 1234 Fries and Vijay Gurbani for their comments to this draft. 1236 The "AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile" 1237 is based on an idea by Jon Peterson. 1239 14. IANA Considerations 1241 When a SAML assertion is attached to the body of the message then the 1242 "application/samlassertion+xml" MIME media type is used. This MIME 1243 type is already registered with IANA and no further action is 1244 required from IANA. 1246 14.1. URI Parameter 1248 This document extends the registry of URI parameters, as defined RFC 1249 3969 [RFC3969] with the following value: 1251 Parameter Name: token-info 1253 Predefined Values: No 1255 Reference: This document 1257 14.2. 477 'Binding to SIP Message failed' Response Code 1259 This document registers a new SIP response code. It is sent when a 1260 verifier receives a SAML assertion but the Subject and Condition 1261 elements cannot be matched to the content in the SIP message, i.e., 1262 the binding between the SIP message and the SAML assertion cannot be 1263 accomplished. This response code is defined by the following 1264 information, which has been added to the method and response-code 1265 sub-registry under http://www.iana.org/assignments/sip-parameters. 1267 Response Code Number: 477 1269 Default Reason Phrase: Binding to SIP Message failed 1271 14.3. 478 'Unknown SAML Assertion Content' Response Code 1273 This document registers a new SIP response code. It is used when the 1274 verifier is unable to parse the content of the SAML assertion, 1275 because, for example, the assertion contains only unknown elements in 1276 in the SAML assertion, or the SAML assertion XML document is garbled. 1277 This response code is defined by the following information, which has 1278 been added to the method and response-code sub-registry under 1279 http://www.iana.org/assignments/sip-parameters. 1281 Response Code Number: 478 1283 Default Reason Phrase: Unknown SAML Assertion Content 1285 14.4. 479 'Invalid SAML Assertion' Response Code 1287 This document registers a new SIP response code. It is used when the 1288 verifier is unable to process the SAML assertion. A verifier may be 1289 unable to process the SAML assertion in case the assertion is self- 1290 signed, or signed by a root certificate authority for whom the 1291 verifier does not possess a root certificate. This response code is 1292 defined by the following information, which has been added to the 1293 method and response-code sub-registry under 1294 http://www.iana.org/assignments/sip-parameters. 1296 Response Code Number: 479 1298 Default Reason Phrase: Invalid SAML Assertion 1300 15. Change Log 1302 RFC Editor - Please remove this section before publication. 1304 15.1. -06 to -07 1306 Undo changes made in version 6. 1308 Removed the header fields and switched to a URI parameter 1310 Editorial changes 1312 15.2. -05 to -06 1314 Defined a new SIP Identity signature mechanism. 1316 15.3. -04 to -05 1318 Changed the document type to experimental 1320 Removed option tag 1322 Added the Caller-driven SIP SAML Conveyed Assertion Profile 1324 Defined a new header (SAML-Info) 1326 Changed the description for usage with this new header 1328 Updated security considerations 1330 Minor editorial cleanups 1332 15.4. -03 to -04 1334 Updated IANA consideration section. 1336 Added option tag 1338 Updated acknowledgments section 1340 Minor editorial changes to the security considerations section 1342 15.5. -02 to -03 1344 Denoted that this I-D is intended to update RFC4474 per SIP working 1345 group consensus at IETF-69. This is the tact adopted in order to 1346 address the impedance mismatch between the nature of the URIs 1347 specified as to be placed in the Identity-Info header field, and what 1348 is specified in RFC4474 as the allowable value of that header field. 1350 Added placeholder "TBD" section for a to-be-determined "call-by- 1351 value" profile, per SIP working group consensus at IETF-69. 1353 Removed use-case appendicies (per recollection of JHodges during 1354 IETF-69 discussion as being WG consensus, but such is not noted in 1355 the minutes). 1357 15.6. -00 to -02 1359 Initial specifications to kickstart the work. 1361 16. References 1363 16.1. Normative References 1365 [OASIS.saml-bindings-2.0-os] 1366 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1367 Maler, "Bindings for the OASIS Security Assertion Markup 1368 Language (SAML) V2.0", OASIS 1369 Standard saml-bindings-2.0-os, March 2005. 1371 [OASIS.saml-core-2.0-os] 1372 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1373 "Assertions and Protocol for the OASIS Security Assertion 1374 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1375 2.0-os, March 2005. 1377 [OASIS.saml-metadata-2.0-os] 1378 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1379 "Metadata for the Security Assertion Markup Language 1380 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1381 March 2005. 1383 [OASIS.saml-profiles-2.0-os] 1384 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1385 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1386 Security Assertion Markup Language (SAML) V2.0", OASIS 1387 Standard OASIS.saml-profiles-2.0-os, March 2005. 1389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1390 Requirement Levels", BCP 14, RFC 2119, March 1997. 1392 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1393 Locators", RFC 2392, August 1998. 1395 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1396 Infrastructure Operational Protocols: FTP and HTTP", 1397 RFC 2585, May 1999. 1399 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1400 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1401 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1403 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1404 A., Peterson, J., Sparks, R., Handley, M., and E. 1405 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1406 June 2002. 1408 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1409 X.509 Public Key Infrastructure Certificate and 1410 Certificate Revocation List (CRL) Profile", RFC 3280, 1411 April 2002. 1413 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1414 Method", RFC 3515, April 2003. 1416 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1417 IETF URN Sub-namespace for Registered Protocol 1418 Parameters", BCP 73, RFC 3553, June 2003. 1420 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1421 Authenticated Identity Body (AIB) Format", RFC 3893, 1422 September 2004. 1424 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1425 (IANA) Uniform Resource Identifier (URI) Parameter 1426 Registry for the Session Initiation Protocol (SIP)", 1427 BCP 99, RFC 3969, December 2004. 1429 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1430 Specifications: ABNF", RFC 4234, October 2005. 1432 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1433 Authenticated Identity Management in the Session 1434 Initiation Protocol (SIP)", RFC 4474, August 2006. 1436 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1437 "Trait-Based Authorization Requirements for the Session 1438 Initiation Protocol (SIP)", RFC 4484, August 2006. 1440 [W3C.xmldsig-core] 1441 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1442 Syntax and Processing", W3C Recommendation xmldsig-core, 1443 October 2000, . 1445 16.2. Informative References 1447 [I-D.hardt-oauth] 1448 Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web 1449 Resource Authorization Profiles", draft-hardt-oauth-01 1450 (work in progress), January 2010. 1452 [IANA.application.samlassertion-xml] 1453 OASIS Security Services Technical Committee (SSTC), 1454 "application/samlassertion+xml MIME Media Type 1455 Registration", IANA MIME Media Types Registry application/ 1456 samlassertion+xml, December 2004. 1458 [OASIS.saml-conformance-2.0-os] 1459 Mishra, P., Philpott, R., and E. Maler, "Conformance 1460 Requirements for the Security Assertion Markup Language 1461 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1462 March 2005. 1464 [OASIS.saml-glossary-2.0-os] 1465 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1466 Security Assertion Markup Language (SAML) V2.0", OASIS 1467 Standard saml-glossary-2.0-os, March 2005. 1469 [OASIS.saml-sec-consider-2.0-os] 1470 Hirsch, F., Philpott, R., and E. Maler, "Security and 1471 Privacy Considerations for the OASIS Security Markup 1472 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1473 2.0-os, March 2005. 1475 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1476 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1477 OASIS SSTC Committee 1478 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1480 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1481 Cantor, S., "SAML Protocol Extension for Third-Party 1482 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1483 ext-thirdparty-cd-01, March 2006. 1485 [OASIS.sstc-saml-tech-overview-2.0-draft-16] 1486 Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, 1487 P., and T. Scavo, "Security Assertion Markup Language 1488 (SAML) V2.0 Technical Overview", OASIS SSTC Working 1489 Draft sstc-saml-tech-overview-2.0-draft-16, May 2008. 1491 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1492 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1493 March 1999. 1495 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1496 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1497 September 1999. 1499 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1500 Certificate Profile for Authorization", RFC 3281, 1501 April 2002. 1503 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1504 Initiation Protocol (SIP)", RFC 3323, November 2002. 1506 Authors' Addresses 1508 Hannes Tschofenig 1509 Nokia Siemens Networks 1510 Linnoitustie 6 1511 Espoo 02600 1512 Finland 1514 Phone: +358 (50) 4871445 1515 Email: Hannes.Tschofenig@gmx.net 1516 URI: http://www.tschofenig.priv.at 1518 Jeff Hodges 1520 Email: Jeff.Hodges@KingsMountain.com 1522 Jon Peterson 1523 NeuStar, Inc. 1524 1800 Sutter St Suite 570 1525 Concord, CA 94520 1526 US 1528 Email: jon.peterson@neustar.biz 1530 James Polk 1531 Cisco 1532 2200 East President George Bush Turnpike 1533 Richardson, Texas 75082 1534 US 1536 Email: jmpolk@cisco.com 1538 Douglas C. Sicker 1539 University of Colorado at Boulder 1540 ECOT 430 1541 Boulder, CO 80309 1542 US 1544 Email: douglas.sicker@colorado.edu