idnits 2.17.00 (12 Aug 2021) /tmp/idnits31540/draft-ietf-sip-saml-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1534. 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 Copyright Line does not match the current year == Line 243 has weird spacing: '...ich the asser...' == Line 443 has weird spacing: '... where prox...' -- 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 (November 3, 2008) is 4947 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2392' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: 'RFC3553' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1452, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: May 7, 2009 Unaffiliated 6 J. Peterson 7 NeuStar, Inc. 8 J. Polk 9 Cisco 10 D. Sicker 11 CU Boulder 12 November 3, 2008 14 SIP SAML Profile and Binding 15 draft-ietf-sip-saml-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 7, 2009. 42 Abstract 44 This document specifies a Session Initiation Protocol (SIP) profile 45 of Security Assertion Markup Language (SAML) as well as a SAML SIP 46 binding. The defined SIP SAML Profile composes with the mechanisms 47 defined in the SIP Identity specification and satisfy requirements 48 presented in "Trait-based Authorization Requirements for the Session 49 Initiation Protocol (SIP)". 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 57 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 58 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 59 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 60 6. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 61 7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 16 62 7.1. AS-driven SIP SAML URI-based Attribute Assertion 63 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 16 64 7.1.1. Required Information . . . . . . . . . . . . . . . . . 16 65 7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 16 66 7.1.3. Profile Description . . . . . . . . . . . . . . . . . 20 67 7.1.4. Assertion Profile Description . . . . . . . . . . . . 23 68 7.1.5. Assertion Verification . . . . . . . . . . . . . . . . 25 69 7.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 27 70 8. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 28 71 8.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 28 72 9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 29 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 74 10.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 34 75 10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 34 76 10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 35 77 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 80 13.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 38 81 13.2. 477 'Binding to SIP Message failed' Response Code . . . . 38 82 13.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 38 83 13.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 38 84 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 85 14.1. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 40 86 14.2. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40 87 14.3. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40 88 14.4. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 41 89 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 90 15.1. Normative References . . . . . . . . . . . . . . . . . . . 42 91 15.2. Informative References . . . . . . . . . . . . . . . . . . 43 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 93 Intellectual Property and Copyright Statements . . . . . . . . . . 46 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-16] 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-16] 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 -- also known as a "SIP SAML 288 profile" -- such that a subject's profile attributes, and their 289 domain's certificate, can be conveyed to a relying party using 290 SAML. In doing so, satisfy the requirements outlined in 291 [RFC4484], and 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 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 SIP SAML Profiles defined in this document make use of concepts 344 defined by [RFC4474] "Enhancements for Authenticated Identity 345 Management in the Session Initiation Protocol (SIP)" -- also known as 346 "SIP Identity". In particular, they leverage the "mediated 347 authentication architecture" utilizing the Authentication Service 348 (AS). The overall semantic being that the AS is vouching that it did 349 indeed 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 The approach used by this document is similar to the one used for SIP 357 Identity. I.e. the AS creates a SAML assertion and makes it 358 available to the verifier via a reference, in the particular case of 359 the AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile. 360 Figure 1 illustrates this approach in a high-level summary fashion. 361 Figure 4, further below, illustrates additional details. In case of 362 the Assertion-by Value profile the SAML assertion is made available 363 to the verifying party directly without the additional step of 364 utilizing a reference. This approach is described in Section 7.2. 366 +--------+ +--------------+ +--------+ 367 |Alice@ | |Authentication| | Bob@ | 368 |example | |Service | |example2| 369 |.com | |@example.com | |.com | 370 | | | | | | 371 +---+----+ +------+-------+ +---+----+ 372 | | | 373 | INVITE | | 374 |---------------------->| | 375 | From:alice@foo.com | | 376 | | | 377 | 407 Proxy auth. req. | | 378 |<----------------------| | 379 | Challenge | | 380 | | | 381 | ACK | | 382 |---------------------->| | 383 | | | 384 | INVITE w/authn creds | | 385 |---------------------->| | 386 | | INVITE | 387 | | w/SAML-Info header | 388 | |--------------------->| 389 | | | 390 | | | 391 | | HTTP GET SAML assn | 392 | |<==================== | 393 | | | 394 | | | 395 | | HTTP 200 OK + assn | 396 | |=====================>| 397 | | | 398 | 200 OK | | 399 |<----------------------+----------------------| 400 | | | 402 Figure 1: SIP-SAML-based Network Asserted Identity 404 Figure 1 shows an exchange based on the AS-driven SIP SAML URI-based 405 Attribute Assertion Fetch Profile where the AS creates a SAML 406 assertion, creates a reference to it, and puts that reference into 407 the SAML-Info header before forwarding the SIP message. Bob in our 408 case acting as the verifier uses the reference to retrieve the SAML 409 assertion and verifies it. 411 6. Header Syntax 413 This document specifies the new SIP header "SAML-Info". This header 414 MAY appear in any SIP header and MAY also appear more than once. 416 The grammar for this header is (following the ABNF [RFC4234] in 417 section 25 of RFC 3261 [RFC3261]): 419 SAML-Info = 420 "SAML-Info" HCOLON ident-info *( SEMI ident-info-params ) 422 ident-info = LAQUOT absoluteURI RAQUOT 424 ident-info-params = generic-param 426 Figure 2: SAML-Info ABNF grammar 428 The "absoluteURI" portion of the SAML-Info header MUST contain a URI 429 which dereferences to a resource containing a SAML assertion. All 430 implementations of this specification MUST support the use of HTTP 431 and HTTPS URIs in the SAML-Info header. Such HTTP and HTTPS URIs 432 MUST follow the conventions of RFC 2585 [RFC2585], and for those URIs 433 the indicated resource MUST be of the form 'application/ 434 samlassertion+xml' described in that specification. 436 No parameters are defined for the SAML-Info header in this document. 437 Future Experimental RFCS may define additional SAML-Info header 438 parameters. 440 This document adds the following entries to Table 2 of RFC 3261 441 [RFC3261]: 443 Header field where proxy ACK BYE CAN INV OPT REG 444 ------------ ----- ----- --- --- --- --- --- --- 445 SAML-Info R a o o - o o o 447 SUB NOT REF INF UPD PRA 448 --- --- --- --- --- --- 449 o o o o o o 451 Figure 3: New SAML-Info Row for RFC3261 Table 2 453 The SAML-Info header MUST NOT appear in CANCEL. 455 7. SIP SAML Profiles 457 This section defines two "SIP SAML profiles": 459 o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 460 Profile" 462 o The "Assertion-by-value" Profile 464 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 466 7.1.1. Required Information 468 The information given in this section is similar to the info provided 469 when registering something, a MIME Media Type, say, with IANA. In 470 this case, it is for registering this profile with the OASIS SSTC. 471 See Section 2 "Specification of Additional Profiles" in 472 [OASIS.saml-profiles-2.0-os]. 474 Identification: 476 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 478 Contact Information: 480 Hannes Tschofenig (Hannes.Tschofenig@nsn.com) 482 SAML Confirmation Method Identifiers: 484 The SAML V2.0 confirmation method identifier is used in this 485 profile. 487 Description: 489 Given below. 491 Updates: 493 None. 495 7.1.2. Profile Overview 497 Figure 4 illustrates this profile's overall protocol flow. The 498 following steps correspond to the labeled interactions in the figure. 499 Within an individual step, there may be one or more actual message 500 exchanges depending upon the protocol binding employed for that 501 particular step and other implementation-dependent behavior. 503 Although this profile is overview is cast in terms of a SIP INVITE 504 transaction, the reader should note that the mechanism specified 505 herein, may be applied to any SIP request message. 507 Figure 4 begins on the next page. 509 +------------------+ +------------------+ +-----------------+ 510 | Caller | |Authn Service (AS)| | Callee | 511 |Alice@example.com | | @example.com | | Bob@example2.com| 512 +--------+---------+ +--------+---------+ +--------+--------+ 513 - - | | | (steps) 514 ^ ^ | INVITE | | 515 | | |---------------------->| | (1a) 516 | | From:alice@foo.com | | 517 | C | To:sip:bob@example.com| | 518 | S | | | 519 | e | 407 Proxy auth. req. | | 520 | q |<----------------------| | (1b) 521 | = | Challenge | | 522 | N | | | 523 | | ACK | | 524 | | |---------------------->| | (1c) 525 | V | | | 526 | - | | | 527 ^ | INVITE + authorization| | 528 D | | header w/ creds | | 529 | |---------------------->| | (2) 530 I | | From:alice@foo.com | | 531 | | To:sip:bob@example.com| | 532 A | Proxy-Authorization:..| | 533 C | | INVITE | 534 L S | |--------------------->| (3) 535 e | | From:alice@foo.com | 536 O q | | To:sip:bob@example2.com 537 | | | 538 G = | | SAML-Info: | 539 | | https://example.com| 540 | N | | /assns/?ID=abcde | 541 | | | | 542 | + | |URI resolution (eg. HTTP) 543 | | |<=====================| (4) 544 | 1 | | GET /assns/?ID=abcde | 545 | | | | 546 | | | | HTTP/1.1 200 OK | 547 | | | |=====================>| (5) 548 | | | | | 549 | | | | | 550 | | | | | 551 | | | | Alice@example.com 552 | | | | 553 | | | | 554 | | | | ... 555 | | | | 556 | | | | foo=bar | 557 | | | 200 OK | | 558 | V |<----------------------+----------------------| (6) 559 . - | | | 560 V 562 Figure 4: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 563 Transaction 565 Step 1. Initial SIP Transaction between Caller and AS 567 This optional initial step is comprised of substeps 1a, 1b, 568 and 1c in Figure 4. In this step, the caller, Alice, sends 569 a SIP request message, illustrated as an INVITE, indicating 570 Bob as the callee (1a), is subsequently challenged by the AS 571 (1b), and sends an ACK in response to the challenge (1c). 572 The latter message signals the completion of this SIP 573 transaction (which is an optional substep of this profile). 575 Step 2. Caller sends SIP Request Message with Authorization 576 Credentials to the AS 578 Alice then sends an INVITE message in response to the 579 challenge, or uses cached credentials for the domain if step 580 1 was skipped, as specified in [RFC4474] and [RFC3261]. 581 Depending on the chosen SIP security mechanism for client 582 authentication either digest authentication, client side 583 authentication of Transport Layer Security, or a combination 584 of both is used to provide the AS with a strong assurance 585 about the identity of Alice. 587 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 589 First, the AS authorizes the received INVITE message as 590 specified in [RFC4474] and [RFC3261]. If the authorization 591 is successful, the AS constructs and caches a SAML assertion 592 asserting Alice's profile attributes required by Bob's 593 domain (example2.com), and also containing a the domain's 594 (example.com) public key certificate, or a reference to it. 595 The AS constructs a HTTP-based SAML URI Reference 596 incorporating the assertion's Assertion ID (see Section 597 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as 598 the value for the SAML-Info header it adds to the INVITE 599 message. 601 The AS determines which profile attributes (if any) to 602 assert in the via local configuration 603 and/or obtaining example2.com's metadata 605 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 606 INVITE message to Bob. 608 Step 4. Callee Dereferences HTTP-based SAML URI Reference 610 Bob's UAC or SIP Proxy receives the message and begins 611 verifying it per the "Verifier Behavior" specified in 612 [RFC4474]. In order to accomplish this task, it needs to 613 obtain Alice's domain certificate. It obtains the HTTP- 614 based SAML URI Reference from the message's SAML-Info header 615 and dereferences it per Section 8.1. Note that this is not 616 a SIP message, but an HTTP message [RFC2616]. 618 Step 5. AS Returns SAML Assertion 620 Upon receipt of the above HTTP request, which contains an 621 embedded reference to Alice's SAML Assertion, Alice's AS 622 returns her assertion in an HTTP response message. 624 Upon receipt of Alice's SAML Assertion, the AS continues its 625 verification of the INVITE message. If successful, it 626 returns a 200 OK message directly to Alice. Otherwise it 627 returns an appropriate SIP error response. 629 Step 6. Callee Returns SIP 200 OK to Caller 631 If Bob determines, based upon Alice's identity as asserted 632 by the AS, and as further substantiated by the information 633 in the SAML assertion, to accept the INVITE, he returns a 634 SIP 200 OK message directly to Alice. 636 7.1.3. Profile Description 638 The following sections provide detailed definitions of the individual 639 profile steps. The relevant illustration is Figure 5, below. Note 640 that this profile is agnostic to the specific SIP request, and also 641 that the Sender and Authentication Service (AS) may be seperate or 642 co-located in actuality. 644 +------------------+ +------------------+ +------------------+ 645 | Sender | |Authn Service (AS)| | Verifier | 646 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 647 +--------+---------+ +--------+---------+ +--------+---------+ 648 | | | (steps) 649 | SIP Request | | 650 |---------------------->| | (1a) 651 | | | 652 | 407 Proxy auth. req. | | 653 |<----------------------| | (1b) 654 | Challenge | | 655 | | | 656 | ACK | | 657 |---------------------->| | (1c) 658 | | | 659 | | | 660 |SIP Req + authorization| | 661 | header w/ creds | | 662 |---------------------->| | (2) 663 | | | 664 | | | 665 | | SIP Req + SAML-Info | 666 | | | 667 | |--------------------->| (3) 668 | | | 669 | | URI resolution | 670 | |<=====================| (4) 671 | | (via HTTP) | 672 | | | 673 | | HTTP/1.1 200 OK | 674 | |=====================>| (5) 675 | | | 676 | | | 677 | | ? | (6) 678 | | | 680 Figure 5: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 682 7.1.3.1. Initial SIP Transaction between Sender and AS 684 This optional step maps to Steps 1 and 2 of Section 5 "Authentication 685 Service Behavior" of [RFC4474]. If the SIP request sent by the 686 caller in substep 1a is deemed insufficiently authenticated by the AS 687 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 688 authenticate the sender of the message. The particulars of how this 689 is accomplished depend upon implementation and/or deployment 690 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 691 in Figure 5 are non-normative and illustrative only. 693 7.1.3.2. Sender sends SIP Request Message with Authorization 694 Credentials to the AS 696 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 697 Behavior" of [RFC4474]. This request is presumed to be made in a 698 context such that the AS will not challenge it -- i.e., the AS will 699 consider the sender of the message to be authenticated. If this is 700 not true, then this procedure reverts back to Step 1, above. 702 Otherwise, the AS carries out all other processing of the message as 703 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 704 procedure procedes to the next step below. 706 7.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 708 This first portion of this step maps to Steps 3 and 4 of Section 5 709 "Authentication Service Behavior" of [RFC4474], which the AS MUST 710 perform, although with the following additional substeps: 712 The AS MUST construct a SAML assertion according to the "Assertion 713 Profile Description" specified in Section 7.1.4 of this 714 specification. 716 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 717 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 719 The AS MUST use the URI constructed in the immediately preceding 720 substep as the value of the SAML-Info header that is added to the 721 SIP request message. 723 Upon successful completion of all of the above, the AS forwards the 724 request message. 726 At this point in this step, after perhaps traversing some number of 727 intermediaries, the SIP request message arrives at a SIP network 728 entity performing the "verifier" role. This role and its behavior 729 are specified in Section 6 "Verifier Behavior" of [RFC4474]. The 730 verifier MUST perform the steps enumerated in the aforementioned 731 section, with the following modifications: 733 Step 1 of [RFC4474] Section 6 maps to and is updated by, the 734 following two steps in this procedure. 736 Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this 737 latter portion of this step, and/or the following two steps, as 738 appropriate. 740 7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 742 The verifier SHOULD ascertain whether it has a current cached copy of 743 the SIP message sender's SAML assertion and domain certificate. If 744 not, or if the verifier chooses to (e.g., due to local policy), it 745 MUST dereference the the HTTP-based SAML URI Reference found in the 746 SIP message's SAML-Info header. To do so, the verifier MUST employ 747 the "SAML HTTP-URI-based SIP Binding" specified in Section 8.1. 749 7.1.3.5. AS Returns SAML Assertion 751 This step also employs Section 8.1 "SAML HTTP-URI-based SIP Binding". 753 If the prior step returns an HTTP error (e.g., 4xx series), then this 754 procedure terminates and the verifier returns (upstream) a SIP 436 755 'Bad SAML-Info' Response code. 757 Otherwise, the HTTP response message will contain a SAML assertion 758 and be denoted as such via the MIME media type of "application/ 759 samlassertion+xml" [IANA.application.samlassertion-xml]. The 760 verifier MUST perform the verification steps specified in 761 Section 7.1.5 "Assertion Verification", below. If successful, then 762 this procedure continues with the next step. 764 7.1.3.6. Verifier performs Next Step 766 The SIP request was successfully processed. The verifier now 767 performs its next step, which depends at least in part on the type of 768 SIP request it received. 770 7.1.4. Assertion Profile Description 772 This section defines the particulars of how the sender, i.e., the 773 SAML Authority, MUST construct certain portions of the SAML 774 assertions it issues. The schema for SAML assertions themselves is 775 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 777 An example SAML assertion, formulated according to this profile is 778 given in Section 9. 780 Overall SAML assertion profile requirements: 782 When using an HTTPS URI then the SAML assertion does not 783 necessarily needs to be signed. If it is signed then it MUST be 784 signed by the same key that is used in the Transport Layer 785 Security mechanism utilized with HTTPS. Signing of SAML 786 assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. 788 In the following subsections, the SAML assertion profile is specified 789 element-by-element, in a top-down, depth-first manner, beginning with 790 the outermost element, "". Where applicable, the 791 requirements for an element's XML attributes are also stated, as a 792 part of the element's description. Requirements for any given 793 element or XML attribute are only stated when, in the context of use 794 of this profile, they are not already sufficiently defined by 795 [OASIS.saml-core-2.0-os]. 797 7.1.4.1. Element: 799 Attribute: ID 801 The value for the ID XML attribute SHOULD be allocated randomly 802 such that the value meets the randomness requirments specified in 803 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 805 Attribute: IssueInstant 807 The value for the IssueInstant XML attribute SHOULD be set at the 808 time the SAML assertion is created (and cached for subsequent 809 retrieval). This time instant value MAY be temporally the same as 810 that encoded in the SIP message's Date header, and MUST be at 811 least temporally later, although it is RECOMMENDED that it not be 812 10 minutes or more later. 814 7.1.4.1.1. Element: 816 The value for the Issuer XML element MUST be a value that matches 817 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 818 the certificate conveyed by the SAML assertion in the ds: 819 X509Certificate element located on this path within the SAML 820 assertion: 822 830 The element SHOULD contain both a element and a 831 element. 833 The value of the element MUST be the Address of Record 834 (AoR). 836 The element attribute Method SHOULD be set to 837 the value: 839 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 841 Although it MAY be set to some other implementation- and/or 842 deployment-specific value. The element itself 843 SHOULD be empty. 845 7.1.4.1.3. Element: 847 The element SHOULD contain an 848 element, which itself SHOULD contain an element. When 849 included the value of the element MUST be the same as the 850 addr-spec of the SIP request's To header field. 852 The following XML attributes of the element MUST be set 853 as follows: 855 Attribute: NotBefore 857 The value of the NotBefore XML attribute MUST be set to a time 858 instant the same as the value for the IssueInstant XML attribute 859 discussed above, or to a later time. 861 Attribute: NotOnOrAfter 863 The value of the NotOnOrAfter XML attribute MUST be set to a time 864 instant later than the value for NotBefore. 866 7.1.4.1.4. Element: 868 The SAML assertion MAY contain an element. If 869 so, the element will contain attribute-value 870 pairs, e.g., of a user profile nature, encoded according to either 871 one of the "SAML Attribute Profiles" as specified in 872 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 873 and/or deployment-specific attribute profile. 875 The attribute-value pairs SHOULD in fact pertain to the entity 876 identified in the SIP From header field, since a SAML assertion 877 formulated per this overall section is stating that they do. 879 7.1.5. Assertion Verification 881 This section specifies the steps that a verifier participating in 882 this profile MUST perform in addition to the "Verifier Behavior" 883 specified in Section 6 of [RFC4474]. 885 The steps are: 887 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 888 extract the AS's domain certificate from the XML element at the end of the element path 890 given in Section 7.1.4.1.1. 892 2. Perform Step 1 in Section 6 of [RFC4474]. 894 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 895 that section, the verifier MUST verify the SAML assertion's 896 signature via the procedures specified in Section 5.4 of 897 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 899 The 479 'Invalid SAML Assertion' response code is used when the 900 verifier is unable to process the SAML assertion. 902 4. Perform Step 2 in Section 6 of [RFC4474]. 904 5. Verify that the signer of the SIP message's Identity header 905 field is the same as the signer of the SAML assertion. 907 6. Verify that the content of the SAML assertion matches with the 908 information carried in the SIP message. This may include the 909 following checks: 911 7. Verify that the SAML assertion's element value matches 912 the Issuer or the Issuer Alternative Name fields [RFC3280] in 913 the AS's domain certificate. 915 8. Verify that the SAML assertion's element value is the 916 same as the Address of Record (AoR) value. 918 9. Verify that the SAML assertion's element 919 value is set to whichever value was configured at 920 implementation- or deployment-time. The default value is: 922 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 924 10. Verify that the SAML assertion contains an element, 925 and that its value matches the value of the addr-spec of the SIP 926 To header field. 928 11. Verify that the validity period denoted by the NotBefore and 929 NotOnOrAfter attributes of the element meets the 930 requirements given in Section 7.1.4.1.3. 932 7.2. Caller-driven SIP SAML Conveyed Assertion Profile 934 For the "Assertion-by-value" profile we assume that a SAML assertion 935 is obtained out-of-band and attached to the body of the SIP message. 936 Note that any SIP message may be used to convey the SAML assertion 937 even though SIP INVITE may be the most appropriate candiate. The 938 verification step described in Section 7.1.5 is applicable to this 939 profile as well as the description on the content of the assertion 940 illustrated in Section 7.1.4. 942 8. SAML SIP Binding 944 This section specifies one SAML SIP Binding at this time. Additional 945 bindings may be specified in future revisions of this specification. 946 The description in Section 7.1.4 is applicable to this profile. 948 8.1. SAML HTTP-URI-based SIP Binding 950 This section specifies the "SAML HTTP-URI-based SIP Binding", 951 (SHUSB). 953 The SHUSB is a profile of the "SAML URI Binding" specified in Section 954 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 955 a means by which SAML assertions can be referenced by URIs and thus 956 be obtained through resolution of such URIs. 958 This profile of the SAML URI Binding is congruent with the SAML URI 959 Binding -- including support for HTTP-based URIs being mandatory to 960 implement -- except for the following further restrictions which are 961 specified in the interest of interoperability (section numbers refer 962 to [OASIS.saml-bindings-2.0-os]): 964 Section 3.7.5.3 Security Considerations: 966 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 968 Section 3.7.5.4 Error Reporting: 970 All SHOULDs in this section are to be interpreted as MUSTs. 972 9. Example SAML Assertions 974 This section presents two examples of a SAML assertion, one unsigned 975 (for clarity), the other signed (for accuracy). 977 In the first example, Figure 6, the assertion is attesting with 978 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 979 The validity conditions are expressed in lines 16-23, via both a 980 validity period expressed as temporal endpoints, and an "audience 981 restriction" stating that this assertion's semantics are valid for 982 only the relying party named "example2.com". Also, the assertion's 983 issuer is noted in lines 4-5. 985 The above items correspond to some aspects of this specification's 986 SAML assertion profile, as noted below in Security Considerations 987 dicussions, see: Section 10.1 and Section 10.2. 989 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 990 fashion, using LDAP/X.500 schema as the typing means. 992 1 995 4 996 5 example.com 997 6 998 7 999 8 1002 11 Alice@example.com 1003 12 1004 13 1006 15 1007 16 1009 18 1010 19 1011 20 example2.com 1012 21 1013 22 1014 23 1015 24 1016 25 1023 32 1024 33 +1-888-555-1212 1025 34 1026 35 1027 36 1028 37 1030 Figure 6: Unsigned SAML Assertion Illustrating Conveyance of 1031 Subject Attribute 1033 In the second example, Figure 7, the information described above is 1034 the same, the addition is that this version of the assertion is 1035 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 1037 integrity are assured. Since this assertion is the same as the one 1038 in the first example above, other than having a signature added, the 1039 second example below addresses the same Security Considerations 1040 aspects, plus those requiring a Signature. 1042 1 1045 4 1046 5 example.com 1047 6 1048 7 1049 8 1050 9 1052 11 1054 13 1056 15 1057 16 1060 19 1063 22 1067 26 1068 27 1069 28 1071 30 1072 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1073 32 1074 33 1075 34 1076 35 1077 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1078 37 1079 38 1080 39 1081 40 1082 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1083 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1084 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1085 44 1086 45 1087 46 1088 47 1089 48 1090 49 1093 52 Alice@example.com 1094 53 1095 54 1097 56 1098 57 1100 59 1101 60 1102 61 example2.com 1103 62 1104 63 1105 64 1106 65 1107 66 1114 73 1115 74 +1-888-555-1212 1116 75 1117 76 1118 77 1119 78 1121 Figure 7: Signed SAML Assertion Illustrating Conveyance of Subject 1122 Attribute 1124 10. Security Considerations 1126 This section discusses security considerations when using SAML with 1127 SIP. 1129 10.1. Man-in-the-Middle Attacks and Stolen Assertions 1131 Threat: 1133 By making SAML assertions available via HTTP-based requests by a 1134 potentially unbounded set of requesters, it is conceivably 1135 possible that anyone would be able to simply request one and 1136 obtain it. By SIP intermediaries on the signaling path for 1137 example. Or, an HTTP intermediary/proxy could intercept the 1138 assertion as it is being returned to a requester. 1140 The attacker could then conceivably attempt to impersonate the 1141 subject (the putative caller) to some SIP-based target entity. 1143 Countermeasures: 1145 Such an attack is implausible for several reasons. The primary 1146 reason is that a message constructed by an imposter using a stolen 1147 assertion that conveys the public key certificate of some domain 1148 will not verify because the values in the SAML assertion, which 1149 are tied to the SIP message, will not verify. 1151 Also, the SIP SAML assertion profile specified herein that the 1152 subject's SAML assertion must adhere to causes it to be not useful 1153 to arbitrary parties. The subject's assertion: 1155 * should be signed, thus causing any alterations to break its 1156 integrity and make such alterations detectable. 1158 * relying party is represented in the SAML assertion's Audience 1159 Restriction. 1161 * Issuer is represented in the SAML assertion. 1163 * validity period for assertion is restricted. 1165 10.2. Forged Assertion 1167 Threat: 1169 A malicious user could forge or alter a SAML assertion in order to 1170 communicate with the SIP entities. 1172 Countermeasures: 1174 To avoid this kind of attack, the entities must assure that proper 1175 mechanisms for protecting the SAML assertion are employed, e.g., 1176 signing the SAML assertion itself or protecting the transport of 1177 the SAML assertion from the AS to the verifying party using TLS. 1178 Section 5.1 of [OASIS.saml-core-2.0-os] specifies the signing of 1179 SAML assertions. 1181 Additionally, the assertion content dictated by the SAML assertion 1182 profile herein ensures ample evidence for a relying party to 1183 verify the assertion and its relationship with the received SIP 1184 request. 1186 10.3. Replay Attack 1188 Threat: 1190 Theft of SIP message protected by the mechanisms described herein 1191 and replay of it at a later time. 1193 Countermeasures: 1195 The SAML assertion may contain several elements to prevent replay 1196 attacks. There is, however, a clear tradeoff between the 1197 replaying an assertion and re-using it over multiple SIP 1198 exchanges/sessions. 1200 11. Contributors 1202 The authors would like to thank Marcus Tegnander and Henning 1203 Schulzrinne for his contributions to earlier versions of this 1204 document. 1206 12. Acknowledgments 1208 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1209 Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki 1210 Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen 1211 Fries and Vijay Gurbani for their comments to this draft. The "AS- 1212 driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based 1213 on an idea by Jon Peterson. 1215 13. IANA Considerations 1217 13.1. Header Field Names 1219 This document specifies the new SIP header 'SAML-Info'. Their syntax 1220 is given in Section 9. This header is defined by the following 1221 information, which has been added to the header sub-registry under 1222 http://www.iana.org/assignments/sip-parameters. 1224 Header Name: SAML-Info 1226 Compact Form: y 1228 13.2. 477 'Binding to SIP Message failed' Response Code 1230 This document registers a new SIP response code. It is sent when a 1231 verifier receives a SAML assertion but the Subject and Condition 1232 elements cannot be matched to the content in the SIP message, i.e., 1233 the binding between the SIP message and the SAML assertion cannot be 1234 accomplished. This response code is defined by the following 1235 information, which has been added to the method and response-code 1236 sub-registry under http://www.iana.org/assignments/sip-parameters. 1238 Response Code Number: 477 1240 Default Reason Phrase: Binding to SIP Message failed 1242 13.3. 478 'Unknown SAML Assertion Content' Response Code 1244 This document registers a new SIP response code. It is used when the 1245 verifier is unable to parse the content of the SAML assertion, 1246 because, for example, the assertion contains only unknown elements in 1247 in the SAML assertion, or the SAML assertion XML document is garbled. 1248 This response code is defined by the following information, which has 1249 been added to the method and response-code sub-registry under 1250 http://www.iana.org/assignments/sip-parameters. 1252 Response Code Number: 478 1254 Default Reason Phrase: Unknown SAML Assertion Content 1256 13.4. 479 'Invalid SAML Assertion' Response Code 1258 This document registers a new SIP response code. It is used when the 1259 verifier is unable to process the SAML assertion. A verifier may be 1260 unable to process the SAML assertion in case the assertion is self- 1261 signed, or signed by a root certificate authority for whom the 1262 verifier does not possess a root certificate. This response code is 1263 defined by the following information, which has been added to the 1264 method and response-code sub-registry under 1265 http://www.iana.org/assignments/sip-parameters. 1267 Response Code Number: 479 1269 Default Reason Phrase: Invalid SAML Assertion 1271 14. Change Log 1273 RFC Editor - Please remove this section before publication. 1275 14.1. -04 to -05 1277 Changed the document type to experimental 1279 Removed option tag 1281 Added the Caller-driven SIP SAML Conveyed Assertion Profile 1283 Defined a new header (SAML-Info) 1285 Changed the description for usage with this new header 1287 Updated security considerations 1289 Minor editorial cleanups 1291 14.2. -03 to -04 1293 Updated IANA consideration section. 1295 Added option tag 1297 Updated acknowledgments section 1299 Minor editorial changes to the security considerations section 1301 14.3. -02 to -03 1303 Denoted that this I-D is intended to update RFC4474 per SIP working 1304 group consensus at IETF-69. This is the tact adopted in order to 1305 address the impedance mismatch between the nature of the URIs 1306 specified as to be placed in the Identity-Info header field, and what 1307 is specified in RFC4474 as the allowable value of that header field. 1309 Added placeholder "TBD" section for a to-be-determined "call-by- 1310 value" profile, per SIP working group consensus at IETF-69. 1312 Removed use-case appendicies (per recollection of JHodges during 1313 IETF-69 discussion as being WG consensus, but such is not noted in 1314 the minutes). 1316 14.4. -00 to -02 1318 Will detail in -04 rev. 1320 15. References 1322 15.1. Normative References 1324 [OASIS.saml-bindings-2.0-os] 1325 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1326 Maler, "Bindings for the OASIS Security Assertion Markup 1327 Language (SAML) V2.0", OASIS 1328 Standard saml-bindings-2.0-os, March 2005. 1330 [OASIS.saml-core-2.0-os] 1331 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1332 "Assertions and Protocol for the OASIS Security Assertion 1333 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1334 2.0-os, March 2005. 1336 [OASIS.saml-metadata-2.0-os] 1337 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1338 "Metadata for the Security Assertion Markup Language 1339 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1340 March 2005. 1342 [OASIS.saml-profiles-2.0-os] 1343 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1344 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1345 Security Assertion Markup Language (SAML) V2.0", OASIS 1346 Standard OASIS.saml-profiles-2.0-os, March 2005. 1348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1349 Requirement Levels", BCP 14, RFC 2119, March 1997. 1351 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1352 Locators", RFC 2392, August 1998. 1354 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1355 Infrastructure Operational Protocols: FTP and HTTP", 1356 RFC 2585, May 1999. 1358 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1359 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1360 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1362 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1363 A., Peterson, J., Sparks, R., Handley, M., and E. 1364 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1365 June 2002. 1367 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1368 X.509 Public Key Infrastructure Certificate and 1369 Certificate Revocation List (CRL) Profile", RFC 3280, 1370 April 2002. 1372 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1373 Method", RFC 3515, April 2003. 1375 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1376 IETF URN Sub-namespace for Registered Protocol 1377 Parameters", BCP 73, RFC 3553, June 2003. 1379 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1380 Authenticated Identity Body (AIB) Format", RFC 3893, 1381 September 2004. 1383 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1384 Specifications: ABNF", RFC 4234, October 2005. 1386 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1387 Authenticated Identity Management in the Session 1388 Initiation Protocol (SIP)", RFC 4474, August 2006. 1390 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1391 "Trait-Based Authorization Requirements for the Session 1392 Initiation Protocol (SIP)", RFC 4484, August 2006. 1394 [W3C.xmldsig-core] 1395 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1396 Syntax and Processing", W3C Recommendation xmldsig-core, 1397 October 2000, . 1399 15.2. Informative References 1401 [IANA.application.samlassertion-xml] 1402 OASIS Security Services Technical Committee (SSTC), 1403 "application/samlassertion+xml MIME Media Type 1404 Registration", IANA MIME Media Types Registry application/ 1405 samlassertion+xml, December 2004. 1407 [OASIS.saml-conformance-2.0-os] 1408 Mishra, P., Philpott, R., and E. Maler, "Conformance 1409 Requirements for the Security Assertion Markup Language 1410 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1411 March 2005. 1413 [OASIS.saml-glossary-2.0-os] 1414 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1415 Security Assertion Markup Language (SAML) V2.0", OASIS 1416 Standard saml-glossary-2.0-os, March 2005. 1418 [OASIS.saml-sec-consider-2.0-os] 1419 Hirsch, F., Philpott, R., and E. Maler, "Security and 1420 Privacy Considerations for the OASIS Security Markup 1421 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1422 2.0-os, March 2005. 1424 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1425 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1426 OASIS SSTC Committee 1427 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1429 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1430 Cantor, S., "SAML Protocol Extension for Third-Party 1431 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1432 ext-thirdparty-cd-01, March 2006. 1434 [OASIS.sstc-saml-tech-overview-2.0-draft-16] 1435 Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, 1436 P., and T. Scavo, "Security Assertion Markup Language 1437 (SAML) V2.0 Technical Overview", OASIS SSTC Working 1438 Draft sstc-saml-tech-overview-2.0-draft-16, May 2008. 1440 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1441 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1442 March 1999. 1444 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1445 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1446 September 1999. 1448 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1449 Certificate Profile for Authorization", RFC 3281, 1450 April 2002. 1452 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1453 Initiation Protocol (SIP)", RFC 3323, November 2002. 1455 Authors' Addresses 1457 Hannes Tschofenig 1458 Nokia Siemens Networks 1459 Linnoitustie 6 1460 Espoo 02600 1461 Finland 1463 Phone: +358 (50) 4871445 1464 Email: Hannes.Tschofenig@gmx.net 1465 URI: http://www.tschofenig.priv.at 1467 Jeff Hodges 1468 Unaffiliated 1470 Email: Jeff.Hodges@KingsMountain.com 1472 Jon Peterson 1473 NeuStar, Inc. 1474 1800 Sutter St Suite 570 1475 Concord, CA 94520 1476 US 1478 Email: jon.peterson@neustar.biz 1480 James Polk 1481 Cisco 1482 2200 East President George Bush Turnpike 1483 Richardson, Texas 75082 1484 US 1486 Email: jmpolk@cisco.com 1488 Douglas C. Sicker 1489 University of Colorado at Boulder 1490 ECOT 430 1491 Boulder, CO 80309 1492 US 1494 Email: douglas.sicker@colorado.edu 1496 Full Copyright Statement 1498 Copyright (C) The IETF Trust (2008). 1500 This document is subject to the rights, licenses and restrictions 1501 contained in BCP 78, and except as set forth therein, the authors 1502 retain all their rights. 1504 This document and the information contained herein are provided on an 1505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1507 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1508 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1509 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1512 Intellectual Property 1514 The IETF takes no position regarding the validity or scope of any 1515 Intellectual Property Rights or other rights that might be claimed to 1516 pertain to the implementation or use of the technology described in 1517 this document or the extent to which any license under such rights 1518 might or might not be available; nor does it represent that it has 1519 made any independent effort to identify any such rights. Information 1520 on the procedures with respect to rights in RFC documents can be 1521 found in BCP 78 and BCP 79. 1523 Copies of IPR disclosures made to the IETF Secretariat and any 1524 assurances of licenses to be made available, or the result of an 1525 attempt made to obtain a general license or permission for the use of 1526 such proprietary rights by implementers or users of this 1527 specification can be obtained from the IETF on-line IPR repository at 1528 http://www.ietf.org/ipr. 1530 The IETF invites any interested party to bring to its attention any 1531 copyrights, patents or patent applications, or other proprietary 1532 rights that may cover technology that may be required to implement 1533 this standard. Please address the information to the IETF at 1534 ietf-ipr@ietf.org.