idnits 2.17.1 draft-ietf-sip-saml-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 253 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 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2392' is defined on line 1389, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1410, but no explicit reference was found in the text == Unused Reference: 'RFC3553' is defined on line 1413, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1500, 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) == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-10 -- 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: 4 errors (**), 0 flaws (~~), 8 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: April 28, 2011 6 J. Peterson 7 NeuStar, Inc. 8 J. Polk 9 Cisco 10 D. Sicker 11 CU Boulder 12 October 25, 2010 14 SIP SAML Profile and Binding 15 draft-ietf-sip-saml-08.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 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). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 28, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 65 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 66 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 67 6. URI Parameter Definition . . . . . . . . . . . . . . . . . . . 14 68 7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 15 69 7.1. AS-driven SIP SAML URI-based Attribute Assertion 70 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 15 71 7.1.1. Required Information . . . . . . . . . . . . . . . . . 15 72 7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 16 73 7.1.3. Profile Description . . . . . . . . . . . . . . . . . 19 74 7.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 22 75 8. Assertion Profile . . . . . . . . . . . . . . . . . . . . . . 23 76 8.1. Assertion Profile Description . . . . . . . . . . . . . . 23 77 8.1.1. Element: . . . . . . . . . . . . . . . . . 23 78 8.2. Assertion Verification . . . . . . . . . . . . . . . . . . 25 79 9. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 27 80 9.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 27 81 10. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 28 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 83 11.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 33 84 11.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 11.3. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 34 86 11.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 35 87 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 88 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 89 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 90 14.1. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 38 91 14.2. 477 'Binding to SIP Message failed' Response Code . . . . 38 92 14.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 38 93 14.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 39 94 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 95 15.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 40 96 15.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 40 97 15.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 40 98 15.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40 99 15.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40 100 15.6. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 41 101 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 102 16.1. Normative References . . . . . . . . . . . . . . . . . . . 42 103 16.2. Informative References . . . . . . . . . . . . . . . . . . 43 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 106 1. Introduction 108 This document specifies composition of the Security Assertion Markup 109 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 110 richer authorization mechanisms and enable "trait-based 111 authorization". Trait-based authorization is where one is authorized 112 to make use of some resource based on roles or traits rather than 113 ones identity. Motivations for trait-based authorization, along with 114 use-case scenarios, are presented in [RFC4484]. 116 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 117 based framework for creating and exchanging security information. 118 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 119 [OASIS.sstc-saml-tech-overview-2.0-draft-16] provide non-normative 120 overviews of SAMLv2. The SAMLv2 specification set is normatively 121 defined by [OASIS.saml-conformance-2.0-os]. 123 Various means for encoding authorization information exists, such as 124 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 125 to the authenticated identity body [RFC3893]. This document focuses 126 on an encoding of the authorization information using SAML assertions 127 but does not exclude other formats to be used utilized in the future. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 The SIP network element "Authentication Service" is introduced in 136 [RFC4474]. We reuse this term to refer to a network element that 137 authenticates and authorizes a user and creates a "SIP identity 138 assertion". This system entity is the logical equivalent of a "SAML 139 Authority" in the SAML terminology. 141 For overall SIP terminology, see [RFC3261]. 143 In this specification, the term, or term component, "SAML" refers to 144 SAML V2.0 in all cases. For example, the term "SAML assertion" 145 implicitly means "SAMLv2 assertion". For overall SAML terminology, 146 see [OASIS.saml-glossary-2.0-os]. 148 The below list maps other various SIP terms to their SAML 149 (rough-)equivalents: 151 Element, Network Element: 153 System Entity, Entity 155 Authentication Service: 157 SAML Authority 159 Invitee, Invited User, Called Party, Callee: 161 Relying Party 163 Server, User Agent Server (UAS): 165 SAML Responder 167 User Agent Client (UAC), client: 169 SAML Requester 171 Additional terms defined in the context of this specification: 173 profile attribute(s): 175 one or more attributes of a "user profile". 177 user profile, subject profile: 179 the set of various attributes accompanying (i.e., mapped to) a 180 user account in many environments. 182 3. SAML Introduction 184 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 185 [OASIS.sstc-saml-tech-overview-2.0-draft-16] defines an XML-based 186 framework for exchanging "security assertions" between entities. In 187 the course of making, or relying upon such assertions, SAML system 188 entities may use SAML protocols, or other protocols, to communicate 189 an assertion itself, or the subject of an assertion. 191 Thus one can employ SAML to make and encode statements such as "Alice 192 has these profile attributes and her domain's certificate is 193 available over there, and I'm making this statement, and here's who I 194 am." Then one can cause such an assertion to be conveyed to some 195 party who can then rely on it in some fashion for some purpose, for 196 example input it into some local policy evaluation for access to some 197 resource. This is done in a particular "context of use". Such a 198 context of use could be, for example, deciding whether to accept and 199 act upon a SIP-based invitation to initiate a communication session. 201 The specification of how SAML is employed in a particular context of 202 use is known as a "SAML profile". The specification of how SAML 203 assertions and/or protocol messages are conveyed in, or over, another 204 protocol is known as a "SAML Binding". Typically, a SAML profile 205 specifies the SAML bindings that may be used in its context. Both 206 SAML profiles and SAML bindings reference other SAML specifications, 207 especially the SAML Assertions and Protocols, aka "SAML Core", 208 specification [OASIS.saml-core-2.0-os]. 210 There is an additional subtle aspect of SAML profiles that is worth 211 highlighting -- the notion of a "SAML assertion profile". A SAML 212 assertion profile is the specification of the assertion contents in 213 the context of a particular SAML profile. It is possibly further 214 qualified by a particular implementation and/or deployment context. 215 Condensed examples of SAML assertion profiles are: 217 o The SAML assertion must contain at least one authentication 218 statement and no other statements. The relying party must be 219 represented in the element. The 220 SubjectConfirmation Method must be Foo. etc. 222 o The SAML assertion must contain at least one attribute statement 223 and may contain more than one. The values for the subject's 224 profile attributes named "Foo" and "Bar" must be present. An 225 authentication statement may be present. etc. 227 The primary facets of SAML itself are: 229 o Assertions 231 o Abstract Request/Response protocol 233 We describe each in turn below: 235 3.1. SAML Assertions 237 A SAML assertion is a package of information including issuer and 238 subject, conditions and advice, and/or attribute statements, and/or 239 authentication statements and/or other statements. Statements may or 240 may not be present. The SAML assertion "container" itself contains 241 the following information: 243 Issuing information: 245 Who issued the assertion, when was it issued and the assertion 246 identifier. 248 Subject information: 250 The name of the subject, the security domain and optional subject 251 information, like public key. 253 Conditions under which the assertion is valid: 255 Special kind of conditions like assertion validity period, 256 audience restriction and target restriction. 258 Additional advice: 260 Explaining how the assertion was made, for example. 262 In terms of SAML assertions containing SAML attribute statements or 263 SAML authentication statements, here are explanatory examples: 265 With a SAML assertion containing a SAML attribute statement, an 266 issuing authority is asserting that the subject is associated with 267 certain attributes with certain subject profile attribute values. 268 For example, user jon@cs.example.com is associated with the 269 attribute "Department", which has the value "Computer Science". 271 With a SAML assertion containing a SAML authentication statement, 272 an issuing authority is asserting that the subject was 273 authenticated by certain means at a certain time. 275 With a SAML assertion containing both a SAML attribute statement 276 and a SAML authentication statement, an issuing authority is 277 asserting the union of the above. 279 3.2. Abstract Request/Response Protocol 281 SAML defines an abstract request/response protocol for obtaining 282 assertions. See Section 3 "SAML Protocols" of 283 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 284 response returns the requested assertion or an error. This abstract 285 protocol may then be cast into particular contexts of use by binding 286 it to specific underlying protocols, e.g., HTTP or SIP, and 287 "profiling" it for the specific use case at hand. The SAML HTTP- 288 based web single sign-on profile is one such example (see Section 4.1 289 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 290 based SIP communication session establishment, the topic of this 291 specification, is another. 293 4. Specification Scope 295 The scope of this specification is: 297 o Specify a SIP profile of SAML -- also known as a "SIP SAML 298 profile" -- such that a subject's profile attributes, and their 299 domain's certificate, can be conveyed to a relying party using 300 SAML. In doing so, satisfy the requirements outlined in 301 [RFC4484], and compose with [RFC4474]. 303 The following are outside the scope of this specification: 305 o Defining a means for configuring the runtime behavior, or 306 deployment characteristics, of the Authentication Service. 308 Discussion: 310 For example, a SIP Authentication Service could be implemented 311 such that its SAML-based features are employed, or not, on a 312 subject-by-subject basis, and/or on a domain-by-domain basis. 314 o The definition of specific conveyed subject profile attributes 315 (aka traits). 317 Discussion: 319 This specification defines a facility enabling "trait-based 320 authorization" as discussed in [RFC4484]. 322 The attributes of interest in trait-based authorization will be 323 ones akin to, for example: roles, organizational membership, 324 access rights, or authentication event context. Definition of 325 such attributes is application- and/or deployment-context- 326 dependent and are not defined in this specification. However, The 327 SAMLv2 specification defines several "SAML Attribute Profiles" for 328 encoding attributes from various application domains, e.g., LDAP, 329 UUID/GUID, DCE PAC, and XACML, in SAML assertions 330 [OASIS.saml-profiles-2.0-os]. 332 In order for any trait-based system to be practical, participating 333 entities must agree on attributes and traits that will be conveyed 334 and subsequently relied upon. Without such agreements, a trait- 335 based system cannot be usefully deployed. This specification does 336 not discuss the manner in which participating entites might 337 discover one another or agree on the syntax and semantics of 338 attributes and traits. 340 Note that SAMLv2 specifies a "metadata" facility that may be 341 useful in addressing this need. 343 5. Employing SAML in SIP 345 Employing SAML in SIP necessitates devising a new SAML profile(s) and 346 binding(s) because those already specified in the SAMLv2 347 specification set are specific to other use contexts, e.g., HTTP- 348 based web browsing. Although SIP bears some similarity to HTTP, it 349 is a seperately distinct protocol, thus requiring specification of 350 SIP-specific SAML profile(s) and binding(s). This is technically 351 straightforward as both SAML and SIP are explicitly extensible. 353 The SIP SAML Profiles defined in this document make use of concepts 354 defined by [RFC4474] "Enhancements for Authenticated Identity 355 Management in the Session Initiation Protocol (SIP)" -- also known as 356 "SIP Identity". SIP Identity allows the SIP UA client and an entity 357 on behalf of the UA client to attach a SAML assertion (or a reference 358 to it). Since intermediaries, like an outbound SIP proxy, are not 359 allowed to modify the body of a SIP message such an intermediary 360 would attach a pointer to the assertion instead. 362 The specific details on how the SAML assertion is requested are 363 outside the scope of this document. Possible mechanisms are to use a 364 software library that can be accessed via an API, a separate 365 authorization server that can be queried via HTTP (as envisioned by 366 OAuth [I-D.ietf-oauth-v2]), or any other mechanism. As such, this 367 document does not further describe the functional split between the 368 party that attaches the SAML assertion to the SIP message and the 369 party that creates the SAML assertion. 371 The SIP Identity specification calls the party that makes identity 372 assertions about the caller "Authentication Service (AS)". Such an 373 Authentication Service, which likely has access to various pieces of 374 information concerning the calling party, could also act as a SAML 375 Authority, and make such information available to the callee via 376 SAML. This document uses the term SAML Authority and Authentication 377 Service interchangable particularly because of the fact that the 378 entity that attaches the SAML assertion to the SIP message also uses 379 the SIP Identity mechanism to bind it to the message. 381 Note that technically there is a difference between attaching a 382 reference to a SAML assertion and attaching a SAML assertion to the 383 body of a message. We define two different profiles to cover these 384 two cases: 386 AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile: 388 In case of this profile the AS attaches a reference to a SAML 389 assertion to the SIP message and makes it available to the 390 verifier. More details about this profile can be found in 391 Section 7.1. 393 Assertion-by-Value Profile: 395 In case of this profile the SAML assertion is made available to 396 the verifying party directly without the additional step of 397 utilizing a reference. This approach is described in Section 7.2. 399 6. URI Parameter Definition 401 This document represents the URL pointing to the authorization 402 information using a URI parameter. The grammar for this parameter is 403 (following the ABNF [RFC4234] in Section 25 of RFC 3261 [RFC3261]): 405 token-info = 406 "token-info" HCOLON ident-info *( SEMI ident-info-params ) 408 ident-info = LAQUOT absoluteURI RAQUOT 410 ident-info-params = generic-param 412 Figure 1: 'token-info' ABNF Grammar 414 The "absoluteURI" MUST contain a URI which dereferences to a resource 415 containing a SAML assertion. All implementations of this 416 specification MUST support the use of HTTP and HTTPS URIs. Such HTTP 417 and HTTPS URIs MUST follow the conventions of RFC 2585 [RFC2585], and 418 for those URIs the indicated resource MUST be of the form 419 'application/samlassertion+xml' described in that specification. 421 An example of the syntax of the "token-info" parameter is given 422 below: 424 From: ; 426 tag=1928301774 428 7. SIP SAML Profiles 430 This section defines two "SIP SAML profiles": 432 o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 433 Profile" 435 o The "Assertion-by-Value" Profile 437 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 439 7.1.1. Required Information 441 The information given in this section is similar to the info provided 442 when registering something, a MIME Media Type, say, with IANA. In 443 this case, it is for registering this profile with the OASIS SSTC. 444 See Section 2 "Specification of Additional Profiles" in 445 [OASIS.saml-profiles-2.0-os]. 447 Identification: 449 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 451 Contact Information: 453 Hannes Tschofenig (Hannes.Tschofenig@nsn.com) 455 SAML Confirmation Method Identifiers: 457 The SAML V2.0 confirmation method identifier is used in this 458 profile. 460 Description: 462 Given below. 464 Updates: 466 None. 468 7.1.2. Profile Overview 470 Figure 2 illustrates this profile's overall protocol flow. The 471 following steps correspond to the labeled interactions in the figure. 472 Within an individual step, there may be one or more actual message 473 exchanges depending upon the protocol binding employed for that 474 particular step and other implementation-dependent behavior. 476 Although this profile is overview is cast in terms of a SIP INVITE 477 transaction, the reader should note that the mechanism specified 478 herein, may be applied to any SIP request message. 480 Figure 2 begins on the next page. 482 +------------------+ +------------------+ +-----------------+ 483 | Caller | |Authn Service (AS)| | Callee | 484 |Alice@example.com | | @example.com | | Bob@example2.com| 485 +--------+---------+ +--------+---------+ +--------+--------+ 486 - - | | | (steps) 487 ^ ^ | INVITE | | 488 | | |---------------------->| | (1a) 489 | | From:alice@foo.com | | 490 | C | To:sip:bob@example.com| | 491 | S | | | 492 | e | 407 Proxy auth. req. | | 493 | q |<----------------------| | (1b) 494 | = | Challenge | | 495 | N | | | 496 | | ACK | | 497 | | |---------------------->| | (1c) 498 | V | | | 499 | - | | | 500 ^ | INVITE + authorization| | 501 D | | header w/ creds | | 502 | |---------------------->| | (2) 503 I | | From:alice@foo.com | | 504 | | To:sip:bob@example.com| | 505 A | Proxy-Authorization:..| | 506 C | | INVITE | 507 L S | |--------------------->| (3) 508 e | | From:alice@foo.com | 509 O q | | To:sip:bob@example2.com 510 | | | 511 G = | | token-info: | 512 | | https://example.com| 513 | N | | /assns/?ID=abcde | 514 | | | | 515 | + | |URI resolution (eg. HTTP) 516 | | |<=====================| (4) 517 | 1 | | GET /assns/?ID=abcde | 518 | | | | 519 | | | | HTTP/1.1 200 OK | 520 | | | |=====================>| (5) 521 | | | | | 522 | | | | | 523 | | | | | 524 | | | | Alice@example.com 525 | | | | 526 | | | | 527 | | | | ... 528 | | | | 529 | | | | foo=bar | 530 | | | 200 OK | | 531 | V |<----------------------+----------------------| (6) 532 . - | | | 533 V 535 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 536 Transaction 538 Step 1. Initial SIP Transaction between Caller and AS 540 This optional initial step is comprised of substeps 1a, 1b, 541 and 1c in Figure 2. In this step, the caller, Alice, sends 542 a SIP request message, illustrated as an INVITE, indicating 543 Bob as the callee (1a), is subsequently challenged by the AS 544 (1b), and sends an ACK in response to the challenge (1c). 545 The latter message signals the completion of this SIP 546 transaction (which is an optional substep of this profile). 548 Step 2. Caller sends SIP Request Message with Authorization 549 Credentials to the AS 551 Alice then sends an INVITE message in response to the 552 challenge, or uses cached credentials for the domain if step 553 1 was skipped, as specified in [RFC4474] and [RFC3261]. 554 Depending on the chosen SIP security mechanism for client 555 authentication either digest authentication, client side 556 authentication of Transport Layer Security, or a combination 557 of both is used to provide the AS with a strong assurance 558 about the identity of Alice. 560 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 562 First, the AS authorizes the received INVITE message as 563 specified in [RFC4474] and [RFC3261]. If the authorization 564 is successful, the AS constructs and caches a SAML assertion 565 asserting Alice's profile attributes required by Bob's 566 domain (example2.com), and also containing a the domain's 567 (example.com) public key certificate, or a reference to it. 568 The AS constructs a HTTP-based SAML URI Reference 569 incorporating the assertion's Assertion ID (see Section 570 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI 571 and puts the value into the token-info parameter. 573 The AS determines which profile attributes (if any) to 574 assert in the via local configuration 575 and/or obtaining example2.com's metadata 576 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 577 INVITE message to Bob. 579 Step 4. Callee Dereferences HTTP-based SAML URI Reference 581 Bob's UAC or SIP Proxy receives the message and begins 582 verifying it per the "Verifier Behavior" specified in 583 [RFC4474]. In order to accomplish this task, it needs to 584 obtain Alice's domain certificate. It obtains the HTTP- 585 based SAML URI reference from the message's token-info 586 parameter and dereferences it per Section 9.1. Note that 587 this is not a SIP message, but an HTTP message [RFC2616]. 589 Step 5. AS Returns SAML Assertion 591 Upon receipt of the above HTTP request, which contains an 592 embedded reference to Alice's SAML Assertion, Alice's AS 593 returns her assertion in an HTTP response message. 595 Upon receipt of Alice's SAML Assertion, the AS continues its 596 verification of the INVITE message. If successful, it 597 returns a 200 OK message directly to Alice. Otherwise it 598 returns an appropriate SIP error response. 600 Step 6. Callee Returns SIP 200 OK to Caller 602 If Bob determines, based upon Alice's identity as asserted 603 by the AS, and as further substantiated by the information 604 in the SAML assertion, to accept the INVITE, he returns a 605 SIP 200 OK message directly to Alice. 607 7.1.3. Profile Description 609 The following sections provide detailed definitions of the individual 610 profile steps. The relevant illustration is Figure 3, below. Note 611 that this profile is agnostic to the specific SIP request, and also 612 that the Sender and Authentication Service (AS) may be seperate or 613 co-located in actuality. 615 +------------------+ +------------------+ +------------------+ 616 | Sender | |Authn Service (AS)| | Verifier | 617 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 618 +--------+---------+ +--------+---------+ +--------+---------+ 619 | | | (steps) 620 | SIP Request | | 621 |---------------------->| | (1a) 622 | | | 623 | 407 Proxy auth. req. | | 624 |<----------------------| | (1b) 625 | Challenge | | 626 | | | 627 | ACK | | 628 |---------------------->| | (1c) 629 | | | 630 | | | 631 |SIP Req + authorization| | 632 | header w/ creds | | 633 |---------------------->| | (2) 634 | | | 635 | | | 636 | | SIP Req + token-info | 637 | |--------------------->| (3) 638 | | | 639 | | URI resolution | 640 | |<=====================| (4) 641 | | (via HTTP) | 642 | | | 643 | | HTTP/1.1 200 OK | 644 | |=====================>| (5) 645 | | | 646 | | | 647 | | ? | (6) 648 | | | 650 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 652 7.1.3.1. Initial SIP Transaction between Sender and AS 654 This optional step maps to Steps 1 and 2 of Section 5 "Authentication 655 Service Behavior" of [RFC4474]. If the SIP request sent by the 656 caller in substep 1a is deemed insufficiently authenticated by the AS 657 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 658 authenticate the sender of the message. The particulars of how this 659 is accomplished depend upon implementation and/or deployment 660 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 661 in Figure 3 are non-normative and illustrative only. 663 7.1.3.2. Sender sends SIP Request Message with Authorization 664 Credentials to the AS 666 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 667 Behavior" of [RFC4474]. This request is presumed to be made in a 668 context such that the AS will not challenge it -- i.e., the AS will 669 consider the sender of the message to be authenticated. If this is 670 not true, then this procedure reverts back to Step 1, above. 672 Otherwise, the AS carries out all other processing of the message as 673 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 674 procedure procedes to the next step below. 676 7.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 678 This first portion of this step maps to Steps 3 and 4 of Section 5 679 "Authentication Service Behavior" of [RFC4474], which the AS MUST 680 perform, although with the following additional substeps: 682 The AS MUST construct a SAML assertion according to the "Assertion 683 Profile Description" specified in Section 8.1 of this 684 specification. 686 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 687 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 689 The AS MUST use the URI constructed in the immediately preceding 690 substep as the value of the token-info parameter that is added to 691 the SIP request message. 693 Upon successful completion of all of the above, the AS forwards the 694 request message. 696 At this point in this step, after perhaps traversing some number of 697 intermediaries, the SIP request message arrives at a SIP network 698 entity performing the "verifier" role. This role and its behavior 699 are specified in Section 6 "Verifier Behavior" of [RFC4474]. The 700 verifier MUST perform the steps enumerated in the aforementioned 701 section, with the following modifications: 703 Step 1 of [RFC4474] Section 6 maps to and is updated by, the 704 following two steps in this procedure. 706 Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this 707 latter portion of this step, and/or the following two steps, as 708 appropriate. 710 7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 712 The verifier SHOULD ascertain whether it has a current cached copy of 713 the SIP message sender's SAML assertion and domain certificate. If 714 not, or if the verifier chooses to (e.g., due to local policy), it 715 MUST dereference the the HTTP-based SAML URI Reference found in the 716 SIP message's token-info parameter. To do so, the verifier MUST 717 employ the "SAML HTTP-URI-based SIP Binding" specified in 718 Section 9.1. 720 7.1.3.5. AS Returns SAML Assertion 722 This step also employs Section 9.1 "SAML HTTP-URI-based SIP Binding". 724 If the prior step returns an HTTP error (e.g., 4xx series), then this 725 procedure terminates and the verifier returns (upstream) a SIP 436 726 'Bad token-info' Response code. 728 Otherwise, the HTTP response message will contain a SAML assertion 729 and be denoted as such via the MIME media type of "application/ 730 samlassertion+xml" [IANA.application.samlassertion-xml]. The 731 verifier MUST perform the verification steps specified in Section 8.2 732 "Assertion Verification", below. If successful, then this procedure 733 continues with the next step. 735 7.1.3.6. Verifier performs Next Step 737 The SIP request was successfully processed. The verifier now 738 performs its next step, which depends at least in part on the type of 739 SIP request it received. 741 7.2. Caller-driven SIP SAML Conveyed Assertion Profile 743 For the "Assertion-by-value" profile we assume that a SAML assertion 744 is obtained out-of-band and attached to the body of the SIP message. 745 Note that any SIP message may be used to convey the SAML assertion 746 even though SIP INVITE may be the most appropriate candiate. The 747 verification step described in Section 8.2 is applicable to this 748 profile as well as the description on the content of the assertion 749 illustrated in Section 8.1. 751 8. Assertion Profile 753 This section provides some guidance on what information should be put 754 into a SAML assertion by the SAML Authority and how that information 755 is then used by the Verifier. 757 8.1. Assertion Profile Description 759 The schema for SAML assertions themselves is defined in Section 2.3 760 of [OASIS.saml-core-2.0-os]. 762 An example SAML assertion, formulated according to this profile is 763 given in Section 10. 765 Overall SAML assertion profile requirements: 767 If a SAML assertion is signed then it MUST be signed by the same 768 key that is used in the Transport Layer Security mechanism 769 utilized with HTTPS. Signing of SAML assertions is defined in 770 Section 5.4 of [OASIS.saml-core-2.0-os]. 772 In the following subsections, the SAML assertion profile is specified 773 element-by-element, in a top-down, depth-first manner, beginning with 774 the outermost element, "". Where applicable, the 775 requirements for an element's XML attributes are also stated, as a 776 part of the element's description. Requirements for any given 777 element or XML attribute are only stated when, in the context of use 778 of this profile, they are not already sufficiently defined by 779 [OASIS.saml-core-2.0-os]. 781 8.1.1. Element: 783 Attribute: ID 785 The value for the ID XML attribute SHOULD be allocated randomly 786 such that the value meets the randomness requirments specified in 787 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 789 Attribute: IssueInstant 791 The value for the IssueInstant XML attribute SHOULD be set at the 792 time the SAML assertion is created (and cached for subsequent 793 retrieval). This time instant value MAY be temporally the same as 794 that encoded in the SIP message's Date header, and MUST be at 795 least temporally later, although it is RECOMMENDED that it not be 796 10 minutes or more later. 798 8.1.1.1. Element: 800 The value for the Issuer XML element MUST be a value that matches 801 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 802 the certificate conveyed by the SAML assertion in the ds: 803 X509Certificate element located on this path within the SAML 804 assertion: 806 814 The element SHOULD contain both a element and a 815 element. 817 The value of the element MUST be the Address of Record 818 (AoR). 820 The element attribute Method SHOULD be set to 821 the value: 823 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 825 Although it MAY be set to some other implementation- and/or 826 deployment-specific value. The element itself 827 SHOULD be empty. 829 8.1.1.3. Element: 831 The element SHOULD contain an 832 element, which itself SHOULD contain an element. When 833 included the value of the element MUST be the same as the 834 addr-spec of the SIP request's To header field. 836 The following XML attributes of the element MUST be set 837 as follows: 839 Attribute: NotBefore 841 The value of the NotBefore XML attribute MUST be set to a time 842 instant the same as the value for the IssueInstant XML attribute 843 discussed above, or to a later time. 845 Attribute: NotOnOrAfter 847 The value of the NotOnOrAfter XML attribute MUST be set to a time 848 instant later than the value for NotBefore. 850 8.1.1.4. Element: 852 The SAML assertion MAY contain an element. If 853 so, the element will contain attribute-value 854 pairs, e.g., of a user profile nature, encoded according to either 855 one of the "SAML Attribute Profiles" as specified in 856 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 857 and/or deployment-specific attribute profile. 859 The attribute-value pairs SHOULD in fact pertain to the entity 860 identified in the SIP From header field, since a SAML assertion 861 formulated per this overall section is stating that they do. 863 8.2. Assertion Verification 865 This section specifies the steps that a verifier has to perform to 866 verify a SAML assertion created according to the profile from 867 Section 8.1.1. 869 The steps are: 871 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 872 extract the AS's domain certificate from the XML element at the end of the element path 874 given in Section 8.1.1.1. 876 2. Perform Step 1 in Section 6 of [RFC4474]. 878 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 879 that section, the verifier MUST verify the SAML assertion's 880 signature via the procedures specified in Section 5.4 of 881 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. The 479 882 'Invalid SAML Assertion' response code is used when the verifier 883 is unable to process the SAML assertion. 885 4. Perform Step 2 in Section 6 of [RFC4474]. 887 5. Verify that the signer of the SIP message's Identity header 888 field is the same as the signer of the SAML assertion, if SIP 889 Identity is used to bind the token-info parameter to the SIP 890 signaling message. Note that without such protection certain 891 attacks are feasible as described in Section 11. 893 6. Verify that the content of the SAML assertion matches with the 894 information carried in the SIP message. This may include the 895 following checks: 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. 904 9. Verify that the SAML assertion's element 905 value is set to whichever value was configured at 906 implementation- or deployment-time. The default value is: 908 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 910 10. Verify that the SAML assertion contains an element, 911 and that its value matches the value of the addr-spec of the SIP 912 To header field. 914 11. Verify that the validity period denoted by the NotBefore and 915 NotOnOrAfter attributes of the element meets the 916 requirements given in Section 8.1.1.3. 918 9. SAML SIP Binding 920 This section specifies one SAML SIP Binding at this time. Additional 921 bindings may be specified in future revisions of this specification. 922 The description in Section 8.1 is applicable to this profile. 924 9.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 10. Example SAML Assertions 950 This section presents two examples of a SAML assertion, one unsigned 951 (for clarity), the other signed (for accuracy). 953 In the first example, Figure 4, the assertion is attesting with 954 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 955 The validity conditions are expressed in lines 16-23, via both a 956 validity period expressed as temporal endpoints, and an "audience 957 restriction" stating that this assertion's semantics are valid for 958 only the relying party named "example2.com". Also, the assertion's 959 issuer is noted in lines 4-5. 961 The above items correspond to some aspects of this specification's 962 SAML assertion profile, as noted below in Security Considerations 963 dicussions, see: Section 11.1 and Section 11.3. 965 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 966 fashion, using LDAP/X.500 schema as the typing means. 968 1 971 4 972 5 example.com 973 6 974 7 975 8 978 11 Alice@example.com 979 12 980 13 982 15 983 16 985 18 986 19 987 20 example2.com 988 21 989 22 990 23 991 24 992 25 999 32 1000 33 +1-888-555-1212 1001 34 1002 35 1003 36 1004 37 1006 Figure 4: Unsigned SAML Assertion Illustrating Conveyance of 1007 Subject Attribute 1009 In the second example, Figure 5, the information described above is 1010 the same, the addition is that this version of the assertion is 1011 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 1013 integrity are assured. Since this assertion is the same as the one 1014 in the first example above, other than having a signature added, the 1015 second example below addresses the same Security Considerations 1016 aspects, plus those requiring a Signature. 1018 1 1021 4 1022 5 example.com 1023 6 1024 7 1025 8 1026 9 1028 11 1030 13 1032 15 1033 16 1036 19 1039 22 1043 26 1044 27 1045 28 1047 30 1048 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1049 32 1050 33 1051 34 1052 35 1053 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1054 37 1055 38 1056 39 1057 40 1058 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1059 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1060 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1061 44 1062 45 1063 46 1064 47 1065 48 1066 49 1069 52 Alice@example.com 1070 53 1071 54 1073 56 1074 57 1076 59 1077 60 1078 61 example2.com 1079 62 1080 63 1081 64 1082 65 1083 66 1090 73 1091 74 +1-888-555-1212 1092 75 1093 76 1094 77 1095 78 1097 Figure 5: Signed SAML Assertion Illustrating Conveyance of Subject 1098 Attribute 1100 11. Security Considerations 1102 This section discusses security considerations when using SAML with 1103 SIP. 1105 11.1. Man-in-the-Middle Attacks and Stolen Assertions 1107 Threat: 1109 By making SAML assertions available via HTTP-based requests by a 1110 potentially unbounded set of requesters, it is conceivably 1111 possible that anyone would be able to simply request one and 1112 obtain it. By SIP intermediaries on the signaling path for 1113 example. Or, an HTTP intermediary/proxy could intercept the 1114 assertion as it is being returned to a requester. 1116 The attacker could then attempt to utilize the SAML assertion in 1117 another exchange in order to impersonate the subject (the putative 1118 caller) to some SIP-based target entity. 1120 Countermeasures: 1122 Such an attack is implausible for several reasons. The primary 1123 reason is that a message constructed by an imposter using a stolen 1124 assertion that conveys the public key certificate of some domain 1125 will not verify because the values in the SAML assertion, which 1126 are tied to the SIP message, will not verify. 1128 Furthermore, the SIP SAML assertion may contain restrictions 1129 regarding the parties it can be used by. Finally, the assertion 1130 should be signed and thus causing any alterations to break its 1131 integrity and make such alterations detectable. 1133 11.2. Privacy 1135 Threat: 1137 The ability for other entities to obtain additional information 1138 about an individual, such as role in an organization or other 1139 authorization relevant information raises privacy concerns. 1141 Since the SAML assertion itself is not confidentiality protected 1142 nor the exchange of the reference to the SAML assertion an 1143 intermediary or a third party adversary would be allowed to gain 1144 additional information about an individual 1146 Countermeasures: 1148 To address the threats three cases need to be differentiated. 1150 First, a third party that did not participate in any of the 1151 exchange is prevented from eavesdropping on the content of the 1152 SAML assertion by employing confidentiality protection of the SIP 1153 signaling exchange as well as the HTTP exchange. This ensures 1154 that an eavesdropper on the wire is unable to obtain information. 1155 However, this does not prevent intermediaries, such as SIP proxies 1156 from observing a URL to a SAML assertion (in the token-info 1157 parameter). To deal with this second type of attacker depending 1158 on the environment where such a threat must be addressed it is 1159 necessary to authenticate the entity that tries to resolve the 1160 reference to a SAML assertion and to only provide a positive 1161 response (with the SAML assertion) if the requestor is authorized 1162 to obtain the desired information. When a SAML assertion is 1163 carried inband then such a protection is more difficult to 1164 accomplish as the SAML assertion would have to be confidentiality 1165 protected with the key of the intented recipient, for example 1166 using S/MIME. Finally, the last type of threat concerns the 1167 intented recipient of the SAML assertion itself. Proper 1168 permissions for the distribution of information about the caller 1169 via the content of the SAML assertion to certain recipients need 1170 to be available. This permission must be provided by the caller 1171 itself or, in certain circumstances, by someone on behalf of the 1172 caller. From a technical point of view, some form of 1173 authorization policies will be required. 1175 11.3. Forged Assertion 1177 Threat: 1179 A malicious user could forge or alter a SAML assertion in order to 1180 communicate with the SIP entities. 1182 Countermeasures: 1184 To avoid this kind of attack, the entities must assure that proper 1185 mechanisms for protecting the SAML assertion are employed, e.g., 1186 signing the SAML assertion itself or protecting the transport of 1187 the SAML assertion from the AS to the verifying party using TLS. 1188 Section 5.1 of [OASIS.saml-core-2.0-os] specifies the signing of 1189 SAML assertions. 1191 Additionally, the assertion content dictated by the SAML assertion 1192 profile herein ensures ample evidence for a relying party to 1193 verify the assertion and its relationship with the received SIP 1194 request. 1196 11.4. Replay Attack 1198 Threat: 1200 Theft of SIP message protected by the mechanisms described herein 1201 and replay of it at a later time. 1203 Countermeasures: 1205 The SAML assertion may contain several elements to prevent replay 1206 attacks. There is, however, a clear tradeoff between the 1207 replaying an assertion and re-using it over multiple SIP 1208 exchanges/sessions. 1210 Additionally, the SAML assertion can be tied to the SIP exchange 1211 with the help of the SIP Identity mechanism. RFC 4474 [RFC4474] 1212 signs certain header fields and the SIP message body and thereby 1213 helps to protect message modifications. If a recipient knows that 1214 all messages from a certain originator arrive with SIP Identity 1215 protection applies then downgrading attacks are not possible. 1217 12. Contributors 1219 The authors would like to thank Marcus Tegnander and Henning 1220 Schulzrinne for his contributions to earlier versions of this 1221 document. 1223 13. Acknowledgments 1225 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1226 Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki 1227 Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen 1228 Fries and Vijay Gurbani for their comments to this draft. 1230 Eric Rescorla also provided a detailed review of the document. We 1231 would like to thank him for his feedback. 1233 The "AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile" 1234 is based on an idea by Jon Peterson. 1236 14. IANA Considerations 1238 When a SAML assertion is attached to the body of the message then the 1239 "application/samlassertion+xml" MIME media type is used. This MIME 1240 type is already registered with IANA and no further action is 1241 required from IANA. 1243 14.1. URI Parameter 1245 This document extends the registry of URI parameters, as defined RFC 1246 3969 [RFC3969] with the following value: 1248 Parameter Name: token-info 1250 Predefined Values: No 1252 Reference: This document 1254 14.2. 477 'Binding to SIP Message failed' Response Code 1256 This document registers a new SIP response code. It is sent when a 1257 verifier receives a SAML assertion but the Subject and Condition 1258 elements cannot be matched to the content in the SIP message, i.e., 1259 the binding between the SIP message and the SAML assertion cannot be 1260 accomplished. This response code is defined by the following 1261 information, which has been added to the method and response-code 1262 sub-registry under http://www.iana.org/assignments/sip-parameters. 1264 Response Code Number: 477 1266 Default Reason Phrase: Binding to SIP Message failed 1268 14.3. 478 'Unknown SAML Assertion Content' Response Code 1270 This document registers a new SIP response code. It is used when the 1271 verifier is unable to parse the content of the SAML assertion, 1272 because, for example, the assertion contains only unknown elements in 1273 in the SAML assertion, or the SAML assertion XML document is garbled. 1274 This response code is defined by the following information, which has 1275 been added to the method and response-code sub-registry under 1276 http://www.iana.org/assignments/sip-parameters. 1278 Response Code Number: 478 1280 Default Reason Phrase: Unknown SAML Assertion Content 1282 14.4. 479 'Invalid SAML Assertion' Response Code 1284 This document registers a new SIP response code. It is used when the 1285 verifier is unable to process the SAML assertion. A verifier may be 1286 unable to process the SAML assertion in case the assertion is self- 1287 signed, or signed by a root certificate authority for whom the 1288 verifier does not possess a root certificate. This response code is 1289 defined by the following information, which has been added to the 1290 method and response-code sub-registry under 1291 http://www.iana.org/assignments/sip-parameters. 1293 Response Code Number: 479 1295 Default Reason Phrase: Invalid SAML Assertion 1297 15. Change Log 1299 RFC Editor - Please remove this section before publication. 1301 15.1. -06 to -07 1303 Undo changes made in version 6. 1305 Removed the header fields and switched to a URI parameter 1307 Editorial changes 1309 15.2. -05 to -06 1311 Defined a new SIP Identity signature mechanism. 1313 15.3. -04 to -05 1315 Changed the document type to experimental 1317 Removed option tag 1319 Added the Caller-driven SIP SAML Conveyed Assertion Profile 1321 Defined a new header (SAML-Info) 1323 Changed the description for usage with this new header 1325 Updated security considerations 1327 Minor editorial cleanups 1329 15.4. -03 to -04 1331 Updated IANA consideration section. 1333 Added option tag 1335 Updated acknowledgments section 1337 Minor editorial changes to the security considerations section 1339 15.5. -02 to -03 1341 Denoted that this I-D is intended to update RFC4474 per SIP working 1342 group consensus at IETF-69. This is the tact adopted in order to 1343 address the impedance mismatch between the nature of the URIs 1344 specified as to be placed in the Identity-Info header field, and what 1345 is specified in RFC4474 as the allowable value of that header field. 1347 Added placeholder "TBD" section for a to-be-determined "call-by- 1348 value" profile, per SIP working group consensus at IETF-69. 1350 Removed use-case appendicies (per recollection of JHodges during 1351 IETF-69 discussion as being WG consensus, but such is not noted in 1352 the minutes). 1354 15.6. -00 to -02 1356 Initial specifications to kickstart the work. 1358 16. References 1360 16.1. Normative References 1362 [OASIS.saml-bindings-2.0-os] 1363 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1364 Maler, "Bindings for the OASIS Security Assertion Markup 1365 Language (SAML) V2.0", OASIS 1366 Standard saml-bindings-2.0-os, March 2005. 1368 [OASIS.saml-core-2.0-os] 1369 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1370 "Assertions and Protocol for the OASIS Security Assertion 1371 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1372 2.0-os, March 2005. 1374 [OASIS.saml-metadata-2.0-os] 1375 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1376 "Metadata for the Security Assertion Markup Language 1377 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1378 March 2005. 1380 [OASIS.saml-profiles-2.0-os] 1381 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1382 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1383 Security Assertion Markup Language (SAML) V2.0", OASIS 1384 Standard OASIS.saml-profiles-2.0-os, March 2005. 1386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1387 Requirement Levels", BCP 14, RFC 2119, March 1997. 1389 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1390 Locators", RFC 2392, August 1998. 1392 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1393 Infrastructure Operational Protocols: FTP and HTTP", 1394 RFC 2585, May 1999. 1396 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1397 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1398 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1400 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1401 A., Peterson, J., Sparks, R., Handley, M., and E. 1402 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1403 June 2002. 1405 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1406 X.509 Public Key Infrastructure Certificate and 1407 Certificate Revocation List (CRL) Profile", RFC 3280, 1408 April 2002. 1410 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1411 Method", RFC 3515, April 2003. 1413 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1414 IETF URN Sub-namespace for Registered Protocol 1415 Parameters", BCP 73, RFC 3553, June 2003. 1417 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1418 Authenticated Identity Body (AIB) Format", RFC 3893, 1419 September 2004. 1421 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1422 (IANA) Uniform Resource Identifier (URI) Parameter 1423 Registry for the Session Initiation Protocol (SIP)", 1424 BCP 99, RFC 3969, December 2004. 1426 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1427 Specifications: ABNF", RFC 4234, October 2005. 1429 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1430 Authenticated Identity Management in the Session 1431 Initiation Protocol (SIP)", RFC 4474, August 2006. 1433 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1434 "Trait-Based Authorization Requirements for the Session 1435 Initiation Protocol (SIP)", RFC 4484, August 2006. 1437 [W3C.xmldsig-core] 1438 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1439 Syntax and Processing", W3C Recommendation xmldsig-core, 1440 October 2000, . 1442 16.2. Informative References 1444 [I-D.ietf-oauth-v2] 1445 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 1446 2.0 Protocol", draft-ietf-oauth-v2-10 (work in progress), 1447 July 2010. 1449 [IANA.application.samlassertion-xml] 1450 OASIS Security Services Technical Committee (SSTC), 1451 "application/samlassertion+xml MIME Media Type 1452 Registration", IANA MIME Media Types Registry application/ 1453 samlassertion+xml, December 2004. 1455 [OASIS.saml-conformance-2.0-os] 1456 Mishra, P., Philpott, R., and E. Maler, "Conformance 1457 Requirements for the Security Assertion Markup Language 1458 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1459 March 2005. 1461 [OASIS.saml-glossary-2.0-os] 1462 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1463 Security Assertion Markup Language (SAML) V2.0", OASIS 1464 Standard saml-glossary-2.0-os, March 2005. 1466 [OASIS.saml-sec-consider-2.0-os] 1467 Hirsch, F., Philpott, R., and E. Maler, "Security and 1468 Privacy Considerations for the OASIS Security Markup 1469 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1470 2.0-os, March 2005. 1472 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1473 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1474 OASIS SSTC Committee 1475 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1477 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1478 Cantor, S., "SAML Protocol Extension for Third-Party 1479 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1480 ext-thirdparty-cd-01, March 2006. 1482 [OASIS.sstc-saml-tech-overview-2.0-draft-16] 1483 Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, 1484 P., and T. Scavo, "Security Assertion Markup Language 1485 (SAML) V2.0 Technical Overview", OASIS SSTC Working 1486 Draft sstc-saml-tech-overview-2.0-draft-16, May 2008. 1488 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1489 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1490 March 1999. 1492 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1493 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1494 September 1999. 1496 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1497 Certificate Profile for Authorization", RFC 3281, 1498 April 2002. 1500 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1501 Initiation Protocol (SIP)", RFC 3323, November 2002. 1503 Authors' Addresses 1505 Hannes Tschofenig 1506 Nokia Siemens Networks 1507 Linnoitustie 6 1508 Espoo 02600 1509 Finland 1511 Phone: +358 (50) 4871445 1512 Email: Hannes.Tschofenig@gmx.net 1513 URI: http://www.tschofenig.priv.at 1515 Jeff Hodges 1517 Email: Jeff.Hodges@KingsMountain.com 1519 Jon Peterson 1520 NeuStar, Inc. 1521 1800 Sutter St Suite 570 1522 Concord, CA 94520 1523 US 1525 Email: jon.peterson@neustar.biz 1527 James Polk 1528 Cisco 1529 2200 East President George Bush Turnpike 1530 Richardson, Texas 75082 1531 US 1533 Email: jmpolk@cisco.com 1535 Douglas C. Sicker 1536 University of Colorado at Boulder 1537 ECOT 430 1538 Boulder, CO 80309 1539 US 1541 Email: douglas.sicker@colorado.edu