idnits 2.17.00 (12 Aug 2021) /tmp/idnits29727/draft-ietf-sip-saml-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 256 has weird spacing: '...ich the asser...' == Line 1266 has weird spacing: '... where prox...' == Line 1381 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 (March 8, 2009) is 4822 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2392' is defined on line 1649, but no explicit reference was found in the text == Unused Reference: 'RFC3515' is defined on line 1673, but no explicit reference was found in the text == Unused Reference: 'RFC3553' is defined on line 1679, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1740, but no explicit reference was found in the text == Unused Reference: 'RFC3323' is defined on line 1752, 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 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- 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) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Experimental J. Hodges 5 Expires: September 9, 2009 Unaffiliated 6 J. Peterson 7 NeuStar, Inc. 8 J. Polk 9 Cisco 10 D. Sicker 11 CU Boulder 12 March 8, 2009 14 SIP SAML Profile and Binding 15 draft-ietf-sip-saml-06.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 9, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document specifies a Session Initiation Protocol (SIP) profile 54 of Security Assertion Markup Language (SAML) as well as a SAML SIP 55 binding. The defined SIP SAML Profile composes with the mechanisms 56 defined in the SIP Identity specification and satisfy requirements 57 presented in "Trait-based Authorization Requirements for the Session 58 Initiation Protocol (SIP)". 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 9 66 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 10 67 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 11 68 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 69 6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14 70 6.1. AS-driven SIP SAML URI-based Attribute Assertion 71 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14 72 6.1.1. Required Information . . . . . . . . . . . . . . . . . 14 73 6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14 74 6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18 75 6.1.4. Assertion Profile Description . . . . . . . . . . . . 21 76 6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 23 77 6.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 24 78 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26 79 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26 80 8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 27 81 9. Authentication Service Behavior . . . . . . . . . . . . . . . 32 82 10. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . . 34 83 11. SAML-Info Header Field . . . . . . . . . . . . . . . . . . . . 36 84 12. Extended RFC 4474 SIP Identity Signature Mechanism . . . . . . 38 85 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 86 13.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 41 87 13.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 41 88 13.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 42 89 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 90 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 91 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 92 16.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 45 93 16.2. 477 'Binding to SIP Message failed' Response Code . . . . 45 94 16.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 45 95 16.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 46 96 16.5. 480 'Use SAML Header' Response Code . . . . . . . . . . . 46 97 17. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 47 98 17.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 47 99 17.2. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 47 100 17.3. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 47 101 17.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 47 102 17.5. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 48 103 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 104 18.1. Normative References . . . . . . . . . . . . . . . . . . . 49 105 18.2. Informative References . . . . . . . . . . . . . . . . . . 50 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 108 1. Introduction 110 This document specifies composition of the Security Assertion Markup 111 Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate 112 richer authorization mechanisms and enable "trait-based 113 authorization." Trait-based authorization is where one is authorized 114 to make use of some resource based on roles or traits rather than 115 ones identifier(s). Motivations for trait-based authorization, along 116 with use-case scenarios, are presented in [RFC4484]. 118 Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- 119 based framework for creating and exchanging security information. 120 [OASIS.sstc-saml-exec-overview-2.0-cd-01] and 121 [OASIS.sstc-saml-tech-overview-2.0-draft-16] provide non-normative 122 overviews of SAMLv2. The SAMLv2 specification set is normatively 123 defined by [OASIS.saml-conformance-2.0-os]. 125 Various means of providing trait-based authorization exist: 126 authorization certificates [RFC3281], SPKI [RFC2693], or extensions 127 to the authenticated identity body [RFC3893]. The authors selected 128 SAML due to its increasing use in environments, such as the Liberty 129 Alliance, and the Internet2 project, areas where the applicability to 130 SIP is widely desired. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 The SIP network element "Authentication Service" is introduced in 139 [RFC4474]. We reuse this term to refer to a network element that 140 authenticates and authorizes a user and creates a "SIP identity 141 assertion". This system entity is the logical equivalent of a "SAML 142 Authority" in the SAML terminology. 144 For overall SIP terminology, see [RFC3261]. 146 In this specification, the term, or term component, "SAML" refers to 147 SAML V2.0 in all cases. For example, the term "SAML assertion" 148 implicitly means "SAMLv2 assertion". For overall SAML terminology, 149 see [OASIS.saml-glossary-2.0-os]. 151 The below list maps other various SIP terms to their SAML 152 (rough-)equivalents: 154 Element, Network Element: 156 System Entity, Entity 158 Authentication Service: 160 SAML Authority 162 Invitee, Invited User, Called Party, Callee: 164 Relying Party 166 Server, User Agent Server (UAS): 168 SAML Responder 170 User Agent Client (UAC), client: 172 SAML Requester 174 Additional terms defined in the context of this specification: 176 profile attribute(s): 178 one or more attributes of a "user profile". 180 user profile, subject profile: 182 the set of various attributes accompanying (i.e., mapped to) a 183 user account in many environments. 185 3. SAML Introduction 187 SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] 188 [OASIS.sstc-saml-tech-overview-2.0-draft-16] defines an XML-based 189 framework for exchanging "security assertions" between entities. In 190 the course of making, or relying upon such assertions, SAML system 191 entities may use SAML protocols, or other protocols, to communicate 192 an assertion itself, or the subject of an assertion. 194 Thus, one can employ SAML to make and encode statements such as 195 "Alice has these profile attributes and her domain's certificate is 196 available over there, and I'm making this statement, and here's who I 197 am." Then one can cause such an assertion to be conveyed to some 198 party who can then rely on it in some fashion for some purpose, for 199 example input it into some local policy evaluation for access to some 200 resource. This is done in a particular "context of use". Such a 201 context of use could be, for example, deciding whether to accept and 202 act upon a SIP-based invitation to initiate a communication session. 204 The specification of how SAML is employed in a particular context of 205 use is known as a "SAML profile". The specification of how SAML 206 assertions and/or protocol messages are conveyed in, or over, another 207 protocol is known as a "SAML Binding". Typically, a SAML profile 208 specifies the SAML bindings that may be used in its context. Both 209 SAML profiles and SAML bindings reference other SAML specifications, 210 especially the SAML Assertions and Protocols, aka "SAML Core", 211 specification [OASIS.saml-core-2.0-os]. 213 There is an additional subtle aspect of SAML profiles that is worth 214 highlighting -- the notion of a "SAML assertion profile". A SAML 215 assertion profile is the specification of the assertion contents in 216 the context of a particular SAML profile. It is possibly further 217 qualified by a particular implementation and/or deployment context. 218 Condensed examples of SAML assertion profiles are: 220 o The SAML assertion must contain at least one authentication 221 statement and no other statements. The relying party must be 222 represented in the element. The 223 SubjectConfirmation Method must be Foo. etc. 225 o The SAML assertion must contain at least one attribute statement 226 and may contain more than one. The values for the subject's 227 profile attributes named "Foo" and "Bar" must be present. An 228 authentication statement may be present. etc. 230 The primary facets of SAML itself are: 232 o Assertions 234 o Abstract Request/Response protocol 236 We describe each in turn below: 238 3.1. SAML Assertions 240 A SAML assertion is a package of information including issuer and 241 subject, conditions and advice, and/or attribute statements, and/or 242 authentication statements and/or other statements. Statements may or 243 may not be present. The SAML assertion "container" itself contains 244 the following information: 246 Issuing information: 248 Who issued the assertion, when was it issued and the assertion 249 identifier. 251 Subject information: 253 The name of the subject, the security domain and optional subject 254 information, like public key. 256 Conditions under which the assertion is valid: 258 Special kind of conditions like assertion validity period, 259 audience restriction and target restriction. 261 Additional advice: 263 Explaining how the assertion was made, for example. 265 In terms of SAML assertions containing SAML attribute statements or 266 SAML authentication statements, here are explanatory examples: 268 With a SAML assertion containing a SAML attribute statement, an 269 issuing authority is asserting that the subject is associated with 270 certain attributes with certain subject profile attribute values. 271 For example, user jon@cs.example.com is associated with the 272 attribute "Department", which has the value "Computer Science". 274 With a SAML assertion containing a SAML authentication statement, 275 an issuing authority is asserting that the subject was 276 authenticated by certain means at a certain time. 278 With a SAML assertion containing both a SAML attribute statement 279 and a SAML authentication statement, an issuing authority is 280 asserting the union of the above. 282 3.2. Abstract Request/Response Protocol 284 SAML defines an abstract request/response protocol for obtaining 285 assertions. See Section 3 "SAML Protocols" of 286 [OASIS.saml-core-2.0-os]. A request asks for an assertion. A 287 response returns the requested assertion or an error. This abstract 288 protocol may then be cast into particular contexts of use by binding 289 it to specific underlying protocols, e.g., HTTP or SIP, and 290 "profiling" it for the specific use case at hand. The SAML HTTP- 291 based web single sign-on profile is one such example (see Section 4.1 292 Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait- 293 based SIP communication session establishment, the topic of this 294 specification, is another. 296 4. Specification Scope 298 The scope of this specification is: 300 o Specify a SIP profile of SAML -- also known as a "SIP SAML 301 profile" -- such that a subject's profile attributes. In doing 302 so, satisfy the requirements outlined in [RFC4484]. 304 The following are outside the scope of this specification: 306 o Defining a means for configuring the runtime behavior, or 307 deployment characteristics, of the Authentication Service. 309 Discussion: 311 For example, a SIP Authentication Service could be implemented 312 such that its SAML-based features are employed, or not, on a 313 subject-by-subject basis, and/or on a domain-by-domain basis. 315 o The definition of specific conveyed subject profile attributes 316 (aka traits). 318 Discussion: 320 This specification defines a facility enabling "trait-based 321 authorization" as discussed in [RFC4484]. 323 The attributes of interest in trait-based authorization will be 324 ones akin to, for example: roles, organizational membership, 325 access rights, or authentication event context. Definition of 326 such attributes is application- and/or deployment-context- 327 dependent and are not defined in this specification. However, The 328 SAMLv2 specification defines several "SAML Attribute Profiles" for 329 encoding attributes from various application domains, e.g., LDAP, 330 UUID/GUID, DCE PAC, and XACML, in SAML assertions 331 [OASIS.saml-profiles-2.0-os]. 333 In order for any trait-based system to be practical, participating 334 entities must agree on attributes and traits that will be conveyed 335 and subsequently relied upon. Without such agreements, a trait- 336 based system cannot be usefully deployed. This specification does 337 not discuss the manner in which participating entites might 338 discover one another or agree on the syntax and semantics of 339 attributes and traits. 341 Note that SAMLv2 specifies a "metadata" facility that may be 342 useful in addressing this need. 344 5. Employing SAML in SIP 346 Employing SAML in SIP necessitates devising a new SAML profile(s) and 347 binding(s) because those already specified in the SAMLv2 348 specification set are specific to other use contexts, e.g., HTTP- 349 based web browsing. Although SIP bears some similarity to HTTP, it 350 is a seperately distinct protocol, thus requiring specification of 351 SIP-specific SAML profile(s) and binding(s). 353 The SIP SAML Profiles defined in this document make use of concepts 354 defined by [RFC4474] "Enhancements for Authenticated Identity 355 Management in the Session Initiation Protocol (SIP)" -- also known as 356 "SIP Identity". In particular, they leverage the "mediated 357 authentication architecture" utilizing the Authentication Service 358 (AS). The overall semantic being that the AS is vouching that it did 359 indeed authenticate the calling party. 361 Such an Authentication Service, which likely has access to various 362 pieces of information concerning the calling party, could also act as 363 a SAML Authority, and make such information available to the callee 364 via SAML. 366 The approach used by this document is similar to the one used for SIP 367 Identity, i.e. the AS creates a SAML assertion and makes it available 368 to the verifier via a reference, in the particular case of the AS- 369 driven SIP SAML URI-based Attribute Assertion Fetch Profile. 370 Figure 1 illustrates this approach in a high-level summary fashion. 371 Figure 2, further below, illustrates additional details. In case of 372 the Assertion-by Value profile the SAML assertion is made available 373 to the verifying party directly without the additional step of 374 utilizing a reference. This approach is described in Section 6.2. 376 +--------+ +--------------+ +--------+ 377 |Alice@ | |Authentication| | Bob@ | 378 |example | |Service | |example2| 379 |.com | |@example.com | |.com | 380 | | | | | | 381 +---+----+ +------+-------+ +---+----+ 382 | | | 383 | INVITE | | 384 |---------------------->| | 385 | From:alice@foo.com | | 386 | | | 387 | 407 Proxy auth. req. | | 388 |<----------------------| | 389 | Challenge | | 390 | | | 391 | ACK | | 392 |---------------------->| | 393 | | | 394 | INVITE w/authn creds | | 395 |---------------------->| | 396 | | INVITE | 397 | | w/SAML-Info and | 398 | | w/SAML-Signature | 399 | |--------------------->| 400 | | | 401 | | | 402 | | HTTP GET SAML assn | 403 | |<==================== | 404 | | | 405 | | | 406 | | HTTP 200 OK + assn | 407 | |=====================>| 408 | | | 409 | 200 OK | | 410 |<----------------------+----------------------| 411 | | | 413 Figure 1: SIP-SAML-based Network Asserted Identity 415 Figure 1 shows an exchange based on the AS-driven SIP SAML URI-based 416 Attribute Assertion Fetch Profile where the AS creates a SAML 417 assertion, creates a reference to it, and puts that reference into 418 the SAML-Info header before forwarding the SIP message. To tie the 419 SAML-Info field to the message a digial signature is computed and 420 placed in the SAML-Signature header. Bob in our case acting as the 421 verifier uses the reference to retrieve the SAML assertion, verifies 422 it and the SAML-Signature. 424 6. SIP SAML Profiles 426 This section defines two "SIP SAML profiles": 428 o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch 429 Profile" 431 o The "Assertion-by-value" Profile 433 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 435 6.1.1. Required Information 437 The information given in this section is similar to the info provided 438 when registering something, a MIME Media Type, say, with IANA. In 439 this case, it is for registering this profile with the OASIS SSTC. 440 See Section 2 "Specification of Additional Profiles" in 441 [OASIS.saml-profiles-2.0-os]. 443 Identification: 445 urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 447 Contact Information: 449 Hannes Tschofenig (Hannes.Tschofenig@nsn.com) 451 SAML Confirmation Method Identifiers: 453 The SAML V2.0 confirmation method identifier is used in this 454 profile. 456 Description: 458 Given below. 460 Updates: 462 None. 464 6.1.2. Profile Overview 466 Figure 2 illustrates this profile's overall protocol flow. The 467 following steps correspond to the labeled interactions in the figure. 468 Within an individual step, there may be one or more actual message 469 exchanges depending upon the protocol binding employed for that 470 particular step and other implementation-dependent behavior. 472 Although this profile is overview is cast in terms of a SIP INVITE 473 transaction, the reader should note that the mechanism specified 474 herein, may be applied to any SIP request message. 476 Figure 2 begins on the next page. 478 +------------------+ +------------------+ +-----------------+ 479 | Caller | |Authn Service (AS)| | Callee | 480 |Alice@example.com | | @example.com | | Bob@example2.com| 481 +--------+---------+ +--------+---------+ +--------+--------+ 482 - - | | | (steps) 483 ^ ^ | INVITE | | 484 | | |---------------------->| | (1a) 485 | | From:alice@foo.com | | 486 | C | To:sip:bob@example.com| | 487 | S | | | 488 | e | 407 Proxy auth. req. | | 489 | q |<----------------------| | (1b) 490 | = | Challenge | | 491 | N | | | 492 | | ACK | | 493 | | |---------------------->| | (1c) 494 | V | | | 495 | - | | | 496 ^ | INVITE + authorization| | 497 D | | header w/ creds | | 498 | |---------------------->| | (2) 499 I | | From:alice@foo.com | | 500 | | To:sip:bob@example.com| | 501 A | Proxy-Authorization:..| | 502 C | | INVITE | 503 L S | |--------------------->| (3) 504 e | | From:alice@foo.com | 505 O q | | To:sip:bob@example2.com 506 | | | 507 G = | | SAML-Info: | 508 | | https://example.com| 509 | N | | /assns/?ID=abcde | 510 | | | | SAML-Signature | 511 | | | | 512 | + | |URI resolution (eg. HTTP) 513 | | |<=====================| (4) 514 | 1 | | GET /assns/?ID=abcde | 515 | | | | 516 | | | | HTTP/1.1 200 OK | 517 | | | |=====================>| (5) 518 | | | | | 519 | | | | | 520 | | | | | 521 | | | | Alice@example.com 522 | | | | 523 | | | | 524 | | | | ... 525 | | | | 526 | | | | foo=bar | 527 | | | 200 OK | | 528 | V |<----------------------+----------------------| (6) 529 . - | | | 530 V 532 Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE 533 Transaction 535 Step 1. Initial SIP Transaction between Caller and AS 537 This optional initial step is comprised of substeps 1a, 1b, 538 and 1c in Figure 2. In this step, the caller, Alice, sends 539 a SIP request message, illustrated as an INVITE, indicating 540 Bob as the callee (1a), is subsequently challenged by the AS 541 (1b), and sends an ACK in response to the challenge (1c). 542 The latter message signals the completion of this SIP 543 transaction (which is an optional substep of this profile). 545 Step 2. Caller sends SIP Request Message with Authorization 546 Credentials to the AS. 548 Alice then sends an INVITE message in response to the 549 challenge, or uses cached credentials for the domain if step 550 1 was skipped, as specified in [RFC4474] and [RFC3261]. 551 Depending on the chosen SIP security mechanism for client 552 authentication either digest authentication, client side 553 authentication of Transport Layer Security, or a combination 554 of both is used to provide the AS with a strong assurance 555 about the identity of Alice. 557 Step 3. AS authorizes the SIP Request and Forwards it to Callee. 559 First, the AS authorizes the received INVITE message, as 560 specified in [RFC4474] and [RFC3261]. If the authorization 561 procedure is successful, the AS creates a SAML assertion 562 asserting Alice's profile attributes required by Bob's 563 domain (example2.com)., and also containing a the domain's 564 (example.com) public key certificate, or a reference to it. 565 The AS constructs a HTTP-based SAML URI Reference 566 incorporating the assertion's Assertion ID (see Section 567 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as 568 the value for the SAML-Info header it adds to the INVITE 569 message. 571 The AS determines which profile attributes (if any) to 572 assert in the via local configuration 573 and/or obtaining example2.com's metadata 574 [OASIS.saml-metadata-2.0-os]. The AS then sends the updated 575 INVITE message to Bob. 577 Step 4. Callee Dereferences HTTP-based SAML URI Reference 579 Bob's UAC or SIP Proxy receives the message and needs to 580 obtain Alice's domain certificate that is contained in the 581 SAML assertion. It obtains the HTTP-based SAML URI 582 Reference from the message's SAML-Info header and 583 dereferences it per Section 7.1. Note that this is not a 584 SIP message, but an HTTP message [RFC2616]. 586 Step 5. AS Returns SAML Assertion 588 Upon receipt of the above HTTP request, which contains an 589 embedded reference to Alice's SAML Assertion, Alice's AS 590 returns her assertion in an HTTP response message. 592 Upon receipt of Alice's SAML Assertion, the binding between 593 the SAML assertion and the SIP message is verified. A 594 detailed description can be found in Section 10. Various 595 elements contained in the SAML assertion are inspected and 596 the processing of the INVITE message is continued. 598 Step 6. Callee Returns SIP 200 OK to Caller 600 If Bob determines, based upon Alice's identity as asserted 601 by the AS, and as further substantiated by the information 602 in the SAML assertion, to accept the INVITE, he returns a 603 SIP 200 OK message directly to Alice. 605 6.1.3. Profile Description 607 The following sections provide detailed definitions of the individual 608 profile steps. The relevant illustration is Figure 3, below. Note 609 that this profile is agnostic to the specific SIP request, and also 610 that the Sender and Authentication Service (AS) may be seperate or 611 co-located in actuality. 613 +------------------+ +------------------+ +------------------+ 614 | Sender | |Authn Service (AS)| | Verifier | 615 | (UAC) | | (Sender's) | |(UAS or Proxy Svr)| 616 +--------+---------+ +--------+---------+ +--------+---------+ 617 | | | (steps) 618 | SIP Request | | 619 |---------------------->| | (1a) 620 | | | 621 | 407 Proxy auth. req. | | 622 |<----------------------| | (1b) 623 | Challenge | | 624 | | | 625 | ACK | | 626 |---------------------->| | (1c) 627 | | | 628 | | | 629 |SIP Req + authorization| | 630 | header w/ creds | | 631 |---------------------->| | (2) 632 | | | 633 | | | 634 | | SIP Req + SAML-Info | 635 | | + SIP-Signature | 636 | |--------------------->| (3) 637 | | | 638 | | URI resolution | 639 | |<=====================| (4) 640 | | (via HTTP) | 641 | | | 642 | | HTTP/1.1 200 OK | 643 | |=====================>| (5) 644 | | | 645 | | | 646 | | ? | (6) 647 | | | 649 Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow 651 6.1.3.1. Initial SIP Transaction between Sender and AS 653 This optional step maps to Steps 1 and 2 of Section 5 "Authentication 654 Service Behavior" of [RFC4474]. If the SIP request sent by the 655 caller in substep 1a is deemed insufficiently authenticated by the AS 656 per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST 657 authenticate the sender of the message. The particulars of how this 658 is accomplished depend upon implementation and/or deployment 659 instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown 660 in Figure 3 are non-normative and illustrative only. 662 6.1.3.2. Sender sends SIP Request Message with Authorization 663 Credentials to the AS 665 This step maps to Steps 1 and 2 of Section 5 "Authentication Service 666 Behavior" of [RFC4474]. This request is presumed to be made in a 667 context such that the AS will not challenge it -- i.e., the AS will 668 consider the sender of the message to be authenticated. If this is 669 not true, then this procedure reverts back to Step 1, above. 671 Otherwise, the AS carries out all other processing of the message as 672 stipulated in [RFC4474] Steps 1 and 2, and if successful, this 673 procedure procedes to the next step below. 675 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 677 This first portion of this step maps to Steps 3 and 4 of Section 9, 678 which the AS MUST perform, although with the following additional 679 substeps: 681 The AS MUST construct a SAML assertion according to the "Assertion 682 Profile Description" specified in Section 6.1.4 of this 683 specification. 685 The AS MUST construct an HTTP URI per Section "3.7.5.1 URI Syntax" 686 of [OASIS.saml-bindings-2.0-os]. To enable proper caching, the 687 HTTP URI pointing to the SAML assertion MUST be unique, i.e., if 688 the content of the SAML assertion changes then the HTTP URI 689 reference MUST be different than any previously used HTTP URI 690 references used before. 692 The AS MUST use the URI constructed in the immediately preceding 693 substep as the value of the SAML-Info header that is added to the 694 SIP request message. 696 Upon successful completion of all of the above, the AS forwards the 697 request message. 699 At this point in this step, after perhaps traversing some number of 700 intermediaries, the SIP request message arrives at a SIP network 701 entity performing the "verifier" role. This role and its behavior 702 are specified in Section 10. 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 SAML-Info header. To do so, the verifier MUST employ 711 the "SAML HTTP-URI-based SIP Binding" specified in Section 7.1. 713 6.1.3.5. AS Returns SAML Assertion 715 This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 717 If the prior step returns an HTTP error (e.g., 4xx series), then this 718 procedure terminates and the verifier returns (upstream) a SIP 436 719 'Bad SAML-Info' Response code. 721 Otherwise, the HTTP response message will contain a SAML assertion 722 and be denoted as such via the MIME media type of "application/ 723 samlassertion+xml" [IANA.application.samlassertion-xml]. The 724 verifier MUST perform the verification steps specified in 725 Section 6.1.5 "Assertion Verification", below. If successful, then 726 this procedure continues with the next step. 728 6.1.3.6. Verifier performs Next Step 730 The SIP request was successfully processed. The verifier now 731 performs its next step, which depends at least in part on the type of 732 SIP request it received. 734 6.1.4. Assertion Profile Description 736 This section defines the particulars of how the sender, i.e., the 737 SAML Authority, MUST construct certain portions of the SAML 738 assertions it issues. The schema for SAML assertions themselves is 739 defined in Section 2.3 of [OASIS.saml-core-2.0-os]. 741 An example SAML assertion, formulated according to this profile is 742 given in Section 8. 744 In the following subsections, the SAML assertion profile is specified 745 element-by-element, in a top-down, depth-first manner, beginning with 746 the outermost element, "". Where applicable, the 747 requirements for an element's XML attributes are also stated, as a 748 part of the element's description. Requirements for any given 749 element or XML attribute are only stated when, in the context of use 750 of this profile, they are not already sufficiently defined by 751 [OASIS.saml-core-2.0-os]. 753 6.1.4.1. Element: 755 Attribute: ID 757 The value for the ID XML attribute SHOULD be allocated randomly 758 such that the value meets the randomness requirments specified in 759 Section 1.3.4 of [OASIS.saml-core-2.0-os]. 761 Attribute: IssueInstant 763 The value for the IssueInstant XML attribute SHOULD be set at the 764 time the SAML assertion is created (and cached for subsequent 765 retrieval). This time instant value MAY be temporally the same as 766 that encoded in the SIP message's Date header, and MUST be at 767 least temporally later, although it is RECOMMENDED that it not be 768 10 minutes or more later. 770 6.1.4.1.1. Element: 772 The value for the Issuer XML element MUST be a value that matches 773 either the Issuer or the Issuer Alternative Name fields [RFC3280] in 774 the certificate conveyed by the SAML assertion in the ds: 775 X509Certificate element located on this path within the SAML 776 assertion: 778 788 The element SHOULD contain both a element and a 789 element. 791 The value of the element MUST be the Address of Record 792 (AoR). 794 The element attribute Method SHOULD be set to 795 the value: 797 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 799 Although it MAY be set to some other implementation- and/or 800 deployment-specific value. The element itself 801 SHOULD be empty. 803 6.1.4.1.3. Element: 805 The element SHOULD contain an 806 element, which itself SHOULD contain an element. When 807 included the value of the element MUST be the same as the 808 addr-spec of the SIP request's To header field. 810 The following XML attributes of the element MUST be set 811 as follows: 813 Attribute: NotBefore 815 The value of the NotBefore XML attribute MUST be set to a time 816 instant the same as the value for the IssueInstant XML attribute 817 discussed above, or to a later time. 819 Attribute: NotOnOrAfter 821 The value of the NotOnOrAfter XML attribute MUST be set to a time 822 instant later than the value for NotBefore. 824 6.1.4.1.4. Element: 826 The SAML assertion MAY contain an element. If 827 so, the element will contain attribute-value 828 pairs, e.g., of a user profile nature, encoded according to either 829 one of the "SAML Attribute Profiles" as specified in 830 [OASIS.saml-profiles-2.0-os], or encoded in some implementation- 831 and/or deployment-specific attribute profile. 833 The attribute-value pairs SHOULD in fact pertain to the entity 834 identified in the SIP From header field, since a SAML assertion 835 formulated per this overall section is stating that they do. 837 6.1.5. Assertion Verification 839 This section specifies the steps that a verifier participating in 840 this profile MUST perform in addition to the "Verifier Behavior" 841 specified in Section 6 of [RFC4474]. 843 The steps are: 845 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 846 extract the AS's domain certificate from the 847 XML element at the end of the element path given in 848 Section 6.1.4.1.1. 850 2. Perform Step 1 in Section 6 of [RFC4474]. 852 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of that 853 section, the verifier MUST verify the SAML assertion's signature 854 via the procedures specified in Section 5.4 of 855 [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. 857 The 479 'Invalid SAML Assertion' response code is used when the 858 verifier is unable to process the SAML assertion. 860 4. Perform Step 2 in Section 6 of [RFC4474]. 862 5. Verify that the signer of the SIP message's Identity header field 863 is the same as the signer of the SAML assertion. 865 6. Verify that the content of the SAML assertion, if present, 866 matches with the information carried in the SIP message. This 867 may include the following checks: 869 7. 871 * Verify that the SAML assertion's element value 872 matches the Issuer or the Issuer Alternative Name fields 873 [RFC3280] in the AS's domain certificate. 875 * Verify that the SAML assertion's element value is the 876 same as the Address of Record (AoR) value. 878 * Verify that the SAML assertion's element 879 value is set to whichever value was configured at 880 implementation- or deployment-time. The default value is: 882 urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 884 * Verify that the SAML assertion contains an element, 885 and that its value matches the value of the addr-spec of the 886 SIP To header field. 888 * Verify that the validity period denoted by the NotBefore and 889 NotOnOrAfter attributes of the element meets the 890 requirements given in Section 6.1.4.1.3. 892 6.2. Caller-driven SIP SAML Conveyed Assertion Profile 894 For the "Assertion-by-value" profile we assume that a SAML assertion 895 is obtained out-of-band and attached to the body of the SIP message. 896 Note that any SIP message may be used to convey the SAML assertion 897 even though SIP INVITE may be the most appropriate candiate. The 898 verification step described in Section 6.1.5 is applicable to this 899 profile as well as the description on the content of the assertion 900 illustrated in Section 6.1.4. 902 7. SAML SIP Binding 904 This section specifies one SAML SIP Binding at this time. Additional 905 bindings may be specified in future revisions of this specification. 906 The description in Section 6.1.4 is applicable to this profile. 908 7.1. SAML HTTP-URI-based SIP Binding 910 This section specifies the "SAML HTTP-URI-based SIP Binding", 911 (SHUSB). 913 The SHUSB is a profile of the "SAML URI Binding" specified in Section 914 3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies 915 a means by which SAML assertions can be referenced by URIs and thus 916 be obtained through resolution of such URIs. 918 This profile of the SAML URI Binding is congruent with the SAML URI 919 Binding -- including support for HTTP-based URIs being mandatory to 920 implement -- except for the following further restrictions which are 921 specified in the interest of interoperability (section numbers refer 922 to [OASIS.saml-bindings-2.0-os]): 924 Section 3.7.5.3 Security Considerations: 926 Support for TLS 1.0 or SSL 3.0 is mandatory to implement. 928 Section 3.7.5.4 Error Reporting: 930 All SHOULDs in this section are to be interpreted as MUSTs. 932 8. Example SAML Assertions 934 This section presents two examples of a SAML assertion, one unsigned 935 (for clarity), the other signed (for accuracy). 937 In the first example, Figure 4, the assertion is attesting with 938 respect to the subject (lines 7-15) "Alice@example.com" (line 11). 939 The validity conditions are expressed in lines 16-23, via both a 940 validity period expressed as temporal endpoints, and an "audience 941 restriction" stating that this assertion's semantics are valid for 942 only the relying party named "example2.com". Also, the assertion's 943 issuer is noted in lines 4-5. 945 The above items correspond to some aspects of this specification's 946 SAML assertion profile, as noted below in Security Considerations 947 dicussions, see: Section 13.1 and Section 13.2. 949 In lines 24-36, Alice's telephone number is conveyed, in a "typed" 950 fashion, using LDAP/X.500 schema as the typing means. 952 1 955 4 956 5 example.com 957 6 958 7 959 8 962 11 Alice@example.com 963 12 964 13 966 15 967 16 969 18 970 19 971 20 example2.com 972 21 973 22 974 23 975 24 976 25 983 32 984 33 +1-888-555-1212 985 34 986 35 987 36 988 37 990 Figure 4: Unsigned SAML Assertion Illustrating Conveyance of 991 Subject Attribute 993 In the second example, Figure 5, the information described above is 994 the same, the addition is that this version of the assertion is 995 signed. All the signature information is conveyed in the element, lines 7-47. Thus this assertion's origin and its 997 integrity are assured. Since this assertion is the same as the one 998 in the first example above, other than having a signature added, the 999 second example below addresses the same Security Considerations 1000 aspects, plus those requiring a Signature. 1002 1 1005 4 1006 5 example.com 1007 6 1008 7 1009 8 1010 9 1012 11 1014 13 1016 15 1017 16 1020 19 1023 22 1027 26 1028 27 1029 28 1031 30 1032 31 Kclet6XcaOgOWXM4gty6/UNdviI= 1033 32 1034 33 1035 34 1036 35 1037 36 hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubfZ6RqVL+wNmeWI4= 1038 37 1039 38 1040 39 1041 40 1042 41 MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxNVBAYTAlVT 1043 42 MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnZAv2FU78pLX 1044 43 8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdioG8cCx3w/w== 1045 44 1046 45 1047 46 1048 47 1049 48 1050 49 1053 52 Alice@example.com 1054 53 1055 54 1057 56 1058 57 1060 59 1061 60 1062 61 example2.com 1063 62 1064 63 1065 64 1066 65 1067 66 1074 73 1075 74 +1-888-555-1212 1076 75 1077 76 1078 77 1079 78 1081 Figure 5: Signed SAML Assertion Illustrating Conveyance of Subject 1082 Attribute 1084 9. Authentication Service Behavior 1086 [RFC4474] defined a new role for SIP entities called an 1087 authentication service. This document re-uses the concept and hence 1088 the same constraints and properties apply to this document. The 1089 subsequent text is copied from [RFC4474] and modified to fit to the 1090 usage of SAML. 1092 Any entity that instantiates the authentication service role MUST 1093 possess the private key of a domain certificate. Intermediaries that 1094 instantiate this role MUST be capable of authenticating one or more 1095 SIP users that can register in that domain. Commonly, this role will 1096 be instantiated by a proxy server, since these entities are more 1097 likely to have a static hostname, hold a corresponding certificate, 1098 and have access to SIP registrar capabilities that allow them to 1099 authenticate users in their domain. It is also possible that the 1100 authentication service role might be instantiated by an entity that 1101 acts as a redirect server, but that is left as a topic for future 1102 work. 1104 SIP entities that act as an authentication service MUST add a Date 1105 header field to SIP requests if one is not already present. 1106 Similarly, authentication services MUST add a Content- Length header 1107 field to SIP requests if one is not already present; this can help 1108 verifiers to double-check that they are hashing exactly as many bytes 1109 of message-body as the authentication service when they verify the 1110 message. 1112 Entities instantiating the authentication service role perform the 1113 following steps, in order, to generate an Identity header for a SIP 1114 request: 1116 Step 1: 1118 The authentication service MUST extract the identity of the sender 1119 from the request. The authentication service takes this value 1120 from the From header field; this AoR will be referred to here as 1121 the 'identity field'. If the identity field contains a SIP or SIP 1122 Secure (SIPS) URI, the authentication service MUST extract the 1123 hostname portion of the identity field and compare it to the 1124 domain(s) for which it is responsible (following the procedures in 1125 RFC 3261, Section 16.4, used by a proxy server to determine the 1126 domain(s) for which it is responsible). If the identity field 1127 uses the TEL URI scheme, the policy of the authentication service 1128 determines whether or not it is responsible for this identity. If 1129 the authentication service is not responsible for the identity in 1130 question, it SHOULD process and forward the request normally, but 1131 it MUST NOT add a SAML-Info and a SAML-Signature header. 1133 Step 2: 1135 The authentication service MUST determine whether or not the 1136 sender of the request is authorized to claim the identity given in 1137 the identity field. In order to do so, the authentication service 1138 MUST authenticate the sender of the message. 1140 Step 3: 1142 The authentication service SHOULD ensure that any preexisting Date 1143 header in the request is accurate. Local policy can dictate 1144 precisely how accurate the Date must be; a RECOMMENDED maximum 1145 discrepancy of ten minutes will ensure that the request is 1146 unlikely to upset any verifiers. If the Date header contains a 1147 time different by more than ten minutes from the current time 1148 noted by the authentication service, the authentication service 1149 SHOULD reject the request. This behavior is not mandatory because 1150 a user agent client (UAC) could only exploit the Date header in 1151 order to cause a request to fail verification; the SAML-Signature 1152 header is not intended to provide a source of non-repudiation or a 1153 perfect record of when messages are processed. Finally, the 1154 authentication service MUST verify that the Date header falls 1155 within the validity period of its certificate. 1157 Step 4: 1159 The authentication service MUST form the signature and add the 1160 SAML-Signature header to the request containing this signature. 1161 After the SAML-Signature header has been added to the request, the 1162 authentication service MUST also add an SAML-Info header. The 1163 SAML-Info header contains a URI from which the SAML assertion and 1164 a domain certificate can be acquired. 1166 Finally, the authentication service MUST forward the message 1167 normally. 1169 10. Verifier Behavior 1171 When a verifier receives a SIP message containing an SAML-Signature 1172 and SAML-Info header, it may inspect these two header fields. 1173 Typically, the results of a verification are provided as input to an 1174 authorization process that is outside the scope of this document. If 1175 an SAML-Info and SAML-Signature header is not present in a request, 1176 and one is required by local policy (for example, based on a per- 1177 sending-domain policy, or a per-sending-user policy), then a 428 'Use 1178 SAML Header' response MUST be sent. 1180 In order to verify the identity of the sender of a message, an entity 1181 acting as a verifier MUST perform the following steps, in the order 1182 here specified. 1184 Step 1: 1186 The verifier has to acquire the certificate for the signing 1187 domain. Implementations supporting this specification SHOULD have 1188 some means of retaining domain certificates (in accordance with 1189 normal practices for certificate lifetimes and revocation) in 1190 order to prevent themselves from needlessly downloading the same 1191 certificate every time a request from the same domain is received. 1192 Certificates cached in this manner should be indexed by the URI 1193 given in the SAML-Info header field value. 1195 Provided that the domain certificate used to sign this message is 1196 not previously known to the verifier, SIP entities SHOULD discover 1197 this certificate by dereferencing the SAML-Info header, unless 1198 they have some more efficient implementation-specific way of 1199 acquiring certificates for that domain. The domain certificate 1200 can be found in the SAML assertion, either by reference or by 1201 value. The verifier processes this certificate in the usual ways, 1202 including checking that it has not expired, that the chain is 1203 valid back to a trusted certification authority (CA), and that it 1204 does not appear on revocation lists. Once the certificate is 1205 acquired, it MUST be validated following the procedures in RFC 1206 3280 [RFC3280]. If the certificate cannot be validated (it is 1207 self-signed and untrusted, or signed by an untrusted or unknown 1208 certificate authority, expired, or revoked), the verifier MUST 1209 send a 437 'Unsupported Certificate' response. 1211 Step 2: 1213 The verifier MUST follow the process described in Section 13.4 of 1214 [RFC4474] to determine if the signer is authoritative for the URI 1215 in the From header field. 1217 Step 3: 1219 The verifier MUST verify the signature in the SAML-Signature 1220 header field, following the procedures for generating the hashed 1221 digest-string described in Section 12. If a verifier determines 1222 that the signature on the message does not correspond to the 1223 reconstructed digest- string, then a 479 'Invalid SAML Assertion' 1224 response MUST be returned. 1226 Step 4: 1228 The verifier MUST validate the Date, Contact, and Call-ID headers. 1229 It must furthermore ensure that the value of the Date header falls 1230 within the validity period of the certificate whose corresponding 1231 private key was used to sign the Identity header. 1233 11. SAML-Info Header Field 1235 This document introduces the SIP header field "SAML-Info" to carry a 1236 reference to a SAML assertion. This header MAY appear in any SIP 1237 header and MAY also appear more than once. 1239 The grammar for this header is (following the ABNF [RFC4234] in 1240 Section 25 of RFC 3261 [RFC3261]): 1242 SAML-Info = 1243 "SAML-Info" HCOLON ident-info *( SEMI ident-info-params ) 1245 ident-info = LAQUOT absoluteURI RAQUOT 1247 ident-info-params = generic-param 1249 Figure 6: SAML-Info ABNF grammar 1251 The "absoluteURI" portion of the SAML-Info header MUST contain a URI 1252 which dereferences to a resource containing a SAML assertion. All 1253 implementations of this specification MUST support the use of HTTP 1254 and HTTPS URIs in the SAML-Info header. Such HTTP and HTTPS URIs 1255 MUST follow the conventions of RFC 2585 [RFC2585], and for those URIs 1256 the indicated resource MUST be of the form 'application/ 1257 samlassertion+xml' described in that specification. 1259 No parameters are defined for the SAML-Info header in this document. 1260 Future experimental RFCS may define additional SAML-Info header 1261 parameters. 1263 This document adds the following entries to Table 2 of RFC 3261 1264 [RFC3261]: 1266 Header field where proxy ACK BYE CAN INV OPT REG 1267 ------------ ----- ----- --- --- --- --- --- --- 1268 SAML-Info R a o o - o o o 1270 SUB NOT REF INF UPD PRA 1271 --- --- --- --- --- --- 1272 o o o o o o 1274 Figure 7: New SAML-Info Row for RFC3261 Table 2 1276 The SAML-Info header MUST NOT appear in CANCEL. 1278 12. Extended RFC 4474 SIP Identity Signature Mechanism 1280 To allow the SIP Identity mechanism [RFC4474] to protect also the 1281 reference to the SAML assertion additional SIP header fields need to 1282 be protected by the signature calculation mechanisms. The extended 1283 signature computation is included in the SAML-Signature header field. 1285 The grammar for this new header is (following the ABNF [RFC4234] in 1286 RFC 3261 [RFC3261]): 1288 SAML-Signature = "SAML-Signature" HCOLON ( signed-identity-digest 1289 sig-info-fields sig-info-alg ) / sig-info-extension 1290 signed-identity-digest = LDQUOT 32LHEX RDQUOT 1291 sig-info-alg = "alg" EQUAL token 1292 sig-info-fields = "fields" EQUAL token 1293 sig-info-extension = generic-param 1295 The signed-identity-digest is a signed hash of a canonical string 1296 generated from certain components of a SIP request. To create the 1297 contents of the signed-identity-digest, the following elements of a 1298 SIP message MUST be placed in a bit-exact string in the order 1299 specified here, separated by a vertical line, "|" or %x7C, character: 1301 o The AoR of the UA sending the message, or addr-spec of the From 1302 header field (referred to occasionally here as the 'identity 1303 field'). 1305 o The addr-spec component of the To header field, which is the AoR 1306 to which the request is being sent. 1308 o The callid from Call-Id header field. 1310 o The digit (1*DIGIT) and method (method) portions from CSeq header 1311 field, separated by a single space (ABNF SP, or %x20). Note that 1312 th CSeq header field allows linear whitespace (LWS) rather than SP 1313 to separate the digit and method portions, and thus the CSeq 1314 header field may need to be transformed in order to be 1315 canonicalized. The authentication service MUST strip leading 1316 zeros from the 'digit' portion of the Cseq before generating the 1317 digest-string. 1319 o The Date header field, with exactly one space each for each SP and 1320 the weekday and month items case set as shown in BNF in RFC 3261. 1321 RFC 3261 specifies that the BNF for weekday and month is a choice 1322 amongst a set of tokens. The RFC 2234 rules for the BNF specify 1323 that tokens are case sensitive. However, when used to construct 1324 the canonical string defined here, the first letter of each week 1325 and month MUST be capitalized, and the remaining two letters must 1326 be lowercase. This matches the capitalization provided in the 1327 definition of each token. All requests that use the Identity 1328 mechanism MUST contain a Date header. 1330 o The addr-spec component of the Contact header field value. If the 1331 request does not contain a Contact header, this field MUST be 1332 empty (i.e., there will be no whitespace between the fourth and 1333 fifth "|" characters in the canonical string). 1335 o The sig-info-params parameter contains a list of SIP header fields 1336 whose values have to be included into the signature calculation. 1337 The individual field names in small letters are encoded in the 1338 token parameter of the sig-info-fields, each name separated by a 1339 "|" character. 1341 o The body content of the message with the bits exactly as they are 1342 in the Message (in the ABNF for SIP, the message-body). This 1343 includes all components of multipart message bodies. Note that 1344 the message-body does NOT include the CRLF separating the SIP 1345 headers from the message-body, but does include everything that 1346 follows that CRLF. If the message has no body, then message-body 1347 will be empty, and the final "|" will not be followed by any 1348 additional characters. 1350 The precise formulation of this digest-string is, therefore 1351 (following the ABNF [RFC4234] in RFC 3261 [RFC3261]): 1353 digest-string = addr-spec "|" addr-spec "|" callid "|" 1354 1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|" 1355 sigfields "|" message-body 1357 The signfields parameter represent the concatination of the values of 1358 the SIP header fields that are included in the signature calculation. 1360 Note again that the first addr-spec MUST be taken from the From 1361 header field value, the second addr-spec MUST be taken from the To 1362 header field value, and the third addr-spec MUST be taken from the 1363 Contact header field value, provided the Contact header is present in 1364 the request. 1366 After the digest-string is formed, it MUST be hashed and signed with 1367 the certificate for the domain. The hashing and signing algorithm is 1368 specified by the 'alg' parameter. This document defines only one 1369 value for the 'alg' parameter: 'rsa-sha1'. All implementations of 1370 this specification MUST support 'rsa-sha1'. When the 'rsa-sha1' 1371 algorithm is specified in the 'alg' parameter of Identity-Info, the 1372 hash and signature MUST be generated as follows: compute the results 1373 of signing this string with sha1WithRSAEncryption as described in RFC 1374 3370 [RFC3370] and base64 encode the results as specified in RFC 3548 1375 [RFC3548]. A 1024-bit or longer RSA key MUST be used. The result is 1376 placed in the SAML-Signature header field. 1378 This document adds the following entries to Table 2 of RFC 3261 1379 [RFC3261]: 1381 Header field where proxy ACK BYE CAN INV OPT REG 1382 ------------ ----- ----- --- --- --- --- --- --- 1383 SAML-Signature R a o o - o o o 1385 SUB NOT REF INF UPD PRA 1386 --- --- --- --- --- --- 1387 o o o o o o 1389 Note, in the table above, that this mechanism does not protect the 1390 CANCEL method. The CANCEL method cannot be challenged, because it is 1391 hop-by-hop, and accordingly authentication service behavior for 1392 CANCEL would be significantly limited. Note as well that the 1393 REGISTER method uses Contact header fields in very unusual ways that 1394 complicate its applicability to this mechanism, and the use of 1395 Identity with REGISTER is consequently a subject for future study, 1396 although it is left as optional here for forward-compatibility 1397 reasons. The SAML-Signature header MUST NOT appear in CANCEL. 1399 13. Security Considerations 1401 This section discusses security considerations when using SAML with 1402 SIP. 1404 13.1. Man-in-the-Middle Attacks and Stolen Assertions 1406 Threat: 1408 By making SAML assertions available via HTTP-based requests by a 1409 potentially unbounded set of requesters, it is conceivably 1410 possible that anyone would be able to simply request one and 1411 obtain it. By SIP intermediaries on the signaling path for 1412 example. Or, an HTTP intermediary/proxy could intercept the 1413 assertion as it is being returned to a requester. 1415 The attacker could then conceivably attempt to impersonate the 1416 subject (the putative caller) to some SIP-based target entity. 1418 Countermeasures: 1420 Such an attack is implausible for several reasons. The primary 1421 reason is that a message constructed by an imposter using a stolen 1422 assertion that conveys the public key certificate of some domain 1423 will not verify because the values in the SAML assertion, which 1424 are tied to the SIP message, will not verify. 1426 Also, the SIP SAML assertion profile specified herein that the 1427 subject's SAML assertion must adhere to causes it to be not useful 1428 to arbitrary parties. The subject's assertion: 1430 * should be signed, thus causing any alterations to break its 1431 integrity and make such alterations detectable. 1433 * relying party is represented in the SAML assertion's Audience 1434 Restriction. 1436 * Issuer is represented in the SAML assertion. 1438 * validity period for assertion is restricted. 1440 13.2. Forged Assertion 1442 Threat: 1444 A malicious user could forge or alter a SAML assertion in order to 1445 communicate with the SIP entities. 1447 Countermeasures: 1449 To avoid this kind of attack, the entities must assure that proper 1450 mechanisms for protecting the SAML assertion are employed, e.g., 1451 signing the SAML assertion itself. Section 5.1 of 1452 [OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. 1454 Additionally, the assertion content dictated by the SAML assertion 1455 profile herein ensures ample evidence for a relying party to 1456 verify the assertion and its relationship with the received SIP 1457 request. 1459 13.3. Replay Attack 1461 Threat: 1463 Theft of SIP message protected by the mechanisms described herein 1464 and replay of it at a later time. 1466 Countermeasures: 1468 The SAML assertion may contain several elements to prevent replay 1469 attacks. There is, however, a clear tradeoff between the 1470 replaying an assertion and re-using it over multiple SIP 1471 exchanges/sessions. 1473 14. Contributors 1475 The authors would like to thank Marcus Tegnander and Henning 1476 Schulzrinne for his contributions to earlier versions of this 1477 document. 1479 15. Acknowledgments 1481 We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida 1482 Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki 1483 Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen 1484 Fries and Vijay Gurbani for their comments to this draft. The "AS- 1485 driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based 1486 on an idea by Jon Peterson. 1488 We would also like to thank Eric Rescorla for his expert review. 1490 16. IANA Considerations 1492 16.1. Header Field Names 1494 This document specifies two new SIP header fields: 'SAML-Info' (see 1495 Section 11 and 'SAML-Signature' (see Section 12). IANA is requested 1496 to add these two headers to the header sub-registry under 1497 http://www.iana.org/assignments/sip-parameters. 1499 Header Name: SAML-Info 1501 Compact Form: y 1503 Header Name: SAML-Signature 1505 Compact Form: y 1507 16.2. 477 'Binding to SIP Message failed' Response Code 1509 This document registers a new SIP response code. It is sent when a 1510 verifier receives a SAML assertion but the Subject and Condition 1511 elements cannot be matched to the content in the SIP message, i.e., 1512 the binding between the SIP message and the SAML assertion cannot be 1513 accomplished. This response code is defined by the following 1514 information, which has been added to the method and response-code 1515 sub-registry under http://www.iana.org/assignments/sip-parameters. 1517 Response Code Number: 477 1519 Default Reason Phrase: Binding to SIP Message failed 1521 16.3. 478 'Unknown SAML Assertion Content' Response Code 1523 This document registers a new SIP response code. It is used when the 1524 verifier is unable to parse the content of the SAML assertion, 1525 because, for example, the assertion contains only unknown elements in 1526 in the SAML assertion, or the SAML assertion XML document is garbled. 1527 This response code is defined by the following information, which has 1528 been added to the method and response-code sub-registry under 1529 http://www.iana.org/assignments/sip-parameters. 1531 Response Code Number: 478 1533 Default Reason Phrase: Unknown SAML Assertion Content 1535 16.4. 479 'Invalid SAML Assertion' Response Code 1537 This document registers a new SIP response code. It is used when the 1538 verifier is unable to process the SAML assertion. A verifier may be 1539 unable to process the SAML assertion in case the assertion is self- 1540 signed, or signed by a root certificate authority for whom the 1541 verifier does not possess a root certificate. This response code is 1542 defined by the following information, which has been added to the 1543 method and response-code sub-registry under 1544 http://www.iana.org/assignments/sip-parameters. 1546 Response Code Number: 479 1548 Default Reason Phrase: Invalid SAML Assertion 1550 16.5. 480 'Use SAML Header' Response Code 1552 This document registers a new SIP response code. It is used when a 1553 SAML-Info and SAML-Signature header is not present in a request, and 1554 one is required by local policy (for example, based on a per-sending- 1555 domain policy, or a per-sending-user policy). This response code is 1556 defined by the following information, which has been added to the 1557 method and response-code sub-registry under 1558 http://www.iana.org/assignments/sip-parameters. 1560 Response Code Number: 480 1562 Default Reason Phrase: Use SAML Header 1564 17. Change Log 1566 RFC Editor - Please remove this section before publication. 1568 17.1. -05 to -06 1570 In response to the review comments by Eric Rescorla a new signature 1571 SIP header field was added. 1573 17.2. -04 to -05 1575 Changed the document type to experimental 1577 Removed option tag 1579 Added the Caller-driven SIP SAML Conveyed Assertion Profile 1581 Defined a new header (SAML-Info) 1583 Changed the description for usage with this new header 1585 Updated security considerations 1587 Minor editorial cleanups 1589 17.3. -03 to -04 1591 Updated IANA consideration section. 1593 Added option tag 1595 Updated acknowledgments section 1597 Minor editorial changes to the security considerations section 1599 17.4. -02 to -03 1601 Denoted that this I-D is intended to update RFC4474 per SIP working 1602 group consensus at IETF-69. This is the tact adopted in order to 1603 address the impedance mismatch between the nature of the URIs 1604 specified as to be placed in the Identity-Info header field, and what 1605 is specified in RFC4474 as the allowable value of that header field. 1607 Added placeholder "TBD" section for a to-be-determined "call-by- 1608 value" profile, per SIP working group consensus at IETF-69. 1610 Removed use-case appendicies (per recollection of JHodges during 1611 IETF-69 discussion as being WG consensus, but such is not noted in 1612 the minutes). 1614 17.5. -00 to -02 1616 Will detail in -04 rev. 1618 18. References 1620 18.1. Normative References 1622 [OASIS.saml-bindings-2.0-os] 1623 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1624 Maler, "Bindings for the OASIS Security Assertion Markup 1625 Language (SAML) V2.0", OASIS 1626 Standard saml-bindings-2.0-os, March 2005. 1628 [OASIS.saml-core-2.0-os] 1629 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1630 "Assertions and Protocol for the OASIS Security Assertion 1631 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1632 2.0-os, March 2005. 1634 [OASIS.saml-metadata-2.0-os] 1635 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 1636 "Metadata for the Security Assertion Markup Language 1637 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 1638 March 2005. 1640 [OASIS.saml-profiles-2.0-os] 1641 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1642 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1643 Security Assertion Markup Language (SAML) V2.0", OASIS 1644 Standard OASIS.saml-profiles-2.0-os, March 2005. 1646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1647 Requirement Levels", BCP 14, RFC 2119, March 1997. 1649 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1650 Locators", RFC 2392, August 1998. 1652 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1653 Infrastructure Operational Protocols: FTP and HTTP", 1654 RFC 2585, May 1999. 1656 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1657 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1658 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1660 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1661 A., Peterson, J., Sparks, R., Handley, M., and E. 1662 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1663 June 2002. 1665 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1666 X.509 Public Key Infrastructure Certificate and 1667 Certificate Revocation List (CRL) Profile", RFC 3280, 1668 April 2002. 1670 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1671 Algorithms", RFC 3370, August 2002. 1673 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1674 Method", RFC 3515, April 2003. 1676 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1677 Encodings", RFC 3548, July 2003. 1679 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1680 IETF URN Sub-namespace for Registered Protocol 1681 Parameters", BCP 73, RFC 3553, June 2003. 1683 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 1684 Authenticated Identity Body (AIB) Format", RFC 3893, 1685 September 2004. 1687 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1688 Specifications: ABNF", RFC 4234, October 2005. 1690 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 1691 "Trait-Based Authorization Requirements for the Session 1692 Initiation Protocol (SIP)", RFC 4484, August 2006. 1694 [W3C.xmldsig-core] 1695 Eastlake, D., Reagle , J., and D. Solo, "XML-Signature 1696 Syntax and Processing", W3C Recommendation xmldsig-core, 1697 October 2000, . 1699 18.2. Informative References 1701 [IANA.application.samlassertion-xml] 1702 OASIS Security Services Technical Committee (SSTC), 1703 "application/samlassertion+xml MIME Media Type 1704 Registration", IANA MIME Media Types Registry application/ 1705 samlassertion+xml, December 2004. 1707 [OASIS.saml-conformance-2.0-os] 1708 Mishra, P., Philpott, R., and E. Maler, "Conformance 1709 Requirements for the Security Assertion Markup Language 1710 (SAML) V2.0", OASIS Standard saml-conformance-2.0-os, 1711 March 2005. 1713 [OASIS.saml-glossary-2.0-os] 1714 Hodges, J., Philpott, R., and E. Maler, "Glossary for the 1715 Security Assertion Markup Language (SAML) V2.0", OASIS 1716 Standard saml-glossary-2.0-os, March 2005. 1718 [OASIS.saml-sec-consider-2.0-os] 1719 Hirsch, F., Philpott, R., and E. Maler, "Security and 1720 Privacy Considerations for the OASIS Security Markup 1721 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 1722 2.0-os, March 2005. 1724 [OASIS.sstc-saml-exec-overview-2.0-cd-01] 1725 Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", 1726 OASIS SSTC Committee 1727 Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. 1729 [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] 1730 Cantor, S., "SAML Protocol Extension for Third-Party 1731 Requests", OASIS SSTC Committee Draft sstc-saml-protocol- 1732 ext-thirdparty-cd-01, March 2006. 1734 [OASIS.sstc-saml-tech-overview-2.0-draft-16] 1735 Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen, 1736 P., and T. Scavo, "Security Assertion Markup Language 1737 (SAML) V2.0 Technical Overview", OASIS SSTC Working 1738 Draft sstc-saml-tech-overview-2.0-draft-16, May 2008. 1740 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1741 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1742 March 1999. 1744 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1745 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1746 September 1999. 1748 [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute 1749 Certificate Profile for Authorization", RFC 3281, 1750 April 2002. 1752 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1753 Initiation Protocol (SIP)", RFC 3323, November 2002. 1755 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1756 Authenticated Identity Management in the Session 1757 Initiation Protocol (SIP)", RFC 4474, August 2006. 1759 Authors' Addresses 1761 Hannes Tschofenig 1762 Nokia Siemens Networks 1763 Linnoitustie 6 1764 Espoo 02600 1765 Finland 1767 Phone: +358 (50) 4871445 1768 Email: Hannes.Tschofenig@gmx.net 1769 URI: http://www.tschofenig.priv.at 1771 Jeff Hodges 1772 Unaffiliated 1774 Email: Jeff.Hodges@KingsMountain.com 1776 Jon Peterson 1777 NeuStar, Inc. 1778 1800 Sutter St Suite 570 1779 Concord, CA 94520 1780 US 1782 Email: jon.peterson@neustar.biz 1784 James Polk 1785 Cisco 1786 2200 East President George Bush Turnpike 1787 Richardson, Texas 75082 1788 US 1790 Email: jmpolk@cisco.com 1792 Douglas C. Sicker 1793 University of Colorado at Boulder 1794 ECOT 430 1795 Boulder, CO 80309 1796 US 1798 Email: douglas.sicker@colorado.edu