idnits 2.17.1 draft-ietf-sip-saml-03.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 1415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1439. 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 240 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 (November 18, 2007) is 5997 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 1239, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1256, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-content-indirect-mech' is defined on line 1282, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-certs' is defined on line 1288, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-sipping-pay' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-message-identity' is defined on line 1299, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1344, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1356, 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 (~~), 10 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: May 21, 2008 NeuStar, Inc. 7 J. Polk 8 Cisco 9 D. Sicker 10 CU Boulder 11 November 18, 2007 13 SIP SAML Profile and Binding 14 draft-ietf-sip-saml-03.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 May 21, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document specifies a Session Initiation Protocol (SIP) profile 48 of Security Assertion Markup Language (SAML) as well as a SAML SIP 49 binding. The defined SIP SAML Profile composes with the mechanisms 50 defined in the SIP Identity specification and satisfy requirements 51 presented in "Trait-based Authorization Requirements for the Session 52 Initiation Protocol (SIP)". 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 8 61 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9 62 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 11 63 6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 13 64 6.1. AS-driven SIP SAML URI-based Attribute Assertion 65 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1.1. Required Information . . . . . . . . . . . . . . . . . 13 67 6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 13 68 6.1.3. Profile Description . . . . . . . . . . . . . . . . . 17 69 6.1.4. Assertion Profile Description . . . . . . . . . . . . 20 70 6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 22 71 6.2. The TBD "call-by-value" Profile . . . . . . . . . . . . . 24 72 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 25 73 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 25 74 8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 26 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 76 9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 31 77 9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 32 78 9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 32 79 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 82 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37 84 14.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 37 85 14.2. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 37 86 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 87 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 88 15.2. Informative References . . . . . . . . . . . . . . . . . . 39 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 90 Intellectual Property and Copyright Statements . . . . . . . . . . 43 92 1. Introduction 94 This document specifies composition of the Security Assertion Markup 95 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 96 richer authorization mechanisms and enable "trait-based 97 authorization." Trait-based authorization is where one is authorized 98 to make use of some resource based on roles or traits rather than 99 ones identifier(s). Motivations for trait-based authorization, along 100 with use-case scenarios, are presented in [RFC4484]. 102 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 103 based framework for creating and exchanging security information. 104 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 105 [OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative 106 overviews of SAMLv2. The SAMLv2 specification set is normatively 107 defined by [OASIS.saml-conformance-2.0-os]. 109 Various means of providing trait-based authorization exist: 110 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 111 to the authenticated identity body [RFC3893]. The authors selected 112 SAML due to its increasing use in environments such as the Liberty 113 Alliance, and the Internet2 project, areas where the applicability to 114 SIP is widely desired. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 The SIP network element "Authentication Service" is introduced in 123 [RFC4474]. We reuse this term to refer to a network element that 124 authenticates and authorizes a user and creates a "SIP identity 125 assertion". This system entity is the logical equivalent of a "SAML 126 Authority" in the SAML terminology. 128 For overall SIP terminology, see [RFC3261]. 130 In this specification, the term, or term component, "SAML" refers to 131 SAML V2.0 in all cases. For example, the term "SAML assertion" 132 implicitly means "SAMLv2 assertion". For overall SAML terminology, 133 see [OASIS.saml-glossary-2.0-os]. 135 The below list maps other various SIP terms to their SAML 136 (rough-)equivalents: 138 Element, Network Element: 140 System Entity, Entity 142 Authentication Service: 144 SAML Authority 146 Invitee, Invited User, Called Party, Callee: 148 Relying Party 150 Server, User Agent Server (UAS): 152 SAML Responder 154 User Agent Client (UAC), client: 156 SAML Requester 158 Additional terms defined in the context of this specification: 160 profile attribute(s): 162 one or more attributes of a "user profile". 164 user profile, subject profile: 166 the set of various attributes accompanying (i.e., mapped to) a 167 user account in many environments. 169 3. SAML Introduction 171 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 172 [OASIS.sstc-saml-tech-overview-2.0-draft-08] defines an XML-based 173 framework for exchanging "security assertions" between entities. In 174 the course of making, or relying upon such assertions, SAML system 175 entities may use SAML protocols, or other protocols, to communicate 176 an assertion itself, or the subject of an assertion. 178 Thus one can employ SAML to make and encode statements such as "Alice 179 has these profile attributes and her domain's certificate is 180 available over there, and I'm making this statement, and here's who I 181 am." Then one can cause such an assertion to be conveyed to some 182 party who can then rely on it in some fashion for some purpose, for 183 example input it into some local policy evaluation for access to some 184 resource. This is done in a particular "context of use". Such a 185 context of use could be, for example, deciding whether to accept and 186 act upon a SIP-based invitation to initiate a communication session. 188 The specification of how SAML is employed in a particular context of 189 use is known as a "SAML profile". The specification of how SAML 190 assertions and/or protocol messages are conveyed in, or over, another 191 protocol is known as a "SAML Binding". Typically, a SAML profile 192 specifies the SAML bindings that may be used in its context. Both 193 SAML profiles and SAML bindings reference other SAML specifications, 194 especially the SAML Assertions and Protocols, aka "SAML Core", 195 specification [OASIS.saml-core-2.0-os]. 197 There is an additional subtle aspect of SAML profiles that is worth 198 highlighting -- the notion of a "SAML assertion profile". A SAML 199 assertion profile is the specification of the assertion contents in 200 the context of a particular SAML profile. It is possibly further 201 qualified by a particular implementation and/or deployment context. 202 Condensed examples of SAML assertion profiles are: 204 o The SAML assertion must contain at least one authentication 205 statement and no other statements. The relying party must be 206 represented in the element. The 207 SubjectConfirmation Method must be Foo. etc. 209 o The SAML assertion must contain at least one attribute statement 210 and may contain more than one. The values for the subject's 211 profile attributes named "Foo" and "Bar" must be present. An 212 authentication statement may be present. etc. 214 The primary facets of SAML itself are: 216 o Assertions 218 o Abstract Request/Response protocol 220 We describe each in turn below: 222 3.1. SAML Assertions 224 A SAML assertion is a package of information including issuer and 225 subject, conditions and advice, and/or attribute statements, and/or 226 authentication statements and/or other statements. Statements may or 227 may not be present. The SAML assertion "container" itself contains 228 the following information: 230 Issuing information: 232 Who issued the assertion, when was it issued and the assertion 233 identifier. 235 Subject information: 237 The name of the subject, the security domain and optional subject 238 information, like public key. 240 Conditions under which the assertion is valid: 242 Special kind of conditions like assertion validity period, 243 audience restriction and target restriction. 245 Additional advice: 247 Explaining how the assertion was made, for example. 249 In terms of SAML assertions containing SAML attribute statements or 250 SAML authentication statements, here are explanatory examples: 252 With a SAML assertion containing a SAML attribute statement, an 253 issuing authority is asserting that the subject is associated with 254 certain attributes with certain subject profile attribute values. 255 For example, user jon@cs.example.com is associated with the 256 attribute "Department", which has the value "Computer Science". 258 With a SAML assertion containing a SAML authentication statement, 259 an issuing authority is asserting that the subject was 260 authenticated by certain means at a certain time. 262 With a SAML assertion containing both a SAML attribute statement 263 and a SAML authentication statement, an issuing authority is 264 asserting the union of the above. 266 3.2. Abstract Request/Response Protocol 268 SAML defines an abstract request/response protocol for obtaining 269 assertions. See Section 3 "SAML Protocols" of 270 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 271 response returns the requested assertion or an error. This abstract 272 protocol may then be cast into particular contexts of use by binding 273 it to specific underlying protocols, e.g., HTTP or SIP, and 274 "profiling" it for the specific use case at hand. The SAML HTTP- 275 based web single sign-on profile is one such example (see Section 4.1 276 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 277 based SIP communication session establishment, the topic of this 278 specification, is another. 280 4. Specification Scope 282 The scope of this specification is: 284 o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such 285 that a subject's profile attributes, and their domain's 286 certificate, can be conveyed to a relying party using SAML. In 287 doing so, satisfy the requirements outlined in [RFC4484], and 288 compose with [RFC4474]. 290 The following are outside the scope of this specification: 292 o Defining a means for configuring the runtime behavior, or 293 deployment characteristics, of the Authentication Service. 295 Discussion: 297 For example, a SIP Authentication Service could be implemented 298 such that its SAML-based features are employed, or not, on a 299 subject-by-subject basis, and/or on a domain-by-domain basis. 301 o The definition of specific conveyed subject profile attributes 302 (aka traits). 304 Discussion: 306 This specification defines a facility enabling "trait-based 307 authorization" as discussed in [RFC4484]. 309 The attributes of interest in trait-based authorization will be 310 ones akin to, for example: roles, organizational membership, 311 access rights, or authentication event context. Definition of 312 such attributes is application- and/or deployment-context- 313 dependent and are not defined in this specification. However, The 314 SAMLv2 specification defines several "SAML Attribute Profiles" for 315 encoding attributes from various application domains, e.g., LDAP, 316 UUID/GUID, DCE PAC, and XACML, in SAML assertions 317 [OASIS.saml-profiles-2.0-os]. 319 In order for any trait-based system to be practical, participating 320 entities must agree on attributes and traits that will be conveyed 321 and subsequently relied upon. Without such agreements, a trait- 322 based system cannot be usefully deployed. This specification does 323 not discuss the manner in which participating entites might 324 discover one another or agree on the syntax and semantics of 325 attributes and traits. 327 Note that SAMLv2 specifies a "metadata" facility that may be 328 useful in addressing this need. 330 5. Employing SAML in SIP 332 Employing SAML in SIP necessitates devising a new SAML profile(s) and 333 binding(s) because the those already specified in the SAMLv2 334 specification set are specific to other use contexts, e.g., HTTP- 335 based web browsing. Although SIP bears some similarity to HTTP, it 336 is a seperately distinct protocol, thus requiring specification of 337 SIP-specific SAML profile(s) and binding(s). This is technically 338 straightforward as both SAML and SIP are explicitly extensible. 340 The "Authenticated Identity Management in SIP" specification 341 [RFC4474] (aka "SIP Identity") facilitates the composition of SAML 342 and SIP in that it defines a "mediated authentication architecture" 343 where verifying endpoints verify SIP identity assertions -- i.e., the 344 "Identity" header value -- signed by an Authentication Service (AS). 345 The semantic being that the AS is vouching that it did indeed 346 authenticate the calling party. 348 Such an Authentication Service, which likely has access to various 349 pieces of information concerning the calling party, could also act as 350 a SAML Authority, and make such information available to the callee 351 via SAML. 353 Since [RFC4474] stipulates that the AS must make its certificate 354 available for retrieval and convey the availability and access 355 mechanism via a URI, in the Identity-Info header, we have an 356 opportunity to compose SIP Identity and SAML. 358 Such composition can be accomplished by having the resource referred 359 to by the URI in the Identity-Info be a SAML assertion conveying both 360 the AS's certificate and user profile attributes. This is the 361 approach defined in this specification. Figure 1 illustrates this 362 approach in a high-level summary fashion. Figure 2, further below, 363 illustrates additional details. 365 +--------+ +--------------+ +--------+ 366 |Alice@ | |Authentication| | Bob@ | 367 |example | |Service | |example2| 368 |.com | |@example.com | |.com | 369 | | | | | | 370 +---+----+ +------+-------+ +---+----+ 371 | | | 372 | INVITE | | 373 |---------------------->| | 374 | From:alice@foo.com | | 375 | | | 376 | 407 Proxy auth. req. | | 377 |<----------------------| | 378 | Challenge | | 379 | | | 380 | ACK | | 381 |---------------------->| | 382 | | | 383 | INVITE w/authn creds | | 384 |---------------------->| | 385 | | INVITE | 386 | | w/Identity header | 387 | |--------------------->| 388 | | and Identity-Info | 389 | | | 390 | | HTTP GET SAML assn | 391 | |<==================== | 392 | | and domain cert | 393 | | | 394 | | HTTP 200 OK + assn | 395 | |=====================>| 396 | | and domain cert | 397 | 200 OK | | 398 |<----------------------+----------------------| 399 | | | 401 Figure 1: SIP-SAML-based Network Asserted Identity 403 Since the AS already being trusted to create and add the Identity 404 header containing the SIP Identity Assertion, and to supply a pointer 405 to its domain certificate, having it point instead to a SAML 406 assertion conveying the domain certificate and possibly some user 407 profile attributes, does not significantly alter the first-order 408 security considerations examined in [RFC4474]. This specification 409 provides some additional security considerations analysis below in 410 Section 9. 412 6. SIP SAML Profiles 414 This section defines two "SIP SAML profiles": 416 o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 417 Profile" 419 o The to-be-determined (TBD) "call-by-value" profile 421 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 423 6.1.1. Required Information 425 The information given in this section is similar to the info provided 426 when registering something, a MIME Media Type, say, with IANA. In 427 this case, it is for registering this profile with the OASIS SSTC. 428 See Section 2 "Specification of Additional Profiles" in 429 [OASIS.saml-profiles-2.0-os]. 431 Identification: 433 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 435 @@ NOTE: This URN must be agreed upon, and then registered with 436 IANA per [RFC3553]. 438 Contact Information: 440 @@ someone's or something's contact info goes here 442 SAML Confirmation Method Identifiers: 444 The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is 445 used in this profile. 447 Description: 449 Given below. 451 Updates: 453 None. 455 6.1.2. Profile Overview 457 Figure 2 illustrates this profile's overall protocol flow. The 458 following steps correspond to the labeled interactions in the figure. 459 Within an individual step, there may be one or more actual message 460 exchanges depending upon the protocol binding employed for that 461 particular step and other implementation-dependent behavior. 463 Although this profile is overview is cast in terms of a SIP INVITE 464 transaction, the reader should note that the mechanism specified 465 herein, and in [RFC4474], may be applied to any SIP request message. 467 Figure 2 begins on the next page. 469 +------------------+ +------------------+ +-----------------+ 470 | Caller | |Authn Service (AS)| | Callee | 471 |Alice@example.com | | @example.com | | Bob@example2.com| 472 +--------+---------+ +--------+---------+ +--------+--------+ 473 - - | | | (steps) 474 ^ ^ | INVITE | | 475 | | |---------------------->| | (1a) 476 | | From:alice@foo.com | | 477 | C | To:sip:bob@example.com| | 478 | S | | | 479 | e | 407 Proxy auth. req. | | 480 | q |<----------------------| | (1b) 481 | = | Challenge | | 482 | N | | | 483 | | ACK | | 484 | | |---------------------->| | (1c) 485 | V | | | 486 | - | | | 487 ^ | INVITE + authorization| | 488 D | | header w/ creds | | 489 | |---------------------->| | (2) 490 I | | From:alice@foo.com | | 491 | | To:sip:bob@example.com| | 492 A | Proxy-Authorization:..| | 493 C | | INVITE | 494 L S | |--------------------->| (3) 495 e | | From:alice@foo.com | 496 O q | | To:sip:bob@example2.com 497 | | Identity: ..... | 498 G = | | Identity-Info: | 499 | | https://example.com| 500 | N | | /assns/?ID=abcde | 501 | | | | 502 | + | |URI resolution (eg. HTTP) 503 | | |<=====================| (4) 504 | 1 | | GET /assns/?ID=abcde | 505 | | | | 506 | | | | HTTP/1.1 200 OK | 507 | | | |=====================>| (5) 508 | | | | | 509 | | | | | 510 | | | | | 511 | | | | Alice@example.com 512 | | | | 513 | | | | 514 | | | | ... 515 | | | | 516 | | | | foo=bar | 517 | | | 200 OK | | 518 | V |<----------------------+----------------------| (6) 519 . - | | | 520 V 522 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 523 Transaction 525 Step 1. Initial SIP Transaction between Caller and AS 527 This optional initial step is comprised of substeps 1a, 1b, 528 and 1c in Figure 2. In this step, the caller, Alice, sends 529 a SIP request message, illustrated as an INVITE, indicating 530 Bob as the callee (1a), is subsequently challenged by the AS 531 (1b), and sends an ACK in response to the challenge (1c). 532 The latter message signals the completion of this SIP 533 transaction (which is an optional substep of this profile). 535 Step 2. Caller sends SIP Request Message with Authorization 536 Credentials to the AS 538 Alice then sends an INVITE message in response to the 539 challenge, or uses cached credentials for the domain if step 540 1 was skipped, as specified in [RFC4474] and [RFC3261]. 541 Depending on the chosen SIP security mechanism for client 542 authentication either digest authentication, client side 543 authentication of Transport Layer Security, or a combination 544 of both is used to provide the AS with a strong assurance 545 about the identity of Alice. 547 Step 3. AS Authorizes the SIP Request and Forwards it to Callee 549 First, the AS authorizes the received INVITE message as 550 specified in [RFC4474] and [RFC3261]. If the authorization 551 is successful, the AS will form the "identity signature" for 552 the message and add Identity and Identity-Info header fields 553 to the message. The AS also at this time constructs and 554 caches a SAML assertion asserting Alice's profile attributes 555 required by Bob's domain (example2.com), and also containing 556 a the domain's (example.com) public key certificate, or a 557 reference to it. This certificate MUST contain the public 558 key corresponding to the private key used to construct the 559 signature whose value was placed in the Identity header. 560 The AS constructs a HTTP-based SAML URI Reference 561 incorporating the assertion's Assertion ID (see section 562 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as 563 the value for the Identity-Info header it adds to the INVITE 564 message. 566 The AS determines which profile attributes (if any) to 567 assert in the via local configuration 568 and/or obtaining example2.com's metadata 569 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 570 INVITE message to Bob. 572 Step 4. Callee Dereferences HTTP-based SAML URI Reference 574 Bob's UAC or SIP Proxy receives the message and begins 575 verifying it per the "Verifier Behavior" specified in 576 [RFC4474]. In order to accomplish this task, it needs to 577 obtain Alice's domain certificate. It obtains the HTTP- 578 based SAML URI Reference from the message's Identity-Info 579 header and dereferences it per Section 7.1. Note that this 580 is not a SIP message, but an HTTP message [RFC2616]. 582 Step 5. AS Returns SAML Assertion 584 Upon receipt of the above HTTP request, which contains an 585 embedded reference to Alice's SAML Assertion, Alice's AS 586 returns her assertion in an HTTP response message. 588 Upon receipt of Alice's SAML Assertion, the AS continues its 589 verification of the INVITE message. If successful, it 590 returns a 200 OK message directly to Alice. Otherwise it 591 returns an appropriate SIP error response. 593 Step 6. Callee Returns SIP 200 OK to Caller 595 If Bob determines, based upon Alice's identity as asserted 596 by the AS, and as further substantiated by the information 597 in the SAML assertion, to accept the INVITE, he returns a 598 SIP 200 OK message directly to Alice. 600 6.1.3. Profile Description 602 The following sections provide detailed definitions of the individual 603 profile steps. The relevant illustration is Figure 3, below. Note 604 that this profile is agnostic to the specific SIP request, and also 605 that the Sender and Authentication Service (AS) may be seperate or 606 co-located in actuality. 608 +------------------+ +------------------+ +------------------+ 609 | Sender | |Authn Service (AS)| | Verifier | 610 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 611 +--------+---------+ +--------+---------+ +--------+---------+ 612 | | | (steps) 613 | SIP Request | | 614 |---------------------->| | (1a) 615 | | | 616 | 407 Proxy auth. req. | | 617 |<----------------------| | (1b) 618 | Challenge | | 619 | | | 620 | ACK | | 621 |---------------------->| | (1c) 622 | | | 623 | | | 624 |SIP Req + authorization| | 625 | header w/ creds | | 626 |---------------------->| | (2) 627 | | | 628 | | | 629 | | SIP Req + Ident & | 630 | | authz headers | 631 | |--------------------->| (3) 632 | | | 633 | | URI resolution | 634 | |<=====================| (4) 635 | | (via HTTP) | 636 | | | 637 | | HTTP/1.1 200 OK | 638 | |=====================>| (5) 639 | | | 640 | | | 641 | | ? | (6) 642 | | | 644 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 646 6.1.3.1. Initial SIP Transaction between Sender and AS 648 This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication 649 Service Behavior" of [RFC4474]. If the SIP request sent by the 650 caller in substep 1a is deemed insufficiently authenticated by the AS 651 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 652 authenticate the sender of the message. The particulars of how this 653 is accomplished depend upon implementation and/or deployment 654 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 655 in Figure 3 are non-normative and illustrative only. 657 6.1.3.2. Sender sends SIP Request Message with Authorization 658 Credentials to the AS 660 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 661 Behavior" of [RFC4474]. This request is presumed to be made in a 662 context such that the AS will not challenge it -- i.e., the AS will 663 consider the sender of the message to be authenticated. If this is 664 not true, then this procedure reverts back to Step 1, above. 666 Otherwise, the AS carries out all other processing of the message as 667 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 668 procedure procedes to the next step below. 670 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 672 This first portion of this step maps to Steps 3 and 4 of Section 5 673 "Authentication Service Behavior" of [RFC4474], which the AS MUST 674 perform, although with the following additional substeps: 676 The AS MUST construct a SAML assertion according to the "Assertion 677 Profile Description" specified in Section 6.1.4 of this 678 specification. 680 The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 681 per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. 683 The AS MUST use the URI constructed in the immediately preceding 684 substep as the value of the Identity-Info header that is added to 685 the SIP request message per Step 4 of Section 5 of [RFC4474]. 687 Upon successful completion of all of the above, the AS forwards the 688 request message. 690 At this point in this step, after perhaps traversing some number of 691 intermediaries, the SIP request message arrives at a SIP network 692 entity performing the "verifier" role. This role and its behavior 693 are specified in Section 6 "Verifier Behavior" of [RFC4474]. The 694 verifier MUST perform the steps enumerated in the aforementioned 695 section, with the following modifications: 697 Step 1 of [RFC4474] Section 6 maps to and is updated by, the 698 following two steps in this procedure. 700 Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this 701 latter portion of this step, and/or the following two steps, as 702 appropriate. 704 6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 706 The verifier SHOULD ascertain whether it has a current cached copy of 707 the SIP message sender's SAML assertion and domain certificate. If 708 not, or if the verifier chooses to (e.g., due to local policy), it 709 MUST dereference the the HTTP-based SAML URI Reference found in the 710 SIP message's Identity-Info header. To do so, the verifier MUST 711 employ the "SAML HTTP-URI-based SIP Binding" specified in 712 Section 7.1. 714 6.1.3.5. AS Returns SAML Assertion 716 This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 718 If the prior step returns an HTTP error (e.g., 4xx series), then this 719 procedure terminates and the verifier returns (upstream) a SIP 436 720 'Bad Identity-Info' Response code. 722 Otherwise, the HTTP response message will contain a SAML assertion 723 and be denoted as such via the MIME media type of "application/ 724 samlassertion+xml" [IANA.application.samlassertion-xml]. The 725 verifier MUST perform the verification steps specified in 726 Section 6.1.5 "Assertion Verification", below. If successful, then 727 this procedure continues with the next step. 729 6.1.3.6. Verifier performs Next Step 731 The SIP request was successfully processed. The verifier now 732 performs its next step, which depends at least in part on the type of 733 SIP request it received. 735 6.1.4. Assertion Profile Description 737 This section defines the particulars of how the sender, i.e., the 738 SAML Authority, MUST construct certain portions of the SAML 739 assertions it issues. The schema for SAML assertions themselves is 740 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 742 An example SAML assertion, formulated according to this profile is 743 given in Section 8. 745 Overall SAML assertion profile requirements: 747 The SAML assertion MUST be signed by the same key as used to sign 748 the contents of the Identity header field. Signing of SAML 749 assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. 751 In the following subsections, the SAML assertion profile is specified 752 element-by-element, in a top-down, depth-first manner, beginning with 753 the outermost element, "". Where applicable, the 754 requirements for an element's XML attributes are also stated, as a 755 part of the element's description. Requirements for any given 756 element or XML attribute are only stated when, in the context of use 757 of this profile, they are not already sufficiently defined by 758 [OASIS.saml-core-2.0-os]. 760 6.1.4.1. Element: 762 Attribute: ID 764 The value for the ID XML attribute SHOULD be allocated randomly 765 such that the value meets the randomness requirments specified in 766 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 768 Attribute: IssueInstant 770 The value for the IssueInstant XML attribute SHOULD be set at the 771 time the SAML assertion is created (and cached for subsequent 772 retrieval). This time instant value MAY be temporally the same as 773 that encoded in the SIP message's Date header, and MUST be at 774 least temporally later, although it is RECOMMENDED that it not be 775 10 minutes or more later. 777 6.1.4.1.1. Element: 779 The value for the Issuer XML element MUST be a value that matches 780 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 781 the certificate conveyed by the SAML assertion in the ds: 782 X509Certificate element located on this path within the SAML 783 assertion: 785 793 The element SHOULD contain both a element and a 794 element. 796 The value of the element MUST be the same as the Address of 797 Record (AoR) value used in computing the "signed-identity-digest" 798 which forms the value of the Identity header. See Section 9 of 799 [RFC4474]. 801 The element attribute Method SHOULD be set to 802 the value: 804 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 806 Although it MAY be set to some other implementation- and/or 807 deployment-specific value. The element itself 808 SHOULD be empty. 810 6.1.4.1.3. Element: 812 The element SHOULD contain an 813 element, which itself SHOULD contain an element. The 814 value of the element SHOULD be the same as the addr-spec 815 of the SIP request's To header field. 817 The following XML attributes of the element MUST be set 818 as follows: 820 Attribute: NotBefore 822 The value of the NotBefore XML attribute MUST be set to a time 823 instant the same as the value for the IssueInstant XML attribute 824 discussed above, or to a later time. 826 Attribute: NotOnOrAfter 828 The value of the NotOnOrAfter XML attribute MUST be set to a time 829 instant later than the value for NotBefore. 831 6.1.4.1.4. Element: 833 The SAML assertion MAY contain an element. If 834 so, the element will contain attribute-value 835 pairs, e.g., of a user profile nature, encoded according to either 836 one of the "SAML Attribute Profiles" as specified in 837 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 838 and/or deployment-specific attribute profile. 840 The attribute-value pairs SHOULD in fact pertain to the entity 841 identified in the SIP From header field, since a SAML assertion 842 formulated per this overall section is stating that they do. 844 6.1.5. Assertion Verification 846 This section specifies the steps that a verifier participating in 847 this profile MUST perform in addition to the "Verifier Behavior" 848 specified in Section 6 of [RFC4474]. 850 The steps are: 852 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 853 extract the AS's domain certificate from the XML element at the end of the element path 855 given in Section 6.1.4.1.1. 857 2. Perform Step 1 in Section 6 of [RFC4474]. 859 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 860 that section, the verifier MUST verify the SAML assertion's 861 signature via the procedures specified in Section 5.4 of 862 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 864 @@ TODO: do we need to define a new SIP error response code for 865 when a SAML assn signature is bad? e.g., '4xx Invalid SAML 866 asssertion'. 868 4. Perform Step 2 in Section 6 of [RFC4474]. 870 5. Verify that the signer of the SIP message's Identity header 871 field is the same as the signer of the SAML assertion. 873 6. Perform Steps 3 and 4 in Section 6 of [RFC4474]. 875 7. Verify that the SAML assertion's element value matches 876 the Issuer or the Issuer Alternative Name fields [RFC3280] in 877 the AS's domain certificate. 879 8. Verify that the SAML assertion's element value is the 880 same as the Address of Record (AoR) value in the "signed- 881 identity-digest". See Section 9 of [RFC4474]. 883 9. Verify that the SAML assertion's element 884 value is set to whichever value was configured at 885 implementation- or deployment-time. The default value is: 887 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 889 10. Verify that the SAML assertion contains an element, 890 and that its value matches the value of the addr-spec of the SIP 891 To header field. 893 11. Verify that the validity period denoted by the NotBefore and 894 NotOnOrAfter attributes of the element meets the 895 requirements given in Section 6.1.4.1.3. 897 6.2. The TBD "call-by-value" Profile 899 To-Be-Determined (TBD) 901 7. SAML SIP Binding 903 This section specifies one SAML SIP Binding at this time. Additional 904 bindings may be specified in future revisions of this specification. 906 7.1. SAML HTTP-URI-based SIP Binding 908 This section specifies the "SAML HTTP-URI-based SIP Binding", 909 (SHUSB). 911 The SHUSB is a profile of the "SAML URI Binding" specified in Section 912 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 913 a means by which SAML assertions can be referenced by URIs and thus 914 be obtained through resolution of such URIs. 916 This profile of the SAML URI Binding is congruent with the SAML URI 917 Binding -- including support for HTTP-based URIs being mandatory to 918 implement -- except for the following further restrictions which are 919 specified in the interest of interoperability (section numbers refer 920 to [OASIS.saml-bindings-2.0-os]): 922 Section 3.7.5.3 Security Considerations: 924 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 926 Section 3.7.5.4 Error Reporting: 928 All SHOULDs in this section are to be interpreted as MUSTs. 930 8. Example SAML Assertions 932 This section presents two examples of a SAML assertion, one unsigned 933 (for clarity), the other signed (for accuracy). 935 In the first example, Figure 5, the assertion is attesting with 936 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 937 The validity conditions are expressed in lines 16-23, via both a 938 validity period expressed as temporal endpoints, and an "audience 939 restriction" stating that this assertion's semantics are valid for 940 only the relying party named "example2.com". Also, the assertion's 941 issuer is noted in lines 4-5. 943 The above items correspond to some aspects of this specification's 944 SAML assertion profile, as noted below in Security Considerations 945 dicussions, see: Section 9.1 and Section 9.2. 947 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 948 fashion, using LDAP/X.500 schema as the typing means. 950 1 953 4 954 5 example.com 955 6 956 7 957 8 960 11 Alice@example.com 961 12 962 13 964 15 965 16 967 18 968 19 969 20 example2.com 970 21 971 22 972 23 973 24 974 25 981 32 982 33 +1-888-555-1212 983 34 984 35 985 36 986 37 988 Figure 5: Unsigned SAML Assertion Illustrating Conveyance of 989 Subject Attribute 991 In the second example, Figure 6, the information described above is 992 the same, the addition is that this version of the assertion is 993 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 995 integrity are assured. Since this assertion is the same as the one 996 in the first example above, other than having a signature added, the 997 second example below addresses the same Security Considerations 998 aspects, plus those requiring a Signature. 1000 1 1003 4 1004 5 example.com 1005 6 1006 7 1007 8 1008 9 1010 11 1012 13 1014 15 1015 16 1018 19 1021 22 1025 26 1026 27 1027 28 1029 30 1030 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1031 32 1032 33 1033 34 1034 35 1035 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1036 37 1037 38 1038 39 1039 40 1040 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1041 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1042 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1043 44 1044 45 1045 46 1046 47 1047 48 1048 49 1051 52 Alice@example.com 1052 53 1053 54 1055 56 1056 57 1058 59 1059 60 1060 61 example2.com 1061 62 1062 63 1063 64 1064 65 1065 66 1072 73 1073 74 +1-888-555-1212 1074 75 1075 76 1076 77 1077 78 1079 Figure 6: Signed SAML Assertion Illustrating Conveyance of Subject 1080 Attribute 1082 9. Security Considerations 1084 This section discusses security considerations when using SAML with 1085 SIP. 1087 9.1. Man-in-the-middle Attacks and Stolen Assertions 1089 Threat: 1091 By making SAML assertions available via HTTP-based requests by a 1092 potentially unbounded set of requesters, it is conceivably 1093 possible that anyone would be able to simply request one and 1094 obtain it. By SIP intermediaries on the signaling path for 1095 example. Or, an HTTP intermediary/proxy could intercept the 1096 assertion as it is being returned to a requester. 1098 The attacker could then conceivably attempt to impersonate the 1099 subject (the putative caller) to some SIP-based target entity. 1101 Countermeasures: 1103 Such an attack is implausible for several reasons. The primary 1104 reason is that a message constructed by an imposter using a stolen 1105 assertion that conveys the public key certificate of some domain 1106 will not verify per [RFC4474] because the imposter will not have 1107 the corresponding private key with which to generate the signed 1108 Identity header value. 1110 Also, the SIP SAML assertion profile specified herein that the 1111 subject's SAML assertion must adhere to causes it to be not useful 1112 to arbitrary parties. The subject's assertion: 1114 * should be signed, thus causing any alterations to break its 1115 integrity and make such alterations detectable. 1117 * does not contain an authentication statement. Thus no parties 1118 implementing this specification should be relying on SAML 1119 assertions specified herein as sufficient in and of themselves 1120 to allow access to resources. 1122 * relying party is represented in the SAML assertion's Audience 1123 Restriction. 1125 * Issuer is represented in the SAML assertion. 1127 * validity period for assertion is restricted. 1129 * etc. 1131 9.2. Forged Assertion 1133 Threat: 1135 A malicious user could forge or alter a SAML assertion in order to 1136 communicate with the SIP entities. 1138 Countermeasures: 1140 To avoid this kind of attack, the entities must assure that proper 1141 mechanisms for protecting the SAML assertion are employed, e.g., 1142 signing the SAML assertion itself. Section 5.1 of 1143 [OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. 1145 Additionally, the assertion content dictated by the SAML assertion 1146 profile herein ensures ample evidence for a relying party to 1147 verify the assertion and its relationship with the received SIP 1148 request. 1150 9.3. Replay Attack 1152 Threat: 1154 Theft of SIP message protected by the mechanisms described herein 1155 and replay of it at a later time. 1157 Countermeasures: 1159 There are various provisions within [RFC4474] that prevent a 1160 replay attack. 1162 10. Contributors 1164 The authors would like to thank Marcus Tegnander and Henning 1165 Schulzrinne for his contributions to earlier versions of this 1166 document. 1168 11. Acknowledgments 1170 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1171 Schubert, Jason Fischl and Vijay Gurbani for their comments to this 1172 draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 1173 Profile" is based on an idea by Jon Peterson. 1175 12. IANA Considerations 1177 [Editor's Note: A future version of this document will provide IANA 1178 considerations.] 1180 13. Open Issues 1182 A list of open issues can be found at: 1183 http://www.tschofenig.com:8080/saml-sip/ 1185 14. Change Log 1187 RFC Editor - Please remove this section before publication. 1189 14.1. -02 to -03 1191 Denoted that this I-D is intended to update RFC4474 per SIP working 1192 group consensus at IETF-69. This is the tact adopted in order to 1193 address the impedance mismatch between the nature of the URIs 1194 specified as to be placed in the Identity-Info header field, and what 1195 is specified in RFC4474 as the allowable value of that header field. 1197 Added placeholder "TBD" section for a to-be-determined "call-by- 1198 value" profile, per SIP working group consensus at IETF-69. 1200 Removed use-case appendicies (per recollection of JHodges during 1201 IETF-69 discussion as being WG consensus, but such is not noted in 1202 the minutes). 1204 14.2. -00 to -02 1206 Will detail in -04 rev. 1208 15. References 1210 15.1. Normative References 1212 [OASIS.saml-bindings-2.0-os] 1213 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1214 Maler, "Bindings for the OASIS Security Assertion Markup 1215 Language (SAML) V2.0", OASIS 1216 Standard saml-bindings-2.0-os, March 2005. 1218 [OASIS.saml-core-2.0-os] 1219 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1220 "Assertions and Protocol for the OASIS Security Assertion 1221 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1222 2.0-os, March 2005. 1224 [OASIS.saml-metadata-2.0-os] 1225 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1226 "Metadata for the Security Assertion Markup Language 1227 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1228 March 2005. 1230 [OASIS.saml-profiles-2.0-os] 1231 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1232 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1233 Security Assertion Markup Language (SAML) V2.0", OASIS 1234 Standard OASIS.saml-profiles-2.0-os, March 2005. 1236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1237 Requirement Levels", BCP 14, RFC 2119, March 1997. 1239 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1240 Locators", RFC 2392, August 1998. 1242 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1243 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1244 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1246 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1247 A., Peterson, J., Sparks, R., Handley, M., and E. 1248 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1249 June 2002. 1251 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1252 X.509 Public Key Infrastructure Certificate and 1253 Certificate Revocation List (CRL) Profile", RFC 3280, 1254 April 2002. 1256 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1257 Method", RFC 3515, April 2003. 1259 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1260 IETF URN Sub-namespace for Registered Protocol 1261 Parameters", BCP 73, RFC 3553, June 2003. 1263 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1264 Authenticated Identity Body (AIB) Format", RFC 3893, 1265 September 2004. 1267 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1268 Authenticated Identity Management in the Session 1269 Initiation Protocol (SIP)", RFC 4474, August 2006. 1271 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1272 "Trait-Based Authorization Requirements for the Session 1273 Initiation Protocol (SIP)", RFC 4484, August 2006. 1275 [W3C.xmldsig-core] 1276 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1277 Syntax and Processing", W3C Recommendation xmldsig-core, 1278 October 2000, . 1280 15.2. Informative References 1282 [I-D.ietf-sip-content-indirect-mech] 1283 Burger, E., "A Mechanism for Content Indirection in 1284 Session Initiation Protocol (SIP) Messages", 1285 draft-ietf-sip-content-indirect-mech-05 (work in 1286 progress), October 2004. 1288 [I-D.ietf-sipping-certs] 1289 Jennings, C. and J. Peterson, "Certificate Management 1290 Service for The Session Initiation Protocol (SIP)", 1291 draft-ietf-sipping-certs-03 (work in progress), 1292 March 2006. 1294 [I-D.jennings-sipping-pay] 1295 Jennings, C., "Payment for Services in Session Initiation 1296 Protocol (SIP)", draft-jennings-sipping-pay-06 (work in 1297 progress), July 2007. 1299 [I-D.peterson-message-identity] 1300 Peterson, J., "Security Considerations for Impersonation 1301 and Identity in Messaging Systems", 1302 draft-peterson-message-identity-00 (work in progress), 1303 October 2004. 1305 [IANA.application.samlassertion-xml] 1306 OASIS Security Services Technical Committee (SSTC), 1307 "application/samlassertion+xml MIME Media Type 1308 Registration", IANA MIME Media Types Registry application/ 1309 samlassertion+xml, December 2004. 1311 [OASIS.saml-conformance-2.0-os] 1312 Mishra, P., Philpott, R., and E. Maler, "Conformance 1313 Requirements for the Security Assertion Markup Language 1314 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1315 March 2005. 1317 [OASIS.saml-glossary-2.0-os] 1318 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1319 Security Assertion Markup Language (SAML) V2.0", OASIS 1320 Standard saml-glossary-2.0-os, March 2005. 1322 [OASIS.saml-sec-consider-2.0-os] 1323 Hirsch, F., Philpott, R., and E. Maler, "Security and 1324 Privacy Considerations for the OASIS Security Markup 1325 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1326 2.0-os, March 2005. 1328 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1329 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1330 OASIS SSTC Committee 1331 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1333 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1334 Cantor, S., "SAML Protocol Extension for Third-Party 1335 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1336 ext-thirdparty-cd-01, March 2006. 1338 [OASIS.sstc-saml-tech-overview-2.0-draft-08] 1339 Hughes, J. and E. Maler, "Security Assertion Markup 1340 Language (SAML) V2.0 Technical Overview", OASIS SSTC 1341 Working Draft sstc-saml-tech-overview-2.0-draft-08, 1342 September 2005. 1344 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1345 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1346 March 1999. 1348 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1349 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1350 September 1999. 1352 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1353 Certificate Profile for Authorization", RFC 3281, 1354 April 2002. 1356 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1357 Initiation Protocol (SIP)", RFC 3323, November 2002. 1359 Authors' Addresses 1361 Hannes Tschofenig 1362 Nokia Siemens Networks 1363 Otto-Hahn-Ring 6 1364 Munich, Bavaria 81739 1365 Germany 1367 Email: Hannes.Tschofenig@siemens.com 1369 Jeff Hodges 1370 NeuStar, Inc. 1371 2000 Broadway Street 1372 Redwood City, CA 94063 1373 US 1375 Email: Jeff.Hodges@neustar.biz 1377 Jon Peterson 1378 NeuStar, Inc. 1379 1800 Sutter St Suite 570 1380 Concord, CA 94520 1381 US 1383 Email: jon.peterson@neustar.biz 1385 James Polk 1386 Cisco 1387 2200 East President George Bush Turnpike 1388 Richardson, Texas 75082 1389 US 1391 Email: jmpolk@cisco.com 1393 Douglas C. Sicker 1394 University of Colorado at Boulder 1395 ECOT 430 1396 Boulder, CO 80309 1397 US 1399 Email: douglas.sicker@colorado.edu 1401 Full Copyright Statement 1403 Copyright (C) The IETF Trust (2007). 1405 This document is subject to the rights, licenses and restrictions 1406 contained in BCP 78, and except as set forth therein, the authors 1407 retain all their rights. 1409 This document and the information contained herein are provided on an 1410 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1411 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1412 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1413 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1414 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1415 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1417 Intellectual Property 1419 The IETF takes no position regarding the validity or scope of any 1420 Intellectual Property Rights or other rights that might be claimed to 1421 pertain to the implementation or use of the technology described in 1422 this document or the extent to which any license under such rights 1423 might or might not be available; nor does it represent that it has 1424 made any independent effort to identify any such rights. Information 1425 on the procedures with respect to rights in RFC documents can be 1426 found in BCP 78 and BCP 79. 1428 Copies of IPR disclosures made to the IETF Secretariat and any 1429 assurances of licenses to be made available, or the result of an 1430 attempt made to obtain a general license or permission for the use of 1431 such proprietary rights by implementers or users of this 1432 specification can be obtained from the IETF on-line IPR repository at 1433 http://www.ietf.org/ipr. 1435 The IETF invites any interested party to bring to its attention any 1436 copyrights, patents or patent applications, or other proprietary 1437 rights that may cover technology that may be required to implement 1438 this standard. Please address the information to the IETF at 1439 ietf-ipr@ietf.org. 1441 Acknowledgment 1443 Funding for the RFC Editor function is provided by the IETF 1444 Administrative Support Activity (IASA).