idnits 2.17.1 draft-tschofenig-sip-saml-02.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.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1201. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2004) is 7101 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: 'RFC2543' is defined on line 1127, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.hodges-saml-mediatype' == Outdated reference: A later version (-02) exists of draft-ietf-sipping-trait-authz-00 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-trait-authz (ref. 'I-D.ietf-sipping-trait-authz') == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-03 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-certs-00 == Outdated reference: A later version (-06) exists of draft-jennings-sipping-pay-00 -- No information found for draft-liberty-idff-arch-overview - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP H. Tschofenig 3 Internet-Draft Siemens 4 Expires: May 2, 2005 J. Peterson 5 NeuStar, Inc. 6 J. Polk 7 Cisco 8 D. Sicker 9 CU Boulder 10 M. Tegnander 11 LYIT 12 November 2004 14 Using SAML for SIP 15 draft-tschofenig-sip-saml-02.txt 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 2, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2004). 48 Abstract 49 This document describes how to use the Security Assertion Markup 50 Language (SAML) to offer trait-based authorization. As such, it 51 provides an alternative to existing authorization mechanisms for SIP. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5 58 4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6 59 4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3 Request/Response Protocol . . . . . . . . . . . . . . . . 7 62 4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9 65 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6.1 Network Asserted Identities . . . . . . . . . . . . . . . 14 67 6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 16 68 6.3 PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 17 69 6.4 Compensation using SIP and SAML . . . . . . . . . . . . . 18 70 7. SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . . 20 71 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 23 73 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 74 10.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . 24 75 10.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . 24 76 10.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . 24 77 10.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . 25 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 81 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 83 15.1 Normative References . . . . . . . . . . . . . . . . . . . 32 84 15.2 Informative References . . . . . . . . . . . . . . . . . . 32 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 86 Intellectual Property and Copyright Statements . . . . . . . 35 88 1. Introduction 90 This document proposes a method for using the Security Assertion 91 Markup Language (SAML) in collaboration with SIP to accommodate 92 richer authorization mechanisms and enable trait- based authorization 93 where you are authenticated using roles or traits instead of 94 identity. A motivation for trait based authorization and some 95 scenarios are presented in [I-D.ietf-sipping-trait-authz]. 97 Security Assertion Markup Language (SAML) 98 [I-D.saml-tech-overview-1.1-03] is an XML extension for security 99 information exchange that is being developed by OASIS. SAML is a 100 XML-based framework for creating and exchanging security information. 102 To provide trait-based authorization a few solutions are possible: 103 authorization certificates, SPKI or extensions to the authenticated 104 identity body [I-D.ietf-sip-authid-body]. The authors selected SAML 105 due to the amount of work done in the area of SAML which provides 106 some assurance that this technology is mature enough. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 The SIP entity 'Authentication Service' was introduced with 115 [I-D.ietf-sip-identity]. We reuse this term to refer to an entity 116 that authenticates and authorizes a user and creates an assertion. 117 This entity is the equivalent of the asserting party in the SAML 118 terminology. 120 For terminology related to SAML the reader is referred to 121 [I-D.saml-tech-overview-1.1-03]. 123 3. Goals and Non-Goals 125 This document tries to accomplish the following goals: 127 o This document defines how SAML assertions are carried in the SIP. 128 As such, the usage of SAML assertions within SIP can be seen as a 129 SAML profile. 131 o The requirements and scenarios defined in 132 [I-D.ietf-sipping-trait-authz] are compared to the solution 133 described in this document by utilizing SAML assertions. 135 The following issues are outside the scope of this document: 137 o The configuration of the Authentication Service in order to attach 138 certain assertions is outside the scope of this specification and 139 might depend on the environment where SIP is used. To avoid 140 restricting the functionality of SIP either as an in-band or an 141 out-of-band mechanism, it can be defined to trigger the inclusion 142 of SAML assertions. SAML itself provides mechanisms for this 143 purpose. 145 o The attributes stored in assertions are, for example, roles, 146 membership to a certain organization, specific access rights or 147 information about the authentication. A definition of most of 148 these attributes is application dependent and not defined in this 149 document. The SAML specification itself provides a number of 150 common attributes and provides extension points for future 151 enhancements. A brief overview of the available attributes within 152 an assertion is given in Section 4.1. 154 o SIP is not used as a request/response protocol between the Relying 155 Party and the Asserting Party to fetch an assertion based on a 156 received artifact. 158 4. SAML Introduction 160 In SAML there are three main entities: the user, the asserting party 161 and the relying party. A user requests an assertions and receives 162 them after a successful authentication and authorization protocol 163 execution. The asserting party provides assurance that a particular 164 user has been given proper authorization. The relying party has to 165 trust the asserting party with regard to the provided information and 166 then decides whether or not to accept the assertions provided, giving 167 different levels of privileges. 169 The components of SAML are: 171 o Assertions/Artifact 173 o Request/Response protocols 175 o Bindings 177 o Profiles 179 We describe each in turn below 181 4.1 Assertions 183 An assertion is a package of information including authentication 184 statements, attribute statements and authorization decision 185 statements. All of statements do not have to be present, but at 186 least one does. An assertion contains several elements: 188 Issuing information: 190 Who issued the assertion, when was it issued and the assertion 191 identifier. 193 Subject information: 195 The name of the subject, the security domain and optional subject 196 information, like public key. 198 Conditions under which the assertion is valid: 200 Special kind of conditions like assertion validity period, 201 audience restriction and target restriction. 203 Additional advice: 205 Explaining how the assertion was made, for example. 207 In an authentication statement, an issuing authority asserts that a 208 certain subject was authenticated by certain means at a certain time. 210 In an attribute statement, an issuing authority asserts that a 211 certain subject is associated with certain attributes which has 212 certain values. For example, user jon@cs.example.com is associated 213 with the attribute 'Department', which has the value 'Computer 214 Science'. 216 In an authorization decision statement, a certain subject with a 217 certain access type to a certain resource has given certain evidence 218 that the identity is correct. Based on this, the relying party then 219 makes the decision on giving access or not. The subject could be a 220 human or a program, the resource could be a webpage or a web service, 221 for example. 223 4.2 Artifact 225 The artifact used in the Browser/Artifact profile, is a base-64 226 encoded string that is 40 bytes long. 20 bytes consists of the 227 typecode, which is the source id. The remaining 20 bytes consists of 228 a random number that servers use to look up an assertion. The source 229 server stores the assertion temporarily. The destination server 230 receives the artifact and pulls the assertion from the source site. 231 The purpose of the artifact is to act as a token that references an 232 assertion for the subject who holds the artifact. 234 4.3 Request/Response Protocol 236 SAML defines a request/response protocol for obtaining assertions. 237 The request asks for an assertion or makes queries for 238 authentication, attribute and authorization decisions. The response 239 carries back the requested assertion. 241 4.4 Bindings 243 The bindings in SAML maps between the SAML protocol and a transport 244 and messaging protocol. With SAML Version 1.1 there is only one 245 binding specified, which is SAML embedded in SOAP-over-HTTP. In a 246 binding, a transport and messaging protocol is used only for 247 transporting the request/response mechanism. 249 4.5 Profiles 251 When using a profile, SAML is used to provide assertions about a 252 resource in the body of the message itself. In Version 1.1 of SAML, 253 there are two profiles specified, the Browser/Artifact profile and 254 the Browser/POST profile. The Browser/Artifact profile represents a 255 "pull" model, where a special reference to the assertion called an 256 artifact, is sent to the relying party from the asserting party. The 257 artifact is then used to "pull" the assertion from the asserting 258 party. The Browser/POST profile represents a "push" model, where an 259 assertion is posted (using the HTTP POST command) directly to the 260 relying party. These two models are described in Figure 1 and Figure 261 2. 263 5. Assertion Handling Models 265 As mentioned in Section 4.5, two main models can be used in SAML and 266 therefore also with the SIP-SAML extension defined in this document: 267 The Push and the Pull model. 269 In the Pull model the end host requests an assertion from the 270 Asserting Party and receives, after successful authentication and 271 authorization, an artifact. The artifact is a special form of an 272 assertion. This artifact can be compared with the call-by reference 273 approach where a reference to the assertion is stored at the 274 Asserting Party and can later be dereferenced into the real assertion 275 on a request by a replying party. The Relying Party later fetches 276 the SAML assertion after receiving a request by the user which 277 includes the artifact. For communicating the SAML request and 278 response messages, a separate message exchange is needed with a 279 protocol such as SOAP or HTTP. This is outside the scope of this 280 document. 282 +----------+ +--------------+ +--------------+ 283 | User | | Asserting | | Relying | 284 | | | Party | | Party | 285 +----+-----+ +------+-------+ +------+-------+ 286 | | | 287 | Request Assertion | | 288 |--------------------->| | 289 | | | 290 | User Authentication | | 291 | and Authorization | | 292 |<---------------------| | 293 |--------------------->| | 294 | | | 295 | Artifact | | 296 |<---------------------| | 297 | | | 298 | Request + Artifact | 299 |----------------------+------------------------->| 300 | | | 301 | | SAML request | 302 | |<-------------------------| 303 | | | 304 | |SAML response + Assertion | 305 | |------------------------->| 306 | | | 307 | Accept/Reject | 308 |<---------------------+--------------------------| 309 | | | 311 Figure 1: SAML Pull model 313 With the Push model, the user requests an assertion from the 314 Asserting Party. The user can also trigger the Asserting Party to 315 attach an assertion to the request. The assertion, which is added to 316 the service request, can be verified by the Relying Party without 317 additional protocol interactions with the Asserting Party. The 318 assertion therefore contains enough information to authorize the 319 service request. This model realizes a call-by value style of 320 communication. 322 +----------+ +--------------+ +--------------+ 323 | User | | Asserting | | Relying | 324 | | | Party | | Party | 325 +----+-----+ +------+-------+ +------+-------+ 326 | | | 327 | Request Assertion | | 328 |--------------------->| | 329 | | | 330 | | | 331 | User Authentication | | 332 | and Authorization | | 333 |<---------------------| | 334 |--------------------->| | 335 | | | 336 | | | 337 | Assertion | | 338 |<---------------------| | 339 | | | 340 | Request + Assertion | 341 |----------------------+------------------------->| 342 | | | 343 | | | 344 | Accept/Reject | 345 |<---------------------+--------------------------| 346 | | | 348 Figure 2: SAML Push model 350 The usage of SAML in HTTP-based environments and in SIP is, however, 351 affected by some architectural differences. 353 The function of the entities in the Push and the Pull model are shown 354 in Figure 1 and in Figure 2. 356 The user has to request an assertion at the Asserting Party and both 357 entities mutually authenticate each other. The requested assertion 358 is sent to the user in a confidential manner to prevent eavesdroppers 359 from obtaining this assertion. The Relying Party trusts the 360 Asserting Party. It is assumed that the accessed resource is located 361 at the Relying Party and that this entity does not become malicious 362 or act on behalf of the user to impersonate him or her to other 363 parties with regard to access to his resources. To prevent some 364 degree of misuse, attributes in the assertion limit its applicability 365 for certain applications, servers or time frame. 367 Signaling in SIP can, however, involve a number of entities in more 368 complex scenarios. As an example, the scenario addressed in 369 [I-D.ietf-sip-identity] aims to replace end-to-end authentication via 370 S/MIME by a "mediated authentication architecture". The end hosts 371 only need to be able to verify assertions signed by an Authentication 372 Service which guarantees that the sender was authenticated. 374 Directly applying SAML to such a scenario, however, causes a problem: 375 a SIP proxy, which securely receives a SAML assertion (such as 376 confidentially protected to prevent eavesdroppers between the SIP UA 377 and the SIP proxy to learn the assertion), can store this assertion 378 to impersonate the user in future requests towards other SIP end 379 users. The fact that multiple parties see the assertion along the 380 path (i.e., SIP proxies) make the situation worse. The assertion 381 might include some attributes which restrict its usage (such as 382 recipient(s), unique identifier for the message or a time-based 383 constraint) but they cannot fully prevent impersonation. 385 This problem appears if SAML assertions are not bound to a particular 386 protocol run. Binding the assertion to a particular protocol session 387 is not useful if the property of single-sign on is required. 389 To provide referential integrity, a solution as mentioned in 390 [I-D.ietf-sip-authid-body] can be used. which allows a party in a 391 SIP transaction to cryptographically sign the headers that assert the 392 identity of the originator of a message, and provide some other 393 headers necessary for reference integrity. An authenticated identity 394 body (AIB) is a MIME body of type 'message/sipfrag'. This MIME body 395 has a Content-Disposition type of 'aib'. The MIME body is optional. 396 The header fields From, Contact, Date and Call-ID must be used for 397 providing identity. Contact and Date header fields are required for 398 providing reference integrity. AIBs may contain other headers that 399 help to uniquely identify the transaction or that provides related 400 reference integrity. 402 The requirements for a non-INVITE AIB is very much the same as for an 403 INVITE: From, Call-ID, Date and Contact header fields are required. 404 The same that goes for requests also goes for responses with some 405 small differences. The From header field of the AIB in the response 406 to an INVITE must correspond to the address-of-record of the 407 responder and not the From header field in the received request. The 408 To header field of the request must not be included. A new Date 409 header field has to be generated for the response while the Call-ID 410 and CSeq are copied from the request. 412 Following is an example of the format of an AIB for an INVITE: 414 Content-Type: message/sipfrag 415 Content-Disposition: aib; handling=optional 417 From: Alice 418 To: Bob 419 Contact: 420 Date: Thu, 26 Aug 2004 13:51:34 GMT 421 Call-ID: b76m5l94s90835 422 CSeq: 435431 INVITE 424 Figure 3: AIB Format for an INVITE 426 The same concept is applicable to this document as well with regard 427 to reference integrity. For a further discussion on this topic see 428 Section 14 and [I-D.peterson-message-identity]. 430 6. Scenarios 432 This section shows message flows based on scenarios in 433 [I-D.ietf-sipping-trait-authz] enriched with a SAML based solution. 434 Section 6.1 provides an example of enhanced network asserted 435 identities and Section 6.2 shows a SIP conferencing scenario with 436 role-based access control using SAML. A future version of this 437 document will cover more scenarios from 438 [I-D.ietf-sipping-trait-authz]. 440 6.1 Network Asserted Identities 442 Figure 4 shows an enhanced network asserted identity scenario based 443 on [I-D.ietf-sip-identity] which again utilizes extensions proposed 444 with [I-D.ietf-sip-authid-body]. The enhancement is based on the 445 attributes asserted by the Authentication Service. 447 Figure 4 shows three entities, Alice@example.com, AS@example.com and 448 Bob@example2.com. If Alice wants to communicate with Bob, she sends 449 a SIP INVITE to her preferred AS. Depending on the chosen SIP 450 security mechanism either digest authentication, S/MIME or Transport 451 Layer Security is used to provide the AS with a strong assurance 452 about the identity of Alice. During this step authorization 453 attributes for inclusion into the SAML assertion can be selected. 455 After Alice is authenticated and authorized, a SAML assertion is 456 attached to the SIP message. The Authentication Service can be 457 configured to attach a number of assertions, not limited to the 458 authenticated identity. 460 To bind the SAML assertion to a specific SIP session, it is necessary 461 for the AS to compute a hash of some fields of the message. A list 462 of the fields to hash is described in [I-D.ietf-sip-identity] and 463 particularly in [I-D.ietf-sip-authid-body]. The hash is digitally 464 signed and inserted into the SAML assertion and placed into the SAML 465 header. The SAML header also contains information about the entity 466 which created the digital signature. Upon reception of the message, 467 Bob verifies the signature of the SAML assertion and verifies the 468 binding to the SIP message in order to prevent cut-and-paste attacks. 469 The provided SAML assertion can then be used to assist during the 470 authorization procedure. If Bob does not understand the extension 471 defined in this document, he silently ignores it. When the 200 OK 472 message arrives at Bob's AS, the same procedure as when Alice sent 473 her INVITE to her AS can be performed, if desired. This exchange is 474 not shown in Figure 4. 476 Note that this scenario does not imply that the SAML assertions are 477 solely used by SIP UAs. Assertions can also be helpful for SIP 478 proxies or B2B UAs. Additionally, a push model is shown in this 479 section but it is reasonable to use a pull as well. For simplicity 480 reasons a push model should be prefered since an additional message 481 exchange between the Authentication Service and the UA can be 482 omitted. 484 +--------+ +--------------+ +--------+ 485 |Alice@ | |Authentication| | Bob@ | 486 |example | |Service | |example2| 487 |.com | |@example.com | |com | 488 | | | | | | 489 +---+----+ +------+-------+ +---+----+ 490 | | | 491 | INVITE | | 492 |---------------------->| | 493 | From:alice@foo.com | | 494 | | | 495 | 407 Proxy auth. req. | | 496 |<----------------------| | 497 | Challenge | | 498 | | | 499 | Challenge response | | 500 |---------------------->| | 501 | | | 502 | INVITE | | 503 |---------------------->| | 504 | | INVITE | 505 | | + SAML assertion | 506 | |--------------------->| 507 | | | 508 | 200 OK | | 509 |<----------------------+----------------------| 510 | | | 512 Figure 4: Network Asserted Identities 514 A variation of the scenario presented in Figure 4 is given in Figure 515 5 where an end host (Alice@example.com) obtains an assertion from its 516 SIP proxy server which acts as an Authentication Service. This 517 assertion is then attached by the end host to the outgoing INVITE 518 message. Unlike in case of an artifact, Bob@example.com does not 519 need to contact the Proxy Server. 521 An example of this scenario could be to preempt a lower priority call 522 if enough assurance for doing so is presented in the attached SAML 523 assertion. This would also mean that there is a priority value 524 included in the INVITE (for example in the Resource-Priority Header). 526 +--------+ +--------------+ +--------+ 527 | Alice@ | |Proxy Server | | Bob@ | 528 |example | |(AS | |example | 529 |.com | |@example.com | |.com | 530 | | | | | | 531 +---+----+ +------+-------+ +---+----+ 532 | | | 533 | INVITE | | 534 |---------------------->| | 535 | From:alice@example.com| | 536 | | | 537 | 407 Proxy auth. req. | | 538 |<----------------------| | 539 | SAML Auth Header | | 540 | to use | | 541 | | | 542 | INVITE + SAML assertion | 543 |-----------------------+--------------------->| 544 | | | 545 | 200 OK | | 546 |<----------------------+----------------------| 547 | | | 549 Figure 5: End host attaching SAML Assertion 551 Note that Bob and Alice do not need to be in the same administrative 552 domain. It is feasible that Bob is in a domain that is federated 553 with Alice's domain. 555 The assertion obtained by Alice@example.com needs to be associated 556 with a particular SIP messaging session. How to achieve this binding 557 is for further consideration. 559 6.2 SIP Conferencing 561 This section is meant to raise some discussions about the usage of 562 SAML in the domain of conferencing. A user who routes its SIP 563 message through the Authentication Service (Asserting Party) towards 564 a conferencing server may want SAML assertions to be included. The 565 following properties could be provided by this procedure: 567 o The user identity can be replaced to allow the user to be 568 anonymous with regard to the Focus 570 o The user identity could be asserted to the Focus 572 o The SAML assertion could provide additional information such as 573 group membership (belongs to the students, staff, faculty group of 574 university X). This could, for non-identity-based authorization 575 systems, imply certain rights. 577 The corresponding SIP message flow (in high level detail) could have 578 the following shape: 580 +-----+ +-----------+ +-----------+ 581 | | | SIP Proxy | | Focus | 582 |User | |(Asserting | | (Relying | 583 | | | party) | | party) | 584 +--+--+ +-----+-----+ +-----+-----+ 585 | INVITE | | 586 |sip:conf-factory | | 587 |------------------>| INVITE+SAML | 588 | |------------------>| 589 | | | 590 | | Ringing | 591 | Ringing |<------------------| 592 |<------------------| | 593 | | | 594 | | OK | 595 | OK |<------------------| 596 |<------------------| | 597 | | | 598 | ACK | | 599 |------------------>| ACK | 600 | |------------------>| 601 | | | 602 | | | 603 ... many more msgs... 605 Figure 6: SIP Conferencing and SAML 607 6.3 PSTN-to-SIP Phone Call 609 Alice, using a phone connected to the PSTN, wants to make a call to 610 Bob, which resides in a SIP network. Her call is switched through 611 the PSTN by means of PSTN signaling (outside the scope of this 612 document) to the PSTN/SIP gateway. At the gateway, the call is 613 converted from SS7 signaling to SIP signaling. Since Alice was 614 previously 'authenticated' through PSTN signaling mechanisms, the 615 gateway can create an assertion based on signaling information from 616 Alice and digitally sign it with his private key. Alice's call is 617 forwarded from the SIP/PSTN gateway to Bob's phone. Bob can certify 618 that the identity of Alice is correct by examining the SAML 619 assertion. 621 +-----------+ 622 +----------------------+ | | 623 | | SS7 | SIP/PSTN | 624 | Public Switched |--------------------->| Gateway | 625 | | | | 626 | | | | 627 | Telephone Network | +--+-----------+----+ 628 | ^ | | | | 629 +---------+------------+ | | SIP+SAML | 630 | SS7 | v | 631 | | +--------+ | 632 O | | | | 633 O /|\ <----+----| SIP | | 634 /|\ / \ SIP+ | Proxy | | 635 / \ Bob SAML | | | 636 Alice | +--------+ | 637 | SIP based | 638 | Network | 639 +-------------------+ 641 Figure 7: PSTN to SIP call 643 6.4 Compensation using SIP and SAML 645 This section briefly elaborates a scenario where SAML is used in SIP 646 to realize compensation functionality as described in 647 [I-D.jennings-sipping-pay] 649 Section 1 of [I-D.jennings-sipping-pay] shows a message exchange 650 which is used by a number of payment protocols and hence can also be 651 used by a SAML specified protocol. To avoid repetition in this 652 document a second alternative is provided in Figure 8. Alice 653 initiates a communication with an Authentication Service which acts 654 as a financial institution. Note that Alice does not necessarily 655 need to use SIP for communication with the Authentication Service. 656 Instead, it might be possible to use HTTP or other protocols which 657 offer the necessary user credential or offer additional information 658 (such as a web page). After a successful authentication and 659 authorization Alice obtains an assertion (or an artifact) which might 660 contain payment relevant information. For a later service access, 661 Alice contacts the merchant Bob with the assertion. Bob verifies the 662 assertion and, it might want to contact the Authentication Service 663 for a credit check. A financial settlement between the merchant Bob 664 and the Trusted Third Party is assumed. Depending on the type of 665 service, a one-time payment with immediate amount deduction may take 666 place (e.g., in case of a prepaid account) or the amount is captured 667 as a batch transaction. 669 The aspect of lightweight protocol execution is provided by 671 o The alternative usage of an artifact which leads to a lower 672 bandwidth consumption. 674 o The ability to use a single assertion for multiple service access 675 protocol executions, if desired. 677 o SAML, furthermore allows a cryptographic key to be bound to an 678 assertion. A high degree of flexibility is provided with regard 679 to the possible credentials. For example, it might not be 680 necessary to use public key cryptography with every service 681 access. This might be useful if the cost of public key 682 cryptographic is too expensive for a cheap service or when devices 683 have performance limitations. In this case, it might be useful to 684 rely on symmetric cryptographic, such as hash chains. 686 +--------+ +--------------+ +--------+ 687 |User | |Authentication| |Merchant| 688 |Alice | |Server | |Bob | 689 | | |(Trusted Third| | | 690 | | | Party) | | | 691 +---+----+ +------+-------+ +---+----+ 692 | | | 693 | SIP, HTTP, etc. | | 694 |---------------------->| | 695 | | | 696 | Assertion | | 697 |<----------------------| | 698 | | | 699 | | | 700 | INVITE + SAML assertion | 701 |-----------------------+--------------------->| 702 | | | 703 | 200 OK | | 704 |<----------------------+----------------------| 705 | | | 707 Figure 8: Message flow for SIP payment 709 The main difference between the above-described mechanism and the one 710 described in Section 1 of [I-D.jennings-sipping-pay] is the degree of 711 user involvement and the type of protocol interaction. In both cases 712 it is possible to provide an indication to the user about the costs 713 of a service access. In fact, the assertion might specify these type 714 of constraints directly or indirectly with the help of recurring 715 service requests/responses. 717 7. SIP-SAML Extension 719 To carry SAML assertions and artifacts two mechanisms are defined: 721 o The SIP header may either carry an Artifcat or a CID URI [RFC2392] 722 pointing to an assertion in the SIP body. The name of this new 723 SIP header is SAML-Payload. A SAML artifact consists of a 724 TypeCode, SourceID and an AssertionHandle. It is thereby assumed 725 that the Relying Party will maintain a table of sourceID values as 726 well as URLs for Asserting Parties to contact. This information 727 is communicated out-of-band. This document also allows the 728 Asserting Party to add a URL to point to the assertion to prevent 729 this level of indirection. 731 o The SIP body may carry one or more SAML assertions. The MIME type 732 of this SAML assertion is defined in [I-D.hodges-saml-mediatype]. 734 A SIP user agent may add an assertion to the body of a SIP message or 735 may add a reference to the assertion into the SIP header. SIP 736 proxies MUST NOT add the assertion to the body. The SIP header MUST 737 be used instead when an assertion has to be added. 739 A SAML assertion SHOULD be protected and when added by a SIP entity 740 then S/MIME MUST be used rather than XML digital signatures. 742 To bind a SAML assertion to a SIP message a few selected SIP message 743 fields are input to a hash function. The digest-string, defined in 744 Section 10 of [I-D.ietf-sip-identity], is included into the 745 conditions extension point of the SAML assertion. Details are for 746 further study. 748 8. Example 750 This is an example of a SAML assertion and how it is structured in 751 XML. 753 760 762 765 766 767 NameQualifier=alice@example.com 768 Format="urn:oasis:names:tc:SAML:1.1:nameid- 769 format:emailAddress">uid=alice 770 771 772 773 urn:oasis:names:tc:SAML:1.0: 774 cm:SIP-artifact-01 775 776 777 778 779 781 The elements in the assertion have the following meaning: 783 +---------------------+-----+-------------------------------+ 784 | Tag name |Req- | Description | 785 | |uired| | 786 +---------------------+-----+-------------------------------+ 787 |MajorVersion | X |Major version of the assertion | 788 +---------------------+-----+-------------------------------+ 789 |MinorVersion | X |Minor version of the assertion | 790 +---------------------+-----+-------------------------------+ 791 |AssertionID | X |ID of the assertion | 792 +---------------------+-----+-------------------------------+ 793 |Issuer | X |The name of the SAML authority | 794 | | |that created the assertion | 795 +---------------------+-----+-------------------------------+ 796 |IssuerInstant | X |Issuing time of the assertion | 797 +---------------------+-----+-------------------------------+ 798 | | |Conditions that MUST be taken | 799 |Conditions | |into account when assessing | 800 | | |the validity of the assertion | 801 +---------------------+-----+-------------------------------+ 802 | | |Specifies | 803 |AuthenticationMethod | X |what kind of authentication | 804 | | |took place | 805 +---------------------+-----+-------------------------------+ 806 |AuthenticationInstant| X |Specifies the time when the | 807 | | |authentication took place | 808 +---------------------+-----+-------------------------------+ 809 |Qualifier | |The name by which the subject | 810 | | |is recognized | 811 +---------------------+-----+-------------------------------+ 812 | | |A URI reference representing | 813 |Format | |the format of NameIdentifier | 814 | | | | 815 +---------------------+-----+-------------------------------+ 816 | | |Specifies a subject by supply- | 817 |SubjectConfirmation | |ing data that allows the sub- | 818 | | |ject to be authenticated | 819 +---------------------+-----+-------------------------------+ 820 | | |Identifies | 821 |ConfirmationMethod | |which method to be used for | 822 | | |authenticating the subject | 823 +---------------------+-----+-------------------------------+ 825 Figure 10: Tag descriptions 827 9. Requirement Comparison 829 A future version of this document will compare the requirements 830 listed in [I-D.ietf-sipping-trait-authz] with the solution provided 831 in this document. 833 10. Security Considerations 835 This section discusses security considerations when using SAML with 836 SIP. 838 10.1 Stolen Assertion 840 Threat: 842 If an eavesdropper can copy the real user's SAML response and 843 included assertions and construct a SIP message of his own, then 844 the eavesdropper could be able to impersonate the user at other 845 SIP entities. 847 Countermeasures: 849 By providing adequate confidentiality, eavesdropping of a SAML 850 assertion can be stopped. 852 10.2 MitM Attack 854 Threat: 856 Since the SAML assertion is carried within a SIP message, a 857 malicious site could impersonate the user at some other SIP 858 entities. These SIP entities would believe the adversary to be 859 the subject of the assertion. 861 Countermeasures: 863 If the adversary is a not-participating in the SIP signaling 864 itself (i.e., it is not a SIP proxy or a SIP UA), this threat can 865 be eliminated by employing inherent SIP security mechanisms, such 866 as TLS. However, if this entity is part of the communication 867 itself then reference integrity needs to be provided. Assertions 868 with tight restrictions (e.g., validity of the assertion) can also 869 limit the possible damage. 871 10.3 Forged Assertion 873 Threat: 875 A malicious user could forge or alter a SAML assertion in order to 876 communicate with the SIP entities. 878 Countermeasures: 880 To avoid this kind of attack, the entities must assure that proper 881 mechanisms for protecting the SAML assertion needs to be in place. 882 It is recommended to protect the assertion using a digital 883 signature. 885 10.4 Replay Attack 887 Threat: 889 In the case of using SIP with the SAML pull model, the threat of 890 replay lies in the fact that the artifact is a one-time-use 891 subject. The same artifact can be used again to gain access to 892 resources. 894 Countermeasures: 896 Cases where multiple requests are made which references the same 897 request must be tracked in order to avoid the threat. 899 11. Contributors 901 The authors would like to thank Henning Schulzrinne for his 902 contributions to this document. 904 12. Acknowledgments 906 We would like to thank RL 'Bob' Morgan and Stefan Goeman for their 907 comments to this draft. 909 13. IANA Considerations 911 This document contains a number of IANA considerations. A future 912 version of this document will list them in this section. 914 14. Open Issues 916 This document raises a number of issues with regard to the SIP 917 protocol interaction. Some of them are raised in this document (such 918 as reference integrity, who is allowed to add which information, 919 etc.) but a more detailed treatment of this topic with a focus of 920 identity management is described in [I-D.peterson-message-identity]. 921 In particular, the following sections are highly relevant for this 922 document: 924 Assertion Constraints and Scope: 926 This aspect deals with the problem of binding a SIP assertion to a 927 specific SIP message. The goal is to provide a security property 928 called reference integrity to prevent replay and impersonation 929 attacks. As described in Section 5 that a number of fields can be 930 used for this purpose. This document also considers scenarios 931 where the SAML assertion was obtained outside a SIP protocol run. 932 In these cases SIP fields are not available to provide reference 933 integrity. The concept of the holder-of-the-key assertion is 934 described below and relevant for this discussion. 936 Canonicalization versus Replication: 938 To provide reference integrity a few selected fields need to be 939 hashed, signed and placed into the assertion. Two approaches are 940 available for this purpose. Hence it needs to be studied how the 941 interworking between reference integrity and the usage of obtained 942 SAML assertion can be properly accomplished. For example, who 943 indicates which fields are included? 945 Placement of Assertions and Keys in Messages: 947 This document assumes that the assertions are added to the SIP 948 body and artifacts or references to assertions located in the SIP 949 body are added to the SIP header. A central question is therefore 950 where these assertions should be attached? Should the SIP user 951 agent or intermediate SIP proxies add assertions/artifacts? In the 952 scenarios depicted in Section 6, we have both approaches depending 953 on what kind of scenario it is. In Figure 4, they are added at 954 the UA and in contrast we have Figure 7, where the assertions are 955 added at the PSTN/SIP gateway. 957 MIME bodies can only be attached at the UA. Proxies by definition 958 do not attach MIME bodies; if an intermediary were to do so, it 959 would not be playing the proxy server role in the SIP 960 architecture. The SIP content indirection mechanism 961 [I-D.ietf-sip-content-indirect-mech] is also relevant in this 962 discussion. 964 To provide reference integrity (by binding a SIP session and a SAML 965 assertion together) two alternative approaches exist: 967 Hashing of SIP message fields: 969 If a hash is computed over a number of selected SIP fields and 970 subsequently digitally signed then there is a some degree of 971 protection that the assertion cannot be copied to other SIP 972 messages and reused. The drawback thereby is that the assertion 973 has a very limited time period. The hashed fields may vary from 974 context to context. 976 Holder-of-the-Key Assertion: 978 SAML introduces the concept of a holder-of-the-key assertion to 979 bind the assertions (authorization information) to a cryptographic 980 key. As a result, the end host which was quite passive when 981 dealing with assertions can be turned into an active protocol 982 participant. The end host obtained the assertion and attached 983 them to selected messages but did not provide any cryptographic 984 computations with regard to the assertion itself. With the end 985 host being active in the protocol exchange security is improved a 986 lot. Furthermore, it is possible to combine the benefits of the 987 work done with SIPPING-CERT [I-D.ietf-sipping-certs] and this 988 document by binding a self-signed certificate created by the user 989 and stored at the credential server to an assertion. As noted in 990 Section 9 of [I-D.ietf-sipping-certs] in the context of signing 991 SIP messages the usage of a self-signed certificate is not very 992 helpful except used with an Authentication Service. Combined with 993 a SAML assertion the signature would protect the SIP message and 994 the SAML assertion would provide authorization information. 996 A number of credentials can be used with the KeyInfo element of the 997 Holder-of-the-Key assertion as described in Section 4.4 of 998 [xmldsig-core]. 1000 Further open issues are: 1002 o Some work on option-tags is required. Are there cases when 1003 processing of the assertion would be required by the sender? Or 1004 when a proxy server wants to be able to say that a UA must supply 1005 this header in order to access a particular resource? If so, an 1006 option-tag should be defined for this extension that can be used 1007 in Require, Supported, 420, etc. 1009 o Specific SAML confirmation method identifiers and identifiers for 1010 the bindings or profiles must be defined and registered with 1011 OASIS. A confirmation method identifier is a URI that specifies 1012 which method should be used by the target domain to assure that 1013 the identity of the subject is true. 1015 This mechanism seems to be provide the same reference integrity 1016 properties as the hash over the various headers/bodies proposed in 1017 the identity draft. 1019 o Further use cases would be interesting. For example, a mechanism 1020 to provide additional security for the SIP REFER method [RFC3515]. 1022 o A few new URIs need to be registered. The proposed URIs for 1023 identification are: 1025 SIP Binding: urn:oasis:names:tc:SAML:1.0:bindings:SIP-binding 1027 Artifact profile: 1028 urn:oasis:names:tc:SAML:1.0:profiles:SIP-artifact-01 1030 Assertion profile: 1031 urn:oasis:names:tc:SAML:1.0:profiles:SIP-assertion-01 1033 o The proposed URIs for Confirmation Method Identifiers are: 1035 Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01 1037 Assertion profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer 1039 o These are based on the URIs already used in the existing SOAP-SAML 1040 binding, specified in Section 3 of [I-D.saml-bindings-1.1]. 1042 o An alignment with the work done by Liberty Alliance on Federated 1043 Identities as described in [I-D.liberty-idff-arch-overview] would 1044 be useful. 1046 o The security consideration needs more details. 1048 15. References 1050 15.1 Normative References 1052 [I-D.hodges-saml-mediatype] 1053 Hodges, J., "application/saml+xml Media Type 1054 Registration", draft-hodges-saml-mediatype-01 (work in 1055 progress), June 2004. 1057 [I-D.ietf-sipping-trait-authz] 1058 Peterson, J., "Trait-based Authorization Requirements for 1059 the Session Initiation Protocol (SIP)", 1060 draft-ietf-sipping-trait-authz-00 (work in progress), 1061 February 2004. 1063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1064 Requirement Levels", March 1997. 1066 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1067 Locators", RFC 2392, August 1998. 1069 15.2 Informative References 1071 [I-D.ietf-sip-authid-body] 1072 Peterson, J., "SIP Authenticated Identity Body (AIB) 1073 Format", draft-ietf-sip-authid-body-03 (work in progress), 1074 May 2004. 1076 [I-D.ietf-sip-content-indirect-mech] 1077 Burger, E., "A Mechanism for Content Indirection in 1078 Session Initiation Protocol (SIP) Messages", 1079 draft-ietf-sip-content-indirect-mech-05 (work in 1080 progress), October 2004. 1082 [I-D.ietf-sip-identity] 1083 Peterson, J., "Enhancements for Authenticated Identity 1084 Management in the Session Initiation Protocol (SIP)", 1085 draft-ietf-sip-identity-03 (work in progress), September 1086 2004. 1088 [I-D.ietf-sipping-certs] 1089 Jennings, C. and J. Peterson, "Certificate Management 1090 Service for SIP", draft-ietf-sipping-certs-00 (work in 1091 progress), October 2004. 1093 [I-D.jennings-sipping-pay] 1094 Jennings, C., "Payment for SIP Services", 1095 draft-jennings-sipping-pay-00 (work in progress), July 1096 2004. 1098 [I-D.liberty-idff-arch-overview] 1099 Wason, T., "Liberty ID-FF Architecture Overview", 2004. 1101 [I-D.peterson-message-identity] 1102 Peterson, J., "Security Considerations for Impersonation 1103 and Identity in Messaging Systems", 1104 draft-peterson-message-identity-00 (work in progress), 1105 October 2004. 1107 [I-D.saml-bindings-1.1] 1108 Maler, E., Philpott, R. and P. Mishra, "Bindings and 1109 Profiles for the OASIS Security Assertion Markup Language 1110 (SAML) V1.1", September 2003. 1112 [I-D.saml-core-1.1] 1113 Maler, E., Philpott, R. and P. Mishra, "Assertions and 1114 Protocol for the OASIS Security Assertion Markup Language 1115 (SAML) V1.1", September 2003. 1117 [I-D.saml-sec-consider-1.1] 1118 Maler, E. and R. Philpott, "Security and Privacy 1119 Considerations for the OASIS Security Markup Language 1120 (SAML) V1.1", September 2003. 1122 [I-D.saml-tech-overview-1.1-03] 1123 Maler, E. and J. Hughes, "Technical Overview of the OASIS 1124 Security Assertion Markup Language (SAML) V1.1", March 1125 2004. 1127 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. 1128 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1129 March 1999. 1131 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1132 Method", RFC 3515, April 2003. 1134 [xmldsig-core] 1135 Eastlake, D., Reagle, J. and D. Solo, "XML-Signature 1136 Syntax and Processing, W3C Recommendation (available at 1137 http://www.w3.org/TR/xmldsig-core/)", February 2002. 1139 Authors' Addresses 1141 Hannes Tschofenig 1142 Siemens 1143 Otto-Hahn-Ring 6 1144 Munich, Bavaria 81739 1145 Germany 1147 EMail: Hannes.Tschofenig@siemens.com 1149 Jon Peterson 1150 NeuStar, Inc. 1151 1800 Sutter St Suite 570 1152 Concord, CA 94520 1153 US 1155 EMail: jon.peterson@neustar.biz 1157 James Polk 1158 Cisco 1159 2200 East President George Bush Turnpike 1160 Richardson, Texas 75082 1161 US 1163 EMail: jmpolk@cisco.com 1165 Douglas C. Sicker 1166 University of Colorado at Boulder 1167 ECOT 430 1168 Boulder, CO 80309 1169 US 1171 EMail: douglas.sicker@colorado.edu 1173 Marcus Tegnander 1174 Letterkenny Institute of Technology 1175 Port Road 1176 Letterkenny, Donegal 1177 Ireland 1179 Intellectual Property Statement 1181 The IETF takes no position regarding the validity or scope of any 1182 Intellectual Property Rights or other rights that might be claimed to 1183 pertain to the implementation or use of the technology described in 1184 this document or the extent to which any license under such rights 1185 might or might not be available; nor does it represent that it has 1186 made any independent effort to identify any such rights. Information 1187 on the procedures with respect to rights in RFC documents can be 1188 found in BCP 78 and BCP 79. 1190 Copies of IPR disclosures made to the IETF Secretariat and any 1191 assurances of licenses to be made available, or the result of an 1192 attempt made to obtain a general license or permission for the use of 1193 such proprietary rights by implementers or users of this 1194 specification can be obtained from the IETF on-line IPR repository at 1195 http://www.ietf.org/ipr. 1197 The IETF invites any interested party to bring to its attention any 1198 copyrights, patents or patent applications, or other proprietary 1199 rights that may cover technology that may be required to implement 1200 this standard. Please address the information to the IETF at 1201 ietf-ipr@ietf.org. 1203 Disclaimer of Validity 1205 This document and the information contained herein are provided on an 1206 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1207 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1208 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1209 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1210 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1211 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1213 Copyright Statement 1215 Copyright (C) The Internet Society (2004). This document is subject 1216 to the rights, licenses and restrictions contained in BCP 78, and 1217 except as set forth therein, the authors retain all their rights. 1219 Acknowledgment 1221 Funding for the RFC Editor function is currently provided by the 1222 Internet Society.