idnits 2.17.00 (12 Aug 2021) /tmp/idnits19826/draft-ietf-sip-saml-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1480. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4474, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 243 has weird spacing: '...ich the asser...' (Using the creation date from RFC4474, updated by this document, for RFC5378 checks: 2002-10-31) -- 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 (July 14, 2008) is 5059 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2392' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1318, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1383, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1395, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Downref: Normative reference to an Informational RFC: RFC 4484 -- 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 (~~), 6 warnings (==), 10 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 Updates: 4474 (if approved) J. Hodges 5 Intended status: Standards Track J. Peterson 6 Expires: January 15, 2009 NeuStar, Inc. 7 J. Polk 8 Cisco 9 D. Sicker 10 CU Boulder 11 July 14, 2008 13 SIP SAML Profile and Binding 14 draft-ietf-sip-saml-04.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 15, 2009. 41 Abstract 43 This document specifies a Session Initiation Protocol (SIP) profile 44 of Security Assertion Markup Language (SAML) as well as a SAML SIP 45 binding. The defined SIP SAML Profile composes with the mechanisms 46 defined in the SIP Identity specification and satisfy requirements 47 presented in "Trait-based Authorization Requirements for the Session 48 Initiation Protocol (SIP)". 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 56 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 57 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 58 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 59 6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14 60 6.1. AS-driven SIP SAML URI-based Attribute Assertion 61 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14 62 6.1.1. Required Information . . . . . . . . . . . . . . . . . 14 63 6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14 64 6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18 65 6.1.4. Assertion Profile Description . . . . . . . . . . . . 21 66 6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 23 67 6.2. The TBD "call-by-value" Profile . . . . . . . . . . . . . 25 68 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26 69 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26 70 8. The 'saml-shusb' Option Tag . . . . . . . . . . . . . . . . . 27 71 9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 28 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 73 10.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 33 74 10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 33 75 10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 34 76 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 77 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 79 13.1. IANA Registration for New SIP Option Tag . . . . . . . . . 37 80 13.2. 477 'Use Identity Header with SAML Assertion' Response 81 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 82 13.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 37 83 13.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 37 84 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 85 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 86 15.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40 87 15.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40 88 15.3. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 40 89 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 90 16.1. Normative References . . . . . . . . . . . . . . . . . . . 41 91 16.2. Informative References . . . . . . . . . . . . . . . . . . 42 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 93 Intellectual Property and Copyright Statements . . . . . . . . . . 45 95 1. Introduction 97 This document specifies composition of the Security Assertion Markup 98 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 99 richer authorization mechanisms and enable "trait-based 100 authorization." Trait-based authorization is where one is authorized 101 to make use of some resource based on roles or traits rather than 102 ones identifier(s). Motivations for trait-based authorization, along 103 with use-case scenarios, are presented in [RFC4484]. 105 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 106 based framework for creating and exchanging security information. 107 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 108 [OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative 109 overviews of SAMLv2. The SAMLv2 specification set is normatively 110 defined by [OASIS.saml-conformance-2.0-os]. 112 Various means of providing trait-based authorization exist: 113 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 114 to the authenticated identity body [RFC3893]. The authors selected 115 SAML due to its increasing use in environments such as the Liberty 116 Alliance, and the Internet2 project, areas where the applicability to 117 SIP is widely desired. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 The SIP network element "Authentication Service" is introduced in 126 [RFC4474]. We reuse this term to refer to a network element that 127 authenticates and authorizes a user and creates a "SIP identity 128 assertion". This system entity is the logical equivalent of a "SAML 129 Authority" in the SAML terminology. 131 For overall SIP terminology, see [RFC3261]. 133 In this specification, the term, or term component, "SAML" refers to 134 SAML V2.0 in all cases. For example, the term "SAML assertion" 135 implicitly means "SAMLv2 assertion". For overall SAML terminology, 136 see [OASIS.saml-glossary-2.0-os]. 138 The below list maps other various SIP terms to their SAML 139 (rough-)equivalents: 141 Element, Network Element: 143 System Entity, Entity 145 Authentication Service: 147 SAML Authority 149 Invitee, Invited User, Called Party, Callee: 151 Relying Party 153 Server, User Agent Server (UAS): 155 SAML Responder 157 User Agent Client (UAC), client: 159 SAML Requester 161 Additional terms defined in the context of this specification: 163 profile attribute(s): 165 one or more attributes of a "user profile". 167 user profile, subject profile: 169 the set of various attributes accompanying (i.e., mapped to) a 170 user account in many environments. 172 3. SAML Introduction 174 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 175 [OASIS.sstc-saml-tech-overview-2.0-draft-08] defines an XML-based 176 framework for exchanging "security assertions" between entities. In 177 the course of making, or relying upon such assertions, SAML system 178 entities may use SAML protocols, or other protocols, to communicate 179 an assertion itself, or the subject of an assertion. 181 Thus one can employ SAML to make and encode statements such as "Alice 182 has these profile attributes and her domain's certificate is 183 available over there, and I'm making this statement, and here's who I 184 am." Then one can cause such an assertion to be conveyed to some 185 party who can then rely on it in some fashion for some purpose, for 186 example input it into some local policy evaluation for access to some 187 resource. This is done in a particular "context of use". Such a 188 context of use could be, for example, deciding whether to accept and 189 act upon a SIP-based invitation to initiate a communication session. 191 The specification of how SAML is employed in a particular context of 192 use is known as a "SAML profile". The specification of how SAML 193 assertions and/or protocol messages are conveyed in, or over, another 194 protocol is known as a "SAML Binding". Typically, a SAML profile 195 specifies the SAML bindings that may be used in its context. Both 196 SAML profiles and SAML bindings reference other SAML specifications, 197 especially the SAML Assertions and Protocols, aka "SAML Core", 198 specification [OASIS.saml-core-2.0-os]. 200 There is an additional subtle aspect of SAML profiles that is worth 201 highlighting -- the notion of a "SAML assertion profile". A SAML 202 assertion profile is the specification of the assertion contents in 203 the context of a particular SAML profile. It is possibly further 204 qualified by a particular implementation and/or deployment context. 205 Condensed examples of SAML assertion profiles are: 207 o The SAML assertion must contain at least one authentication 208 statement and no other statements. The relying party must be 209 represented in the element. The 210 SubjectConfirmation Method must be Foo. etc. 212 o The SAML assertion must contain at least one attribute statement 213 and may contain more than one. The values for the subject's 214 profile attributes named "Foo" and "Bar" must be present. An 215 authentication statement may be present. etc. 217 The primary facets of SAML itself are: 219 o Assertions 221 o Abstract Request/Response protocol 223 We describe each in turn below: 225 3.1. SAML Assertions 227 A SAML assertion is a package of information including issuer and 228 subject, conditions and advice, and/or attribute statements, and/or 229 authentication statements and/or other statements. Statements may or 230 may not be present. The SAML assertion "container" itself contains 231 the following information: 233 Issuing information: 235 Who issued the assertion, when was it issued and the assertion 236 identifier. 238 Subject information: 240 The name of the subject, the security domain and optional subject 241 information, like public key. 243 Conditions under which the assertion is valid: 245 Special kind of conditions like assertion validity period, 246 audience restriction and target restriction. 248 Additional advice: 250 Explaining how the assertion was made, for example. 252 In terms of SAML assertions containing SAML attribute statements or 253 SAML authentication statements, here are explanatory examples: 255 With a SAML assertion containing a SAML attribute statement, an 256 issuing authority is asserting that the subject is associated with 257 certain attributes with certain subject profile attribute values. 258 For example, user jon@cs.example.com is associated with the 259 attribute "Department", which has the value "Computer Science". 261 With a SAML assertion containing a SAML authentication statement, 262 an issuing authority is asserting that the subject was 263 authenticated by certain means at a certain time. 265 With a SAML assertion containing both a SAML attribute statement 266 and a SAML authentication statement, an issuing authority is 267 asserting the union of the above. 269 3.2. Abstract Request/Response Protocol 271 SAML defines an abstract request/response protocol for obtaining 272 assertions. See Section 3 "SAML Protocols" of 273 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 274 response returns the requested assertion or an error. This abstract 275 protocol may then be cast into particular contexts of use by binding 276 it to specific underlying protocols, e.g., HTTP or SIP, and 277 "profiling" it for the specific use case at hand. The SAML HTTP- 278 based web single sign-on profile is one such example (see Section 4.1 279 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 280 based SIP communication session establishment, the topic of this 281 specification, is another. 283 4. Specification Scope 285 The scope of this specification is: 287 o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such 288 that a subject's profile attributes, and their domain's 289 certificate, can be conveyed to a relying party using SAML. In 290 doing so, satisfy the requirements outlined in [RFC4484], and 291 compose with [RFC4474]. 293 The following are outside the scope of this specification: 295 o Defining a means for configuring the runtime behavior, or 296 deployment characteristics, of the Authentication Service. 298 Discussion: 300 For example, a SIP Authentication Service could be implemented 301 such that its SAML-based features are employed, or not, on a 302 subject-by-subject basis, and/or on a domain-by-domain basis. 304 o The definition of specific conveyed subject profile attributes 305 (aka traits). 307 Discussion: 309 This specification defines a facility enabling "trait-based 310 authorization" as discussed in [RFC4484]. 312 The attributes of interest in trait-based authorization will be 313 ones akin to, for example: roles, organizational membership, 314 access rights, or authentication event context. Definition of 315 such attributes is application- and/or deployment-context- 316 dependent and are not defined in this specification. However, The 317 SAMLv2 specification defines several "SAML Attribute Profiles" for 318 encoding attributes from various application domains, e.g., LDAP, 319 UUID/GUID, DCE PAC, and XACML, in SAML assertions 320 [OASIS.saml-profiles-2.0-os]. 322 In order for any trait-based system to be practical, participating 323 entities must agree on attributes and traits that will be conveyed 324 and subsequently relied upon. Without such agreements, a trait- 325 based system cannot be usefully deployed. This specification does 326 not discuss the manner in which participating entites might 327 discover one another or agree on the syntax and semantics of 328 attributes and traits. 330 Note that SAMLv2 specifies a "metadata" facility that may be 331 useful in addressing this need. 333 5. Employing SAML in SIP 335 Employing SAML in SIP necessitates devising a new SAML profile(s) and 336 binding(s) because the those already specified in the SAMLv2 337 specification set are specific to other use contexts, e.g., HTTP- 338 based web browsing. Although SIP bears some similarity to HTTP, it 339 is a seperately distinct protocol, thus requiring specification of 340 SIP-specific SAML profile(s) and binding(s). This is technically 341 straightforward as both SAML and SIP are explicitly extensible. 343 The "Authenticated Identity Management in SIP" specification 344 [RFC4474] (aka "SIP Identity") facilitates the composition of SAML 345 and SIP in that it defines a "mediated authentication architecture" 346 where verifying endpoints verify SIP identity assertions -- i.e., the 347 "Identity" header value -- signed by an Authentication Service (AS). 348 The semantic being that the AS is vouching that it did indeed 349 authenticate the calling party. 351 Such an Authentication Service, which likely has access to various 352 pieces of information concerning the calling party, could also act as 353 a SAML Authority, and make such information available to the callee 354 via SAML. 356 Since [RFC4474] stipulates that the AS must make its certificate 357 available for retrieval and convey the availability and access 358 mechanism via a URI, in the Identity-Info header, we have an 359 opportunity to compose SIP Identity and SAML. 361 Such composition can be accomplished by having the resource referred 362 to by the URI in the Identity-Info be a SAML assertion conveying both 363 the AS's certificate and user profile attributes. This is the 364 approach defined in this specification. Figure 1 illustrates this 365 approach in a high-level summary fashion. Figure 2, further below, 366 illustrates additional details. 368 +--------+ +--------------+ +--------+ 369 |Alice@ | |Authentication| | Bob@ | 370 |example | |Service | |example2| 371 |.com | |@example.com | |.com | 372 | | | | | | 373 +---+----+ +------+-------+ +---+----+ 374 | | | 375 | INVITE | | 376 |---------------------->| | 377 | From:alice@foo.com | | 378 | | | 379 | 407 Proxy auth. req. | | 380 |<----------------------| | 381 | Challenge | | 382 | | | 383 | ACK | | 384 |---------------------->| | 385 | | | 386 | INVITE w/authn creds | | 387 |---------------------->| | 388 | | INVITE | 389 | | w/Identity header | 390 | |--------------------->| 391 | | and Identity-Info | 392 | | | 393 | | HTTP GET SAML assn | 394 | |<==================== | 395 | | and domain cert | 396 | | | 397 | | HTTP 200 OK + assn | 398 | |=====================>| 399 | | and domain cert | 400 | 200 OK | | 401 |<----------------------+----------------------| 402 | | | 404 Figure 1: SIP-SAML-based Network Asserted Identity 406 Since the AS already being trusted to create and add the Identity 407 header containing the SIP Identity Assertion, and to supply a pointer 408 to its domain certificate, having it point instead to a SAML 409 assertion conveying the domain certificate and possibly some user 410 profile attributes, does not significantly alter the first-order 411 security considerations examined in [RFC4474]. This specification 412 provides some additional security considerations analysis below in 413 Section 10. 415 6. SIP SAML Profiles 417 This section defines two "SIP SAML profiles": 419 o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 420 Profile" 422 o The to-be-determined (TBD) "call-by-value" profile 424 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 426 6.1.1. Required Information 428 The information given in this section is similar to the info provided 429 when registering something, a MIME Media Type, say, with IANA. In 430 this case, it is for registering this profile with the OASIS SSTC. 431 See Section 2 "Specification of Additional Profiles" in 432 [OASIS.saml-profiles-2.0-os]. 434 Identification: 436 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 438 @@ NOTE: This URN must be agreed upon, and then registered with 439 IANA per [RFC3553]. 441 Contact Information: 443 @@ someone's or something's contact info goes here 445 SAML Confirmation Method Identifiers: 447 The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is 448 used in this profile. 450 Description: 452 Given below. 454 Updates: 456 None. 458 6.1.2. Profile Overview 460 Figure 2 illustrates this profile's overall protocol flow. The 461 following steps correspond to the labeled interactions in the figure. 462 Within an individual step, there may be one or more actual message 463 exchanges depending upon the protocol binding employed for that 464 particular step and other implementation-dependent behavior. 466 Although this profile is overview is cast in terms of a SIP INVITE 467 transaction, the reader should note that the mechanism specified 468 herein, and in [RFC4474], may be applied to any SIP request message. 470 Figure 2 begins on the next page. 472 +------------------+ +------------------+ +-----------------+ 473 | Caller | |Authn Service (AS)| | Callee | 474 |Alice@example.com | | @example.com | | Bob@example2.com| 475 +--------+---------+ +--------+---------+ +--------+--------+ 476 - - | | | (steps) 477 ^ ^ | INVITE | | 478 | | |---------------------->| | (1a) 479 | | From:alice@foo.com | | 480 | C | To:sip:bob@example.com| | 481 | S | | | 482 | e | 407 Proxy auth. req. | | 483 | q |<----------------------| | (1b) 484 | = | Challenge | | 485 | N | | | 486 | | ACK | | 487 | | |---------------------->| | (1c) 488 | V | | | 489 | - | | | 490 ^ | INVITE + authorization| | 491 D | | header w/ creds | | 492 | |---------------------->| | (2) 493 I | | From:alice@foo.com | | 494 | | To:sip:bob@example.com| | 495 A | Proxy-Authorization:..| | 496 C | | INVITE | 497 L S | |--------------------->| (3) 498 e | | From:alice@foo.com | 499 O q | | To:sip:bob@example2.com 500 | | Identity: ..... | 501 G = | | Identity-Info: | 502 | | https://example.com| 503 | N | | /assns/?ID=abcde | 504 | | | | 505 | + | |URI resolution (eg. HTTP) 506 | | |<=====================| (4) 507 | 1 | | GET /assns/?ID=abcde | 508 | | | | 509 | | | | HTTP/1.1 200 OK | 510 | | | |=====================>| (5) 511 | | | | | 512 | | | | | 513 | | | | | 514 | | | | Alice@example.com 515 | | | | 516 | | | | 517 | | | | ... 518 | | | | 519 | | | | foo=bar | 520 | | | 200 OK | | 521 | V |<----------------------+----------------------| (6) 522 . - | | | 523 V 525 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 526 Transaction 528 Step 1. Initial SIP Transaction between Caller and AS 530 This optional initial step is comprised of substeps 1a, 1b, 531 and 1c in Figure 2. In this step, the caller, Alice, sends 532 a SIP request message, illustrated as an INVITE, indicating 533 Bob as the callee (1a), is subsequently challenged by the AS 534 (1b), and sends an ACK in response to the challenge (1c). 535 The latter message signals the completion of this SIP 536 transaction (which is an optional substep of this profile). 538 Step 2. Caller sends SIP Request Message with Authorization 539 Credentials to the AS 541 Alice then sends an INVITE message in response to the 542 challenge, or uses cached credentials for the domain if step 543 1 was skipped, as specified in [RFC4474] and [RFC3261]. 544 Depending on the chosen SIP security mechanism for client 545 authentication either digest authentication, client side 546 authentication of Transport Layer Security, or a combination 547 of both is used to provide the AS with a strong assurance 548 about the identity of Alice. 550 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 552 First, the AS authorizes the received INVITE message as 553 specified in [RFC4474] and [RFC3261]. If the authorization 554 is successful, the AS will form the "identity signature" for 555 the message and add Identity and Identity-Info header fields 556 to the message. The AS also at this time constructs and 557 caches a SAML assertion asserting Alice's profile attributes 558 required by Bob's domain (example2.com), and also containing 559 a the domain's (example.com) public key certificate, or a 560 reference to it. This certificate MUST contain the public 561 key corresponding to the private key used to construct the 562 signature whose value was placed in the Identity header. 563 The AS constructs a HTTP-based SAML URI Reference 564 incorporating the assertion's Assertion ID (see section 565 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as 566 the value for the Identity-Info header it adds to the INVITE 567 message. 569 The AS determines which profile attributes (if any) to 570 assert in the via local configuration 571 and/or obtaining example2.com's metadata 572 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 573 INVITE message to Bob. 575 Step 4. Callee Dereferences HTTP-based SAML URI Reference 577 Bob's UAC or SIP Proxy receives the message and begins 578 verifying it per the "Verifier Behavior" specified in 579 [RFC4474]. In order to accomplish this task, it needs to 580 obtain Alice's domain certificate. It obtains the HTTP- 581 based SAML URI Reference from the message's Identity-Info 582 header and dereferences it per Section 7.1. Note that this 583 is not a SIP message, but an HTTP message [RFC2616]. 585 Step 5. AS Returns SAML Assertion 587 Upon receipt of the above HTTP request, which contains an 588 embedded reference to Alice's SAML Assertion, Alice's AS 589 returns her assertion in an HTTP response message. 591 Upon receipt of Alice's SAML Assertion, the AS continues its 592 verification of the INVITE message. If successful, it 593 returns a 200 OK message directly to Alice. Otherwise it 594 returns an appropriate SIP error response. 596 Step 6. Callee Returns SIP 200 OK to Caller 598 If Bob determines, based upon Alice's identity as asserted 599 by the AS, and as further substantiated by the information 600 in the SAML assertion, to accept the INVITE, he returns a 601 SIP 200 OK message directly to Alice. 603 6.1.3. Profile Description 605 The following sections provide detailed definitions of the individual 606 profile steps. The relevant illustration is Figure 3, below. Note 607 that this profile is agnostic to the specific SIP request, and also 608 that the Sender and Authentication Service (AS) may be seperate or 609 co-located in actuality. 611 +------------------+ +------------------+ +------------------+ 612 | Sender | |Authn Service (AS)| | Verifier | 613 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 614 +--------+---------+ +--------+---------+ +--------+---------+ 615 | | | (steps) 616 | SIP Request | | 617 |---------------------->| | (1a) 618 | | | 619 | 407 Proxy auth. req. | | 620 |<----------------------| | (1b) 621 | Challenge | | 622 | | | 623 | ACK | | 624 |---------------------->| | (1c) 625 | | | 626 | | | 627 |SIP Req + authorization| | 628 | header w/ creds | | 629 |---------------------->| | (2) 630 | | | 631 | | | 632 | | SIP Req + Ident & | 633 | | authz headers | 634 | |--------------------->| (3) 635 | | | 636 | | URI resolution | 637 | |<=====================| (4) 638 | | (via HTTP) | 639 | | | 640 | | HTTP/1.1 200 OK | 641 | |=====================>| (5) 642 | | | 643 | | | 644 | | ? | (6) 645 | | | 647 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 649 6.1.3.1. Initial SIP Transaction between Sender and AS 651 This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication 652 Service Behavior" of [RFC4474]. If the SIP request sent by the 653 caller in substep 1a is deemed insufficiently authenticated by the AS 654 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 655 authenticate the sender of the message. The particulars of how this 656 is accomplished depend upon implementation and/or deployment 657 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 658 in Figure 3 are non-normative and illustrative only. 660 6.1.3.2. Sender sends SIP Request Message with Authorization 661 Credentials to the AS 663 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 664 Behavior" of [RFC4474]. This request is presumed to be made in a 665 context such that the AS will not challenge it -- i.e., the AS will 666 consider the sender of the message to be authenticated. If this is 667 not true, then this procedure reverts back to Step 1, above. 669 Otherwise, the AS carries out all other processing of the message as 670 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 671 procedure procedes to the next step below. 673 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 675 This first portion of this step maps to Steps 3 and 4 of Section 5 676 "Authentication Service Behavior" of [RFC4474], which the AS MUST 677 perform, although with the following additional substeps: 679 The AS MUST construct a SAML assertion according to the "Assertion 680 Profile Description" specified in Section 6.1.4 of this 681 specification. 683 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 684 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 686 The AS MUST use the URI constructed in the immediately preceding 687 substep as the value of the Identity-Info header that is added to 688 the SIP request message per Step 4 of Section 5 of [RFC4474]. 690 Upon successful completion of all of the above, the AS forwards the 691 request message. 693 At this point in this step, after perhaps traversing some number of 694 intermediaries, the SIP request message arrives at a SIP network 695 entity performing the "verifier" role. This role and its behavior 696 are specified in Section 6 "Verifier Behavior" of [RFC4474]. The 697 verifier MUST perform the steps enumerated in the aforementioned 698 section, with the following modifications: 700 Step 1 of [RFC4474] Section 6 maps to and is updated by, the 701 following two steps in this procedure. 703 Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this 704 latter portion of this step, and/or the following two steps, as 705 appropriate. 707 6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 709 The verifier SHOULD ascertain whether it has a current cached copy of 710 the SIP message sender's SAML assertion and domain certificate. If 711 not, or if the verifier chooses to (e.g., due to local policy), it 712 MUST dereference the the HTTP-based SAML URI Reference found in the 713 SIP message's Identity-Info header. To do so, the verifier MUST 714 employ the "SAML HTTP-URI-based SIP Binding" specified in 715 Section 7.1. 717 6.1.3.5. AS Returns SAML Assertion 719 This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 721 If the prior step returns an HTTP error (e.g., 4xx series), then this 722 procedure terminates and the verifier returns (upstream) a SIP 436 723 'Bad Identity-Info' Response code. 725 Otherwise, the HTTP response message will contain a SAML assertion 726 and be denoted as such via the MIME media type of "application/ 727 samlassertion+xml" [IANA.application.samlassertion-xml]. The 728 verifier MUST perform the verification steps specified in 729 Section 6.1.5 "Assertion Verification", below. If successful, then 730 this procedure continues with the next step. 732 6.1.3.6. Verifier performs Next Step 734 The SIP request was successfully processed. The verifier now 735 performs its next step, which depends at least in part on the type of 736 SIP request it received. 738 6.1.4. Assertion Profile Description 740 This section defines the particulars of how the sender, i.e., the 741 SAML Authority, MUST construct certain portions of the SAML 742 assertions it issues. The schema for SAML assertions themselves is 743 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 745 An example SAML assertion, formulated according to this profile is 746 given in Section 9. 748 Overall SAML assertion profile requirements: 750 The SAML assertion MUST be signed by the same key as used to sign 751 the contents of the Identity header field. Signing of SAML 752 assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. 754 In the following subsections, the SAML assertion profile is specified 755 element-by-element, in a top-down, depth-first manner, beginning with 756 the outermost element, "". Where applicable, the 757 requirements for an element's XML attributes are also stated, as a 758 part of the element's description. Requirements for any given 759 element or XML attribute are only stated when, in the context of use 760 of this profile, they are not already sufficiently defined by 761 [OASIS.saml-core-2.0-os]. 763 6.1.4.1. Element: 765 Attribute: ID 767 The value for the ID XML attribute SHOULD be allocated randomly 768 such that the value meets the randomness requirments specified in 769 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 771 Attribute: IssueInstant 773 The value for the IssueInstant XML attribute SHOULD be set at the 774 time the SAML assertion is created (and cached for subsequent 775 retrieval). This time instant value MAY be temporally the same as 776 that encoded in the SIP message's Date header, and MUST be at 777 least temporally later, although it is RECOMMENDED that it not be 778 10 minutes or more later. 780 6.1.4.1.1. Element: 782 The value for the Issuer XML element MUST be a value that matches 783 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 784 the certificate conveyed by the SAML assertion in the ds: 785 X509Certificate element located on this path within the SAML 786 assertion: 788 796 The element SHOULD contain both a element and a 797 element. 799 The value of the element MUST be the same as the Address of 800 Record (AoR) value used in computing the "signed-identity-digest" 801 which forms the value of the Identity header. See Section 9 of 802 [RFC4474]. 804 The element attribute Method SHOULD be set to 805 the value: 807 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 809 Although it MAY be set to some other implementation- and/or 810 deployment-specific value. The element itself 811 SHOULD be empty. 813 6.1.4.1.3. Element: 815 The element SHOULD contain an 816 element, which itself SHOULD contain an element. The 817 value of the element SHOULD be the same as the addr-spec 818 of the SIP request's To header field. 820 The following XML attributes of the element MUST be set 821 as follows: 823 Attribute: NotBefore 825 The value of the NotBefore XML attribute MUST be set to a time 826 instant the same as the value for the IssueInstant XML attribute 827 discussed above, or to a later time. 829 Attribute: NotOnOrAfter 831 The value of the NotOnOrAfter XML attribute MUST be set to a time 832 instant later than the value for NotBefore. 834 6.1.4.1.4. Element: 836 The SAML assertion MAY contain an element. If 837 so, the element will contain attribute-value 838 pairs, e.g., of a user profile nature, encoded according to either 839 one of the "SAML Attribute Profiles" as specified in 840 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 841 and/or deployment-specific attribute profile. 843 The attribute-value pairs SHOULD in fact pertain to the entity 844 identified in the SIP From header field, since a SAML assertion 845 formulated per this overall section is stating that they do. 847 6.1.5. Assertion Verification 849 This section specifies the steps that a verifier participating in 850 this profile MUST perform in addition to the "Verifier Behavior" 851 specified in Section 6 of [RFC4474]. 853 The steps are: 855 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 856 extract the AS's domain certificate from the XML element at the end of the element path 858 given in Section 6.1.4.1.1. 860 2. Perform Step 1 in Section 6 of [RFC4474]. 862 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 863 that section, the verifier MUST verify the SAML assertion's 864 signature via the procedures specified in Section 5.4 of 865 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 867 @@ TODO: do we need to define a new SIP error response code for 868 when a SAML assn signature is bad? e.g., '4xx Invalid SAML 869 asssertion'. 871 4. Perform Step 2 in Section 6 of [RFC4474]. 873 5. Verify that the signer of the SIP message's Identity header 874 field is the same as the signer of the SAML assertion. 876 6. Perform Steps 3 and 4 in Section 6 of [RFC4474]. 878 7. Verify that the SAML assertion's element value matches 879 the Issuer or the Issuer Alternative Name fields [RFC3280] in 880 the AS's domain certificate. 882 8. Verify that the SAML assertion's element value is the 883 same as the Address of Record (AoR) value in the "signed- 884 identity-digest". See Section 9 of [RFC4474]. 886 9. Verify that the SAML assertion's element 887 value is set to whichever value was configured at 888 implementation- or deployment-time. The default value is: 890 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 892 10. Verify that the SAML assertion contains an element, 893 and that its value matches the value of the addr-spec of the SIP 894 To header field. 896 11. Verify that the validity period denoted by the NotBefore and 897 NotOnOrAfter attributes of the element meets the 898 requirements given in Section 6.1.4.1.3. 900 6.2. The TBD "call-by-value" Profile 902 To-Be-Determined (TBD) 904 7. SAML SIP Binding 906 This section specifies one SAML SIP Binding at this time. Additional 907 bindings may be specified in future revisions of this specification. 909 7.1. SAML HTTP-URI-based SIP Binding 911 This section specifies the "SAML HTTP-URI-based SIP Binding", 912 (SHUSB). 914 The SHUSB is a profile of the "SAML URI Binding" specified in Section 915 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 916 a means by which SAML assertions can be referenced by URIs and thus 917 be obtained through resolution of such URIs. 919 This profile of the SAML URI Binding is congruent with the SAML URI 920 Binding -- including support for HTTP-based URIs being mandatory to 921 implement -- except for the following further restrictions which are 922 specified in the interest of interoperability (section numbers refer 923 to [OASIS.saml-bindings-2.0-os]): 925 Section 3.7.5.3 Security Considerations: 927 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 929 Section 3.7.5.4 Error Reporting: 931 All SHOULDs in this section are to be interpreted as MUSTs. 933 8. The 'saml-shusb' Option Tag 935 This document creates and IANA registers one new option tag: "saml- 936 shusb". This option tag is to be used, as defined in RFC 3261, in 937 the Require, Supported and Unsupported headers. It is used to 938 indicate support for this SIP extension, this option tag is included 939 in a Supported header of the SIP request. 941 9. Example SAML Assertions 943 This section presents two examples of a SAML assertion, one unsigned 944 (for clarity), the other signed (for accuracy). 946 In the first example, Figure 4, the assertion is attesting with 947 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 948 The validity conditions are expressed in lines 16-23, via both a 949 validity period expressed as temporal endpoints, and an "audience 950 restriction" stating that this assertion's semantics are valid for 951 only the relying party named "example2.com". Also, the assertion's 952 issuer is noted in lines 4-5. 954 The above items correspond to some aspects of this specification's 955 SAML assertion profile, as noted below in Security Considerations 956 dicussions, see: Section 10.1 and Section 10.2. 958 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 959 fashion, using LDAP/X.500 schema as the typing means. 961 1 964 4 965 5 example.com 966 6 967 7 968 8 971 11 Alice@example.com 972 12 973 13 975 15 976 16 978 18 979 19 980 20 example2.com 981 21 982 22 983 23 984 24 985 25 992 32 993 33 +1-888-555-1212 994 34 995 35 996 36 997 37 999 Figure 4: Unsigned SAML Assertion Illustrating Conveyance of 1000 Subject Attribute 1002 In the second example, Figure 5, the information described above is 1003 the same, the addition is that this version of the assertion is 1004 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 1006 integrity are assured. Since this assertion is the same as the one 1007 in the first example above, other than having a signature added, the 1008 second example below addresses the same Security Considerations 1009 aspects, plus those requiring a Signature. 1011 1 1014 4 1015 5 example.com 1016 6 1017 7 1018 8 1019 9 1021 11 1023 13 1025 15 1026 16 1029 19 1032 22 1036 26 1037 27 1038 28 1040 30 1041 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1042 32 1043 33 1044 34 1045 35 1046 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1047 37 1048 38 1049 39 1050 40 1051 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1052 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1053 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1054 44 1055 45 1056 46 1057 47 1058 48 1059 49 1062 52 Alice@example.com 1063 53 1064 54 1066 56 1067 57 1069 59 1070 60 1071 61 example2.com 1072 62 1073 63 1074 64 1075 65 1076 66 1083 73 1084 74 +1-888-555-1212 1085 75 1086 76 1087 77 1088 78 1090 Figure 5: Signed SAML Assertion Illustrating Conveyance of Subject 1091 Attribute 1093 10. Security Considerations 1095 This section discusses security considerations when using SAML with 1096 SIP. 1098 10.1. Man-in-the-Middle Attacks and Stolen Assertions 1100 Threat: 1102 By making SAML assertions available via HTTP-based requests by a 1103 potentially unbounded set of requesters, it is conceivably 1104 possible that anyone would be able to simply request one and 1105 obtain it. By SIP intermediaries on the signaling path for 1106 example. Or, an HTTP intermediary/proxy could intercept the 1107 assertion as it is being returned to a requester. 1109 The attacker could then conceivably attempt to impersonate the 1110 subject (the putative caller) to some SIP-based target entity. 1112 Countermeasures: 1114 Such an attack is implausible for several reasons. The primary 1115 reason is that a message constructed by an imposter using a stolen 1116 assertion that conveys the public key certificate of some domain 1117 will not verify per [RFC4474] because the imposter will not have 1118 the corresponding private key with which to generate the signed 1119 Identity header value. 1121 Also, the SIP SAML assertion profile specified herein that the 1122 subject's SAML assertion must adhere to causes it to be not useful 1123 to arbitrary parties. The subject's assertion: 1125 * should be signed, thus causing any alterations to break its 1126 integrity and make such alterations detectable. 1128 * relying party is represented in the SAML assertion's Audience 1129 Restriction. 1131 * Issuer is represented in the SAML assertion. 1133 * validity period for assertion is restricted. 1135 10.2. Forged Assertion 1136 Threat: 1138 A malicious user could forge or alter a SAML assertion in order to 1139 communicate with the SIP entities. 1141 Countermeasures: 1143 To avoid this kind of attack, the entities must assure that proper 1144 mechanisms for protecting the SAML assertion are employed, e.g., 1145 signing the SAML assertion itself. Section 5.1 of 1146 [OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. 1148 Additionally, the assertion content dictated by the SAML assertion 1149 profile herein ensures ample evidence for a relying party to 1150 verify the assertion and its relationship with the received SIP 1151 request. 1153 10.3. Replay Attack 1155 Threat: 1157 Theft of SIP message protected by the mechanisms described herein 1158 and replay of it at a later time. 1160 Countermeasures: 1162 There are various provisions within [RFC4474] that prevent a 1163 replay attack. 1165 11. Contributors 1167 The authors would like to thank Marcus Tegnander and Henning 1168 Schulzrinne for his contributions to earlier versions of this 1169 document. 1171 12. Acknowledgments 1173 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1174 Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki 1175 Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen 1176 Fries and Vijay Gurbani for their comments to this draft. The "AS- 1177 driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based 1178 on an idea by Jon Peterson. 1180 13. IANA Considerations 1182 13.1. IANA Registration for New SIP Option Tag 1184 The SIP option tag "saml-shusb" is created by this document, with the 1185 definition and rule in Section 4.4 of this document, to be added to 1186 sip-parameters within IANA. 1188 13.2. 477 'Use Identity Header with SAML Assertion' Response Code 1190 This document registers a new SIP response code. It is sent when a 1191 verifier receives a SIP request that lacks an Identity header with a 1192 SAML assertion in order to indicate that the request should be re- 1193 sent with an Identity header pointing to a SAML assertion. This 1194 response code is defined by the following information, which has been 1195 added to the method and response-code sub-registry under 1196 http://www.iana.org/assignments/sip-parameters. 1198 Response Code Number: 477 1200 Default Reason Phrase: Use Identity Header with SAML Assertion 1202 13.3. 478 'Unknown SAML Assertion Content' Response Code 1204 This document registers a new SIP response code. It is used when the 1205 verifier is unable to parse the content of the SAML assertion 1206 referenced by the URI of the Identity-Info header, because, for 1207 example, the assertion contains only unknown elements in in the SAML 1208 assertion, or the SAML assertion XML document is garbled. This 1209 response code is defined by the following information, which has been 1210 added to the method and response-code sub-registry under 1211 http://www.iana.org/assignments/sip-parameters. 1213 Response Code Number: 478 1215 Default Reason Phrase: Unknown SAML Assertion Content 1217 13.4. 479 'Invalid SAML Assertion' Response Code 1219 This document registers a new SIP response code. It is used when the 1220 verifier is unable to process the SAML assertion referenced by the 1221 URI of the Identity-Info header, because, for example, the assertion 1222 is self-signed, or signed by a root certificate authority for whom 1223 the verifier does not possess a root certificate. This response code 1224 is defined by the following information, which has been added to the 1225 method and response-code sub-registry under 1226 http://www.iana.org/assignments/sip-parameters. 1228 Response Code Number: 479 1230 Default Reason Phrase: Invalid SAML Assertion 1232 14. Open Issues 1234 A list of open issues can be found at: 1235 http://www.tschofenig.priv.at:8080/saml-sip/ 1237 15. Change Log 1239 RFC Editor - Please remove this section before publication. 1241 15.1. -03 to -04 1243 Updated IANA consideration section. 1245 Added option tag 1247 Updated acknowledgments section 1249 Minor editorial changes to the security considerations section 1251 15.2. -02 to -03 1253 Denoted that this I-D is intended to update RFC4474 per SIP working 1254 group consensus at IETF-69. This is the tact adopted in order to 1255 address the impedance mismatch between the nature of the URIs 1256 specified as to be placed in the Identity-Info header field, and what 1257 is specified in RFC4474 as the allowable value of that header field. 1259 Added placeholder "TBD" section for a to-be-determined "call-by- 1260 value" profile, per SIP working group consensus at IETF-69. 1262 Removed use-case appendicies (per recollection of JHodges during 1263 IETF-69 discussion as being WG consensus, but such is not noted in 1264 the minutes). 1266 15.3. -00 to -02 1268 Will detail in -04 rev. 1270 16. References 1272 16.1. Normative References 1274 [OASIS.saml-bindings-2.0-os] 1275 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1276 Maler, "Bindings for the OASIS Security Assertion Markup 1277 Language (SAML) V2.0", OASIS 1278 Standard saml-bindings-2.0-os, March 2005. 1280 [OASIS.saml-core-2.0-os] 1281 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1282 "Assertions and Protocol for the OASIS Security Assertion 1283 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1284 2.0-os, March 2005. 1286 [OASIS.saml-metadata-2.0-os] 1287 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1288 "Metadata for the Security Assertion Markup Language 1289 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1290 March 2005. 1292 [OASIS.saml-profiles-2.0-os] 1293 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1294 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1295 Security Assertion Markup Language (SAML) V2.0", OASIS 1296 Standard OASIS.saml-profiles-2.0-os, March 2005. 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, March 1997. 1301 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1302 Locators", RFC 2392, August 1998. 1304 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1305 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1306 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1308 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1309 A., Peterson, J., Sparks, R., Handley, M., and E. 1310 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1311 June 2002. 1313 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1314 X.509 Public Key Infrastructure Certificate and 1315 Certificate Revocation List (CRL) Profile", RFC 3280, 1316 April 2002. 1318 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1319 Method", RFC 3515, April 2003. 1321 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1322 IETF URN Sub-namespace for Registered Protocol 1323 Parameters", BCP 73, RFC 3553, June 2003. 1325 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1326 Authenticated Identity Body (AIB) Format", RFC 3893, 1327 September 2004. 1329 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1330 Authenticated Identity Management in the Session 1331 Initiation Protocol (SIP)", RFC 4474, August 2006. 1333 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1334 "Trait-Based Authorization Requirements for the Session 1335 Initiation Protocol (SIP)", RFC 4484, August 2006. 1337 [W3C.xmldsig-core] 1338 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1339 Syntax and Processing", W3C Recommendation xmldsig-core, 1340 October 2000, . 1342 16.2. Informative References 1344 [IANA.application.samlassertion-xml] 1345 OASIS Security Services Technical Committee (SSTC), 1346 "application/samlassertion+xml MIME Media Type 1347 Registration", IANA MIME Media Types Registry application/ 1348 samlassertion+xml, December 2004. 1350 [OASIS.saml-conformance-2.0-os] 1351 Mishra, P., Philpott, R., and E. Maler, "Conformance 1352 Requirements for the Security Assertion Markup Language 1353 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1354 March 2005. 1356 [OASIS.saml-glossary-2.0-os] 1357 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1358 Security Assertion Markup Language (SAML) V2.0", OASIS 1359 Standard saml-glossary-2.0-os, March 2005. 1361 [OASIS.saml-sec-consider-2.0-os] 1362 Hirsch, F., Philpott, R., and E. Maler, "Security and 1363 Privacy Considerations for the OASIS Security Markup 1364 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1365 2.0-os, March 2005. 1367 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1368 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1369 OASIS SSTC Committee 1370 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1372 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1373 Cantor, S., "SAML Protocol Extension for Third-Party 1374 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1375 ext-thirdparty-cd-01, March 2006. 1377 [OASIS.sstc-saml-tech-overview-2.0-draft-08] 1378 Hughes, J. and E. Maler, "Security Assertion Markup 1379 Language (SAML) V2.0 Technical Overview", OASIS SSTC 1380 Working Draft sstc-saml-tech-overview-2.0-draft-08, 1381 September 2005. 1383 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1384 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1385 March 1999. 1387 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1388 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1389 September 1999. 1391 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1392 Certificate Profile for Authorization", RFC 3281, 1393 April 2002. 1395 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1396 Initiation Protocol (SIP)", RFC 3323, November 2002. 1398 Authors' Addresses 1400 Hannes Tschofenig 1401 Nokia Siemens Networks 1402 Linnoitustie 6 1403 Espoo 02600 1404 Finland 1406 Phone: +358 (50) 4871445 1407 Email: Hannes.Tschofenig@gmx.net 1408 URI: http://www.tschofenig.priv.at 1410 Jeff Hodges 1411 NeuStar, Inc. 1412 2000 Broadway Street 1413 Redwood City, CA 94063 1414 US 1416 Email: Jeff.Hodges@neustar.biz 1418 Jon Peterson 1419 NeuStar, Inc. 1420 1800 Sutter St Suite 570 1421 Concord, CA 94520 1422 US 1424 Email: jon.peterson@neustar.biz 1426 James Polk 1427 Cisco 1428 2200 East President George Bush Turnpike 1429 Richardson, Texas 75082 1430 US 1432 Email: jmpolk@cisco.com 1434 Douglas C. Sicker 1435 University of Colorado at Boulder 1436 ECOT 430 1437 Boulder, CO 80309 1438 US 1440 Email: douglas.sicker@colorado.edu 1442 Full Copyright Statement 1444 Copyright (C) The IETF Trust (2008). 1446 This document is subject to the rights, licenses and restrictions 1447 contained in BCP 78, and except as set forth therein, the authors 1448 retain all their rights. 1450 This document and the information contained herein are provided on an 1451 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1452 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1453 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1454 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1455 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1456 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1458 Intellectual Property 1460 The IETF takes no position regarding the validity or scope of any 1461 Intellectual Property Rights or other rights that might be claimed to 1462 pertain to the implementation or use of the technology described in 1463 this document or the extent to which any license under such rights 1464 might or might not be available; nor does it represent that it has 1465 made any independent effort to identify any such rights. Information 1466 on the procedures with respect to rights in RFC documents can be 1467 found in BCP 78 and BCP 79. 1469 Copies of IPR disclosures made to the IETF Secretariat and any 1470 assurances of licenses to be made available, or the result of an 1471 attempt made to obtain a general license or permission for the use of 1472 such proprietary rights by implementers or users of this 1473 specification can be obtained from the IETF on-line IPR repository at 1474 http://www.ietf.org/ipr. 1476 The IETF invites any interested party to bring to its attention any 1477 copyrights, patents or patent applications, or other proprietary 1478 rights that may cover technology that may be required to implement 1479 this standard. Please address the information to the IETF at 1480 ietf-ipr@ietf.org.