idnits 2.17.00 (12 Aug 2021) /tmp/idnits42609/draft-tschofenig-sip-saml-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1239. ** 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. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 293 has weird spacing: '...iece of infor...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 18, 2005) is 6150 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: 'I-D.ietf-sip-content-indirect-mech' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'RFC2543' is defined on line 1163, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.hodges-saml-mediatype' == Outdated reference: draft-ietf-sipping-trait-authz has been published as RFC 4484 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-trait-authz (ref. 'I-D.ietf-sipping-trait-authz') == Outdated reference: draft-ietf-sip-authid-body has been published as RFC 3893 == Outdated reference: draft-ietf-sip-content-indirect-mech has been published as RFC 4483 == Outdated reference: draft-ietf-sip-identity has been published as RFC 4474 == Outdated reference: A later version (-03) exists of draft-ietf-sipping-certs-01 == Outdated reference: A later version (-06) exists of draft-jennings-sipping-pay-01 -- 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: 4 errors (**), 0 flaws (~~), 11 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: January 19, 2006 J. Peterson 5 NeuStar, Inc. 6 J. Polk 7 Cisco 8 D. Sicker 9 CU Boulder 10 M. Tegnander 11 LYIT 12 July 18, 2005 14 Using SAML for SIP 15 draft-tschofenig-sip-saml-04.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on January 19, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document defines a mechanism for using the Security Assertion 49 Markup Language (SAML) in concert with the Session Initiation 50 Protocol (SIP). In particular, it provides a way for SIP to refer to 51 SAML objects, and for recipients of SIP messages to use SAML in order 52 to make more informed authorization decisions. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5 59 4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6 60 4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3 Request/Response Protocol . . . . . . . . . . . . . . . . 7 63 4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9 66 6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6.1 Network Asserted Identities . . . . . . . . . . . . . . . 14 68 6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 16 69 6.3 PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 17 70 6.4 Compensation using SIP and SAML . . . . . . . . . . . . . 18 71 7. SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . . 20 72 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 23 74 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 75 10.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . 24 76 10.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . 24 77 10.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . 24 78 10.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . 25 79 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 80 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 82 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 84 15.1 Normative References . . . . . . . . . . . . . . . . . . 32 85 15.2 Informative References . . . . . . . . . . . . . . . . . 32 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 87 Intellectual Property and Copyright Statements . . . . . . . 35 89 1. Introduction 91 This document proposes a method for using the Security Assertion 92 Markup Language (SAML) in collaboration with SIP to accommodate 93 richer authorization mechanisms and enable trait- based authorization 94 where you are authenticated using roles or traits instead of 95 identity. A motivation for trait based authorization and some 96 scenarios are presented in [I-D.ietf-sipping-trait-authz]. 98 Security Assertion Markup Language (SAML) [I-D.saml-tech-overview- 99 1.1-03] is an XML extension for security information exchange that is 100 being developed by OASIS. SAML is a XML-based framework for creating 101 and exchanging security information. 103 To provide trait-based authorization a few solutions are possible: 104 authorization certificates, SPKI or extensions to the authenticated 105 identity body [I-D.ietf-sip-authid-body]. The authors selected SAML 106 due to its increasing use in environments such as the Liberty 107 Alliance and the Internet2 project, areas where the applicability to 108 SIP is widely desired. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 The SIP entity 'Authentication Service' was introduced with 117 [I-D.ietf-sip-identity]. We reuse this term to refer to an entity 118 that authenticates and authorizes a user and creates an assertion. 119 This entity is the equivalent of the asserting party in the SAML 120 terminology. 122 For terminology related to SAML the reader is referred to [I-D.saml- 123 tech-overview-1.1-03]. 125 3. Goals and Non-Goals 127 This document tries to accomplish the following goals: 129 o This document defines how SAML assertions are carried in the SIP. 130 As such, the usage of SAML assertions within SIP can be seen as a 131 SAML profile. 133 o The requirements and scenarios defined in [I-D.ietf-sipping-trait- 134 authz] are compared to the solution described in this document by 135 utilizing SAML assertions. 137 The following issues are outside the scope of this document: 139 o The configuration of the Authentication Service in order to attach 140 certain assertions is outside the scope of this specification and 141 might depend on the environment where SIP is used. To avoid 142 restricting the functionality of SIP either as an in-band or an 143 out-of-band mechanism, it can be defined to trigger the inclusion 144 of SAML assertions. SAML itself provides mechanisms for this 145 purpose. 147 o The attributes stored in assertions are, for example, roles, 148 membership to a certain organization, specific access rights or 149 information about the authentication. A definition of most of 150 these attributes is application dependent and not defined in this 151 document. The SAML specification itself provides a number of 152 common attributes and provides extension points for future 153 enhancements. A brief overview of the available attributes within 154 an assertion is given in Section 4.1. 156 In order for SAML to be used in a practical system, participating 157 entities must agree on attributes and traits that will be used. 158 Without this pre-existing agreement, SAML cannot be usefully 159 deployed. This document does not discuss the manner in which 160 participating entites might discover one another or agree on the 161 syntax and semantics of attributes and traits. 163 o SIP is not used as a request/response protocol between the Relying 164 Party and the Asserting Party to fetch an assertion based on a 165 received artifact. 167 4. SAML Introduction 169 In SAML there are three main entities: the user, the asserting party 170 and the relying party. A user requests assertions and receives them 171 after a successful authentication and authorization protocol 172 execution. The asserting party provides assurance that a particular 173 user has been given proper authorization. The relying party has to 174 trust the asserting party with regard to the provided information and 175 then decides whether or not to accept the assertions provided, giving 176 different levels of privileges. 178 The components of SAML are: 180 o Assertions/Artifact 182 o Request/Response protocols 184 o Bindings 186 o Profiles 188 We describe each in turn below 190 4.1 Assertions 192 An assertion is a package of information including authentication 193 statements, attribute statements and authorization decision 194 statements. All of statements do not have to be present, but at 195 least one does. An assertion contains several elements: 197 Issuing information: 199 Who issued the assertion, when was it issued and the assertion 200 identifier. 202 Subject information: 204 The name of the subject, the security domain and optional subject 205 information, like public key. 207 Conditions under which the assertion is valid: 209 Special kind of conditions like assertion validity period, 210 audience restriction and target restriction. 212 Additional advice: 214 Explaining how the assertion was made, for example. 216 In an authentication statement, an issuing authority asserts that a 217 certain subject was authenticated by certain means at a certain time. 219 In an attribute statement, an issuing authority asserts that a 220 certain subject is associated with certain attributes which has 221 certain values. For example, user jon@cs.example.com is associated 222 with the attribute 'Department', which has the value 'Computer 223 Science'. 225 In an authorization decision statement, a certain subject with a 226 certain access type to a certain resource has given certain evidence 227 that the identity is correct. Based on this, the relying party then 228 makes the decision on giving access or not. The subject could be a 229 human or a program, the resource could be a webpage or a web service, 230 for example. 232 4.2 Artifact 234 The artifact used in the Browser/Artifact profile, is a base-64 235 encoded string that is 40 bytes long. 20 bytes consists of the 236 typecode, which is the source id. The remaining 20 bytes consists of 237 a random number that servers use to look up an assertion. The source 238 server stores the assertion temporarily. The destination server 239 receives the artifact and pulls the assertion from the source site. 240 The purpose of the artifact is to act as a token that references an 241 assertion for the subject who holds the artifact. 243 Note that artifacts were designed to be used specifically in a web 244 context where the asserting party is clear due to the client/server 245 nature of the protocol. Artifacts are not globally-derefenceable; 246 one cannot tell simply be inspecting an artifact out of context which 247 server generated the artifact. For the more peer-to-peer 248 architecture of SIP, enhancements are required to make the context of 249 artifact generation known to relying parties. 251 4.3 Request/Response Protocol 253 SAML defines a request/response protocol for obtaining assertions. 254 The request asks for an assertion or makes queries for 255 authentication, attribute and authorization decisions. The response 256 carries back the requested assertion. 258 4.4 Bindings 260 The bindings in SAML maps between the SAML protocol and a transport 261 and messaging protocol. With SAML Version 1.1 there is only one 262 binding specified, which is SAML embedded in SOAP-over-HTTP. In a 263 binding, a transport and messaging protocol is used only for 264 transporting the request/response mechanism. 266 4.5 Profiles 268 When using a profile, SAML is used to provide assertions about a 269 resource in the body of the message itself. In Version 1.1 of SAML, 270 there are two profiles specified, the Browser/Artifact profile and 271 the Browser/POST profile. The Browser/Artifact profile represents a 272 "pull" model, where a special reference to the assertion called an 273 artifact, is sent to the relying party from the asserting party. The 274 artifact is then used to "pull" the assertion from the asserting 275 party. The Browser/POST profile represents a "push" model, where an 276 assertion is posted (using the HTTP POST command) directly to the 277 relying party. These two models are described in Figure 2 and 278 Figure 1. 280 5. Assertion Handling Models 282 As mentioned in Section 4.5, two main models can be used in SAML and 283 therefore also with the SIP-SAML extension defined in this document: 284 The Push and the Pull model. 286 A 'Push' model (or mode) means to transmit information towards 287 another entity. Here we call that transmitting the information 'by- 288 value'. An example of this model (or mode) is an email attachment 289 (file). That attachment is included in the original transmission, as 290 is 'by-value'. 292 Whereas, a 'Pull' model (or mode) means to transmit an identifier for 293 where a piece of information is (located somewhere else). This 294 piece of information still requires retrieval by the receiver of this 295 transmission. Here we call that transmitting the information 'by- 296 reference'. An example of this model (or mode) is including a URI in 297 that email, to be accessed directly by the receiver of the email in a 298 subsequent operation. 300 Either the end host or an intermediate proxy might request an 301 assertion or an artifact. The Push and the Pull model used for HTTP 302 does not match with its usage in SIP. 304 With the 'per-value' model either a user requests an assertion from 305 the Asserting Party or the user triggers the Asserting Party to 306 attach an assertion to the outgoing request. The assertion, which is 307 added to the service request, can be verified by the Relying Party 308 without additional protocol interactions with the Asserting Party. 309 The assertion therefore contains enough information to authorize the 310 service request. 312 Figure 1 shows the protocol exchange where the user fetches the 313 assertion. 315 +----------+ +--------------+ +--------------+ 316 | User | | Asserting | | Relying | 317 | | | Party | | Party | 318 +----+-----+ +------+-------+ +------+-------+ 319 | | | 320 | Request Assertion | | 321 |--------------------->| | 322 | | | 323 | User Authentication | | 324 | and Authorization | | 325 |<---------------------| | 326 |--------------------->| | 327 | | | 328 | Assertion | | 329 |<---------------------| | 330 | | | 331 | Request + Assertion | 332 |----------------------+------------------------->| 333 | | | 334 | | | 335 | Accept/Reject | 336 |<---------------------+--------------------------| 337 | | | 339 Figure 1: Example for a 'Per-value' Interaction 341 With the 'per-reference' model either the user contacts the Asserting 342 Party to obtain an artifact or the user triggers the Asserting Party 343 to attach the artifact to the outgoing request. The artifact is a 344 reference to an assertion is stored at the Asserting Party and can 345 later be dereferenced into the assertion on a request. The Relying 346 Party later fetches the SAML assertion after receiving the artifact 347 by the user. For communicating the SAML request and response 348 messages, a separate message exchange is needed with a protocol, such 349 as SOAP. A description of this protocol interaction is outside the 350 scope of this document. 352 Figure 2 shows an example protocol interaction where the user fetches 353 the artifact. 355 +----------+ +--------------+ +--------------+ 356 | User | | Asserting | | Relying | 357 | | | Party | | Party | 358 +----+-----+ +------+-------+ +------+-------+ 359 | | | 360 | Request Assertion | | 361 |--------------------->| | 362 | | | 363 | User Authentication | | 364 | and Authorization | | 365 |<---------------------| | 366 |--------------------->| | 367 | | | 368 | Artifact | | 369 |<---------------------| | 370 | | | 371 | Request + Artifact | 372 |----------------------+------------------------->| 373 | | | 374 | | SAML request | 375 | |<-------------------------| 376 | | | 377 | |SAML response + Assertion | 378 | |------------------------->| 379 | | | 380 | Accept/Reject | 381 |<---------------------+--------------------------| 382 | | | 384 Figure 2: Example for a 'Per-reference' Interaction 386 The usage of SAML in HTTP-based environments and in SIP is, however, 387 affected by some architectural differences. 389 The user has to request an assertion at the Asserting Party and both 390 entities mutually authenticate each other. The requested assertion 391 is sent to the user in a confidential manner to prevent eavesdroppers 392 from obtaining this assertion. The Relying Party trusts the 393 Asserting Party. It is assumed that the accessed resource is located 394 at the Relying Party and that this entity does not become malicious 395 or act on behalf of the user to impersonate him or her to other 396 parties with regard to access to his resources. To prevent some 397 degree of misuse, attributes in the assertion limit its applicability 398 for certain applications, servers or time frame. 400 Signaling in SIP can, however, involve a number of entities in more 401 complex scenarios. As an example, the scenario addressed in 402 [I-D.ietf-sip-identity] aims to replace end-to-end authentication via 403 S/MIME by a "mediated authentication architecture". The end hosts 404 only need to be able to verify assertions signed by an Authentication 405 Service which guarantees that the sender was authenticated. 407 Directly applying SAML to such a scenario, however, causes a problem: 408 a SIP proxy, which securely receives a SAML assertion (such as 409 confidentially protected to prevent eavesdroppers between the SIP UA 410 and the SIP proxy to learn the assertion), can store this assertion 411 to impersonate the user in future requests towards other SIP end 412 users. The fact that multiple parties see the assertion along the 413 path (i.e., SIP proxies) make the situation worse. The assertion 414 might include some attributes which restrict its usage (such as 415 recipient(s), unique identifier for the message or a time-based 416 constraint) but they cannot fully prevent impersonation. 418 This problem appears if SAML assertions are not bound to a particular 419 SIP transaction or dialog. Binding the assertion to a particular 420 protocol session is not useful if the property of single-sign on is 421 required. 423 To provide referential integrity the solution described in [I-D.ietf- 424 sip-authid-body] can be reused. Such an approach allows a party in a 425 SIP transaction to cryptographically sign the headers that assert the 426 identity of the originator of a message, and provide some other 427 headers necessary for reference integrity. An authenticated identity 428 body (AIB) is a MIME body of type 'message/sipfrag'. This MIME body 429 has a Content-Disposition type of 'aib'. The MIME body is optional. 430 The header fields From, Contact, Date and Call-ID must be used for 431 providing identity. Contact and Date header fields are required for 432 providing reference integrity. AIBs may contain other headers that 433 help to uniquely identify the transaction or that provides related 434 reference integrity. 436 The requirements for a non-INVITE AIB is very much the same as for an 437 INVITE: From, Call-ID, Date and Contact header fields are required. 438 The same that goes for requests also goes for responses with some 439 small differences. The From header field of the AIB in the response 440 to an INVITE must correspond to the address-of-record of the 441 responder and not the From header field in the received request. The 442 To header field of the request must not be included. A new Date 443 header field has to be generated for the response while the Call-ID 444 and CSeq are copied from the request. 446 Following is an example of the format of an AIB for an INVITE: 448 Content-Type: message/sipfrag 449 Content-Disposition: aib; handling=optional 451 From: Alice 452 To: Bob 453 Contact: 454 Date: Thu, 26 Aug 2004 13:51:34 GMT 455 Call-ID: b76m5l94s90835 456 CSeq: 435431 INVITE 458 Figure 3: AIB Format for an INVITE 460 The same concept is applicable to this document as well with regard 461 to reference integrity. For a further discussion on this topic see 462 Section 14 and [I-D.peterson-message-identity]. 464 6. Scenarios 466 This section shows message flows based on scenarios in [I-D.ietf- 467 sipping-trait-authz] enriched with a SAML based solution. 468 Section 6.1 provides an example of enhanced network asserted 469 identities and Section 6.2 shows a SIP conferencing scenario with 470 role-based access control using SAML. A future version of this 471 document will cover more scenarios from [I-D.ietf-sipping-trait- 472 authz]. 474 6.1 Network Asserted Identities 476 Figure 4 shows an enhanced network asserted identity scenario based 477 on [I-D.ietf-sip-identity] which again utilizes extensions proposed 478 with [I-D.ietf-sip-authid-body]. The enhancement is based on the 479 attributes asserted by the Authentication Service. 481 Figure 4 shows three entities, Alice@example.com, AS@example.com and 482 Bob@example2.com. If Alice wants to communicate with Bob, she sends 483 a SIP INVITE to her preferred AS. Depending on the chosen SIP 484 security mechanism either digest authentication, S/MIME or Transport 485 Layer Security is used to provide the AS with a strong assurance 486 about the identity of Alice. During this step authorization 487 attributes for inclusion into the SAML assertion can be selected. 489 After Alice is authenticated and authorized, a SAML assertion is 490 attached to the SIP message. The Authentication Service can be 491 configured to attach a number of assertions, not limited to the 492 authenticated identity. 494 To bind the SAML assertion to a specific SIP session, it is necessary 495 for the AS to compute a hash of some fields of the message. A list 496 of the fields to hash is described in [I-D.ietf-sip-identity] and 497 particularly in [I-D.ietf-sip-authid-body]. The hash is digitally 498 signed and inserted into the SAML assertion and placed into the SAML 499 header. The SAML header also contains information about the entity 500 which created the digital signature. Upon reception of the message, 501 Bob verifies the signature of the SAML assertion and verifies the 502 binding to the SIP message in order to prevent cut-and-paste attacks. 503 The provided SAML assertion can then be used to assist during the 504 authorization procedure. If Bob does not understand the extension 505 defined in this document, he silently ignores it. When the 200 OK 506 message arrives at Bob's AS, the same procedure as when Alice sent 507 her INVITE to her AS can be performed, if desired. This exchange is 508 not shown in Figure 4. 510 Note that this scenario does not imply that the SAML assertions are 511 solely used by SIP UAs. Assertions can also be helpful for SIP 512 proxies or B2B UAs. 514 +--------+ +--------------+ +--------+ 515 |Alice@ | |Authentication| | Bob@ | 516 |example | |Service | |example2| 517 |.com | |@example.com | |com | 518 | | | | | | 519 +---+----+ +------+-------+ +---+----+ 520 | | | 521 | INVITE | | 522 |---------------------->| | 523 | From:alice@foo.com | | 524 | | | 525 | 407 Proxy auth. req. | | 526 |<----------------------| | 527 | Challenge | | 528 | | | 529 | Challenge response | | 530 |---------------------->| | 531 | | | 532 | INVITE | | 533 |---------------------->| | 534 | | INVITE | 535 | | + SAML assertion | 536 | |--------------------->| 537 | | | 538 | 200 OK | | 539 |<----------------------+----------------------| 540 | | | 542 Figure 4: Network Asserted Identities 544 A variation of the scenario presented in Figure 4 is given in 545 Figure 5 where an end host (Alice@example.com) obtains an assertion 546 from its SIP proxy server which acts as an Authentication Service. 547 This assertion is then attached by the end host to the outgoing 548 INVITE message. Unlike in case of an artifact, Bob@example.com does 549 not need to contact the Proxy Server. 551 An example of this scenario could be to preempt a lower priority call 552 if enough assurance for doing so is presented in the attached SAML 553 assertion. This would also mean that there is a priority value 554 included in the INVITE (for example in the Resource-Priority Header). 556 +--------+ +--------------+ +--------+ 557 | Alice@ | |Proxy Server | | Bob@ | 558 |example | |(AS | |example | 559 |.com | |@example.com | |.com | 560 | | | | | | 561 +---+----+ +------+-------+ +---+----+ 562 | | | 563 | INVITE | | 564 |---------------------->| | 565 | From:alice@example.com| | 566 | | | 567 | 407 Proxy auth. req. | | 568 |<----------------------| | 569 | SAML Auth Header | | 570 | to use | | 571 | | | 572 | INVITE + SAML assertion | 573 |-----------------------+--------------------->| 574 | | | 575 | 200 OK | | 576 |<----------------------+----------------------| 577 | | | 579 Figure 5: End host attaching SAML Assertion 581 Note that Bob and Alice do not need to be in the same administrative 582 domain. It is feasible that Bob is in a domain that is federated 583 with Alice's domain. 585 The assertion obtained by Alice@example.com needs to be associated 586 with a particular SIP messaging session. How to achieve this binding 587 is for further consideration. 589 6.2 SIP Conferencing 591 This section is meant to raise some discussions about the usage of 592 SAML in the domain of conferencing. A user who routes its SIP 593 message through the Authentication Service (Asserting Party) towards 594 a conferencing server may want SAML assertions to be included. The 595 following properties could be provided by this procedure: 597 o The user identity can be replaced to allow the user to be 598 anonymous with regard to the Focus 600 o The user identity could be asserted to the Focus 602 o The SAML assertion could provide additional information such as 603 group membership (belongs to the students, staff, faculty group of 604 university X). This could, for non-identity-based authorization 605 systems, imply certain rights. 607 The corresponding SIP message flow (in high level detail) could have 608 the following shape: 610 +-----+ +-----------+ +-----------+ 611 | | | SIP Proxy | | Focus | 612 |User | |(Asserting | | (Relying | 613 | | | party) | | party) | 614 +--+--+ +-----+-----+ +-----+-----+ 615 | INVITE | | 616 |sip:conf-factory | | 617 |------------------>| INVITE+SAML | 618 | |------------------>| 619 | | | 620 | | Ringing | 621 | Ringing |<------------------| 622 |<------------------| | 623 | | | 624 | | OK | 625 | OK |<------------------| 626 |<------------------| | 627 | | | 628 | ACK | | 629 |------------------>| ACK | 630 | |------------------>| 631 | | | 632 | | | 633 ... many more msgs... 635 Figure 6: SIP Conferencing and SAML 637 6.3 PSTN-to-SIP Phone Call 639 Alice, using a phone connected to the PSTN, wants to make a call to 640 Bob, which resides in a SIP network. Her call is switched through 641 the PSTN by means of PSTN signaling (outside the scope of this 642 document) to the PSTN/SIP gateway. At the gateway, the call is 643 converted from SS7 signaling to SIP signaling. Since Alice was 644 previously 'authenticated' through PSTN signaling mechanisms, the 645 gateway can create an assertion based on signaling information from 646 Alice and digitally sign it with his private key. Alice's call is 647 forwarded from the SIP/PSTN gateway to Bob's phone. Bob can certify 648 that the identity of Alice is correct by examining the SAML 649 assertion. 651 +-----------+ 652 +----------------------+ | | 653 | | SS7 | SIP/PSTN | 654 | Public Switched |--------------------->| Gateway | 655 | | | | 656 | | | | 657 | Telephone Network | +--+-----------+----+ 658 | ^ | | | | 659 +---------+------------+ | | SIP+SAML | 660 | SS7 | v | 661 | | +--------+ | 662 O | | | | 663 O /|\ <----+----| SIP | | 664 /|\ / \ SIP+ | Proxy | | 665 / \ Bob SAML | | | 666 Alice | +--------+ | 667 | SIP based | 668 | Network | 669 +-------------------+ 671 Figure 7: PSTN to SIP call 673 6.4 Compensation using SIP and SAML 675 This section briefly elaborates a scenario where SAML is used in SIP 676 to realize compensation functionality as described in [I-D.jennings- 677 sipping-pay] 679 Section 1 of [I-D.jennings-sipping-pay] shows a message exchange 680 which is used by a number of payment protocols and hence can also be 681 used by a SAML specified protocol. To avoid repetition in this 682 document a second alternative is provided in Figure 8. Alice 683 initiates a communication with an Authentication Service which acts 684 as a financial institution. Note that Alice does not necessarily 685 need to use SIP for communication with the Authentication Service. 686 Instead, it might be possible to use HTTP or other protocols which 687 offer the necessary user credential or offer additional information 688 (such as a web page). After a successful authentication and 689 authorization Alice obtains an assertion (or an artifact) which might 690 contain payment relevant information. For a later service access, 691 Alice contacts the merchant Bob with the assertion. Bob verifies the 692 assertion and, it might want to contact the Authentication Service 693 for a credit check. A financial settlement between the merchant Bob 694 and the Trusted Third Party is assumed. Depending on the type of 695 service, a one-time payment with immediate amount deduction may take 696 place (e.g., in case of a prepaid account) or the amount is captured 697 as a batch transaction. 699 The aspect of lightweight protocol execution is provided by 701 o The alternative usage of an artifact which leads to a lower 702 bandwidth consumption. 704 o The ability to use a single assertion for multiple service access 705 protocol executions, if desired. 707 o SAML, furthermore allows a cryptographic key to be bound to an 708 assertion. A high degree of flexibility is provided with regard 709 to the possible credentials. For example, it might not be 710 necessary to use public key cryptography with every service 711 access. This might be useful if the cost of public key 712 cryptographic is too expensive for a cheap service or when devices 713 have performance limitations. In this case, it might be useful to 714 rely on symmetric cryptographic, such as hash chains. 716 +--------+ +--------------+ +--------+ 717 |User | |Authentication| |Merchant| 718 |Alice | |Server | |Bob | 719 | | |(Trusted Third| | | 720 | | | Party) | | | 721 +---+----+ +------+-------+ +---+----+ 722 | | | 723 | SIP, HTTP, etc. | | 724 |---------------------->| | 725 | | | 726 | Assertion | | 727 |<----------------------| | 728 | | | 729 | | | 730 | INVITE + SAML assertion | 731 |-----------------------+--------------------->| 732 | | | 733 | 200 OK | | 734 |<----------------------+----------------------| 735 | | | 737 Figure 8: Message flow for SIP payment 739 The main difference between the above-described mechanism and the one 740 described in Section 1 of [I-D.jennings-sipping-pay] is the degree of 741 user involvement and the type of protocol interaction. In both cases 742 it is possible to provide an indication to the user about the costs 743 of a service access. In fact, the assertion might specify these type 744 of constraints directly or indirectly with the help of recurring 745 service requests/responses. 747 7. SIP-SAML Extension 749 To carry SAML assertions and artifacts two mechanisms are defined: 751 o The SIP header may either carry an Artifcat or a CID URI [RFC2392] 752 pointing to an assertion in the SIP body. The name of this new 753 SIP header is SAML-Assertion. A SAML artifact consists of a 754 TypeCode, SourceID and an AssertionHandle. It is thereby assumed 755 that the Relying Party will maintain a table of sourceID values as 756 well as URLs for Asserting Parties to contact. This information 757 is communicated out-of-band. This document also allows the 758 Asserting Party to add a URL to point to the assertion to prevent 759 this level of indirection. 761 o The SIP body may carry one or more SAML assertions. The MIME type 762 of this SAML assertion is defined in [I-D.hodges-saml-mediatype]. 764 A SIP user agent may add an assertion to the body of a SIP message or 765 may add a reference to the assertion into the SIP header. SIP 766 proxies MUST NOT add the assertion to the body. The SIP header MUST 767 be used instead when an assertion has to be added. 769 A SAML assertion SHOULD be protected and when added by a SIP entity 770 then S/MIME MUST be used rather than XML digital signatures. 772 To bind a SAML assertion to a SIP message a few selected SIP message 773 fields are input to a hash function. The digest-string, defined in 774 Section 10 of [I-D.ietf-sip-identity], is included into the 775 conditions extension point of the SAML assertion. Details are for 776 further study. 778 8. Example 780 This is an example of a SAML assertion and how it is structured in 781 XML. 783 790 792 795 796 797 NameQualifier=alice@example.com 798 Format="urn:oasis:names:tc:SAML:1.1:nameid- 799 format:emailAddress">uid=alice 800 801 802 803 urn:oasis:names:tc:SAML:1.0: 804 cm:SIP-artifact-01 805 806 807 808 809 811 The elements in the assertion have the following meaning: 813 +---------------------+-----+-------------------------------+ 814 | Tag name |Req- | Description | 815 | |uired| | 816 +---------------------+-----+-------------------------------+ 817 |MajorVersion | X |Major version of the assertion | 818 +---------------------+-----+-------------------------------+ 819 |MinorVersion | X |Minor version of the assertion | 820 +---------------------+-----+-------------------------------+ 821 |AssertionID | X |ID of the assertion | 822 +---------------------+-----+-------------------------------+ 823 |Issuer | X |The name of the SAML authority | 824 | | |that created the assertion | 825 +---------------------+-----+-------------------------------+ 826 |IssuerInstant | X |Issuing time of the assertion | 827 +---------------------+-----+-------------------------------+ 828 | | |Conditions that MUST be taken | 829 |Conditions | |into account when assessing | 830 | | |the validity of the assertion | 831 +---------------------+-----+-------------------------------+ 832 | | |Specifies | 833 |AuthenticationMethod | X |what kind of authentication | 834 | | |took place | 835 +---------------------+-----+-------------------------------+ 836 |AuthenticationInstant| X |Specifies the time when the | 837 | | |authentication took place | 838 +---------------------+-----+-------------------------------+ 839 |Qualifier | |The name by which the subject | 840 | | |is recognized | 841 +---------------------+-----+-------------------------------+ 842 | | |A URI reference representing | 843 |Format | |the format of NameIdentifier | 844 | | | | 845 +---------------------+-----+-------------------------------+ 846 | | |Specifies a subject by supply- | 847 |SubjectConfirmation | |ing data that allows the sub- | 848 | | |ject to be authenticated | 849 +---------------------+-----+-------------------------------+ 850 | | |Identifies | 851 |ConfirmationMethod | |which method to be used for | 852 | | |authenticating the subject | 853 +---------------------+-----+-------------------------------+ 855 Figure 10: Tag descriptions 857 9. Requirement Comparison 859 A future version of this document will compare the requirements 860 listed in [I-D.ietf-sipping-trait-authz] with the solution provided 861 in this document. 863 10. Security Considerations 865 This section discusses security considerations when using SAML with 866 SIP. 868 10.1 Stolen Assertion 870 Threat: 872 If an eavesdropper can copy the real user's SAML response and 873 included assertions and construct a SIP message of his own, then 874 the eavesdropper could be able to impersonate the user at other 875 SIP entities. 877 Countermeasures: 879 By providing adequate confidentiality, eavesdropping of a SAML 880 assertion can be stopped. 882 10.2 MitM Attack 884 Threat: 886 Since the SAML assertion is carried within a SIP message, a 887 malicious site could impersonate the user at some other SIP 888 entities. These SIP entities would believe the adversary to be 889 the subject of the assertion. 891 Countermeasures: 893 If the adversary is a not-participating in the SIP signaling 894 itself (i.e., it is not a SIP proxy or a SIP UA), this threat can 895 be eliminated by employing inherent SIP security mechanisms, such 896 as TLS. However, if this entity is part of the communication 897 itself then reference integrity needs to be provided. Assertions 898 with tight restrictions (e.g., validity of the assertion) can also 899 limit the possible damage. 901 10.3 Forged Assertion 903 Threat: 905 A malicious user could forge or alter a SAML assertion in order to 906 communicate with the SIP entities. 908 Countermeasures: 910 To avoid this kind of attack, the entities must assure that proper 911 mechanisms for protecting the SAML assertion needs to be in place. 912 It is recommended to protect the assertion using a digital 913 signature. 915 10.4 Replay Attack 917 Threat: 919 In the case of using SIP with a 'by-reference' model, the threat 920 of replay lies in the fact that the artifact is a one-time-use 921 subject. The same artifact can be used again to gain access to 922 resources. 924 Countermeasures: 926 Cases where multiple requests are made which references the same 927 request must be tracked in order to avoid the threat. 929 11. Contributors 931 The authors would like to thank Henning Schulzrinne for his 932 contributions to this document. 934 12. Acknowledgments 936 We would like to thank RL 'Bob' Morgan and Stefan Goeman for their 937 comments to this draft. 939 13. IANA Considerations 941 This document contains a number of IANA considerations. A future 942 version of this document will list them in this section. 944 14. Open Issues 946 This document raises a number of issues with regard to the SIP 947 protocol interaction. Some of them are raised in this document (such 948 as reference integrity, who is allowed to add which information, 949 etc.) but a more detailed treatment of this topic with a focus of 950 identity management is described in [I-D.peterson-message-identity]. 951 In particular, the following sections are highly relevant for this 952 document: 954 Assertion Constraints and Scope: 956 This aspect deals with the problem of binding a SIP assertion to a 957 specific SIP message. The goal is to provide a security property 958 called reference integrity to prevent replay and impersonation 959 attacks. As described in Section 5 that a number of fields can be 960 used for this purpose. This document also considers scenarios 961 where the SAML assertion was obtained outside a SIP protocol run. 962 In these cases SIP fields are not available to provide reference 963 integrity. The concept of the holder-of-the-key assertion is 964 described below and relevant for this discussion. 966 Canonicalization versus Replication: 968 To provide reference integrity a few selected fields need to be 969 hashed, signed and placed into the assertion. Two approaches are 970 available for this purpose. Hence it needs to be studied how the 971 interworking between reference integrity and the usage of obtained 972 SAML assertion can be properly accomplished. For example, who 973 indicates which fields are included? 975 Alignment with SIP Identity: 977 It might be good to avoid the definition of a second set of 978 response codes for SAML conditions which will overlap with the 979 response codes defined for SIP Identity draft. 981 Placement of Assertions and Keys in Messages: 983 This document assumes that the assertions are added to the SIP 984 body and artifacts or references to assertions located in the SIP 985 body are added to the SIP header. A central question is therefore 986 where these assertions should be attached? Should the SIP user 987 agent or intermediate SIP proxies add assertions/artifacts? In 988 the scenarios depicted in Section 6, we have both approaches 989 depending on what kind of scenario it is. In Figure 4, they are 990 added at the UA and in contrast we have Figure 7, where the 991 assertions are added at the PSTN/SIP gateway. 993 MIME bodies can only be attached at the UA. Proxies by definition 994 do not attach MIME bodies; if an intermediary were to do so, it 995 would not be playing the proxy server role in the SIP 996 architecture. The SIP content indirection mechanism [I-D.ietf- 997 sip-content-indirect-mech] is also relevant in this discussion. 999 To provide reference integrity (by binding a SIP session and a SAML 1000 assertion together) two alternative approaches exist: 1002 Hashing of SIP message fields: 1004 If a hash is computed over a number of selected SIP fields and 1005 subsequently digitally signed then there is a some degree of 1006 protection that the assertion cannot be copied to other SIP 1007 messages and reused. The drawback thereby is that the assertion 1008 has a very limited time period. The hashed fields may vary from 1009 context to context. 1011 Holder-of-the-Key Assertion: 1013 SAML introduces the concept of a holder-of-the-key assertion to 1014 bind the assertions (authorization information) to a cryptographic 1015 key. As a result, the end host which was quite passive when 1016 dealing with assertions can be turned into an active protocol 1017 participant. The end host obtained the assertion and attached 1018 them to selected messages but did not provide any cryptographic 1019 computations with regard to the assertion itself. With the end 1020 host being active in the protocol exchange security is improved a 1021 lot. Furthermore, it is possible to combine the benefits of the 1022 work done with SIPPING-CERT [I-D.ietf-sipping-certs] and this 1023 document by binding a self-signed certificate created by the user 1024 and stored at the credential server to an assertion. As noted in 1025 Section 9 of [I-D.ietf-sipping-certs] in the context of signing 1026 SIP messages the usage of a self-signed certificate is not very 1027 helpful except used with an Authentication Service. Combined with 1028 a SAML assertion the signature would protect the SIP message and 1029 the SAML assertion would provide authorization information. 1031 A number of credentials can be used with the KeyInfo element of the 1032 Holder-of-the-Key assertion as described in Section 4.4 of [xmldsig- 1033 core]. 1035 Further open issues are: 1037 o Some work on option-tags is required. Are there cases when 1038 processing of the assertion would be required by the sender? Or 1039 when a proxy server wants to be able to say that a UA must supply 1040 this header in order to access a particular resource? If so, an 1041 option-tag should be defined for this extension that can be used 1042 in Require, Supported, 420, etc. 1044 o Specific SAML confirmation method identifiers and identifiers for 1045 the bindings or profiles must be defined and registered with 1046 OASIS. A confirmation method identifier is a URI that specifies 1047 which method should be used by the target domain to assure that 1048 the identity of the subject is true. 1050 This mechanism seems to be provide the same reference integrity 1051 properties as the hash over the various headers/bodies proposed in 1052 the identity draft. 1054 o Further use cases would be interesting. For example, a mechanism 1055 to provide additional security for the SIP REFER method [RFC3515]. 1057 o A few new URIs need to be registered. The proposed URIs for 1058 identification are: 1060 SIP Binding: urn:oasis:names:tc:SAML:1.0:bindings:SIP-binding 1062 Artifact 1063 profile: urn:oasis:names:tc:SAML:1.0:profiles:SIP-artifact-01 1065 Assertion 1066 profile: urn:oasis:names:tc:SAML:1.0:profiles:SIP-assertion-01 1068 o The proposed URIs for Confirmation Method Identifiers are: 1070 Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01 1072 Assertion profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer 1074 o These are based on the URIs already used in the existing SOAP-SAML 1075 binding, specified in Section 3 of [I-D.saml-bindings-1.1]. 1077 o An alignment with the work done by Liberty Alliance on Federated 1078 Identities as described in [I-D.liberty-idff-arch-overview] would 1079 be useful. 1081 o The security consideration needs more details. 1083 15. References 1085 15.1 Normative References 1087 [I-D.hodges-saml-mediatype] 1088 Hodges, J., "application/saml+xml Media Type 1089 Registration", draft-hodges-saml-mediatype-01 (work in 1090 progress), June 2004. 1092 [I-D.ietf-sipping-trait-authz] 1093 Peterson, J., "Trait-based Authorization Requirements for 1094 the Session Initiation Protocol (SIP)", 1095 draft-ietf-sipping-trait-authz-01 (work in progress), 1096 February 2005. 1098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1099 Requirement Levels", March 1997. 1101 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 1102 Locators", RFC 2392, August 1998. 1104 15.2 Informative References 1106 [I-D.ietf-sip-authid-body] 1107 Peterson, J., "SIP Authenticated Identity Body (AIB) 1108 Format", draft-ietf-sip-authid-body-03 (work in progress), 1109 May 2004. 1111 [I-D.ietf-sip-content-indirect-mech] 1112 Burger, E., "A Mechanism for Content Indirection in 1113 Session Initiation Protocol (SIP) Messages", 1114 draft-ietf-sip-content-indirect-mech-05 (work in 1115 progress), October 2004. 1117 [I-D.ietf-sip-identity] 1118 Peterson, J. and C. Jennings, "Enhancements for 1119 Authenticated Identity Management in the Session 1120 Initiation Protocol (SIP)", draft-ietf-sip-identity-05 1121 (work in progress), May 2005. 1123 [I-D.ietf-sipping-certs] 1124 Jennings, C. and J. Peterson, "Certificate Management 1125 Service for The Session Initiation Protocol (SIP)", 1126 draft-ietf-sipping-certs-01 (work in progress), 1127 February 2005. 1129 [I-D.jennings-sipping-pay] 1130 Jennings, C., "Payment for Services in Session Initiation 1131 Protocol (SIP)", draft-jennings-sipping-pay-01 (work in 1132 progress), February 2005. 1134 [I-D.liberty-idff-arch-overview] 1135 Wason, T., "Liberty ID-FF Architecture Overview", 2004. 1137 [I-D.peterson-message-identity] 1138 Peterson, J., "Security Considerations for Impersonation 1139 and Identity in Messaging Systems", 1140 draft-peterson-message-identity-00 (work in progress), 1141 October 2004. 1143 [I-D.saml-bindings-1.1] 1144 Maler, E., Philpott, R., and P. Mishra, "Bindings and 1145 Profiles for the OASIS Security Assertion Markup Language 1146 (SAML) V1.1", September 2003. 1148 [I-D.saml-core-1.1] 1149 Maler, E., Philpott, R., and P. Mishra, "Assertions and 1150 Protocol for the OASIS Security Assertion Markup Language 1151 (SAML) V1.1", September 2003. 1153 [I-D.saml-sec-consider-1.1] 1154 Maler, E. and R. Philpott, "Security and Privacy 1155 Considerations for the OASIS Security Markup Language 1156 (SAML) V1.1", September 2003. 1158 [I-D.saml-tech-overview-1.1-03] 1159 Maler, E. and J. Hughes, "Technical Overview of the OASIS 1160 Security Assertion Markup Language (SAML) V1.1", 1161 March 2004. 1163 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1164 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1165 March 1999. 1167 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1168 Method", RFC 3515, April 2003. 1170 [xmldsig-core] 1171 Eastlake, D., Reagle, J., and D. Solo, "XML-Signature 1172 Syntax and Processing, W3C Recommendation (available at 1173 http://www.w3.org/TR/xmldsig-core/)", February 2002. 1175 Authors' Addresses 1177 Hannes Tschofenig 1178 Siemens 1179 Otto-Hahn-Ring 6 1180 Munich, Bavaria 81739 1181 Germany 1183 Email: Hannes.Tschofenig@siemens.com 1185 Jon Peterson 1186 NeuStar, Inc. 1187 1800 Sutter St Suite 570 1188 Concord, CA 94520 1189 US 1191 Email: jon.peterson@neustar.biz 1193 James Polk 1194 Cisco 1195 2200 East President George Bush Turnpike 1196 Richardson, Texas 75082 1197 US 1199 Email: jmpolk@cisco.com 1201 Douglas C. Sicker 1202 University of Colorado at Boulder 1203 ECOT 430 1204 Boulder, CO 80309 1205 US 1207 Email: douglas.sicker@colorado.edu 1209 Marcus Tegnander 1210 Letterkenny Institute of Technology 1211 Port Road 1212 Letterkenny, Donegal 1213 Ireland 1215 Email: schwed@gmail.com 1217 Intellectual Property Statement 1219 The IETF takes no position regarding the validity or scope of any 1220 Intellectual Property Rights or other rights that might be claimed to 1221 pertain to the implementation or use of the technology described in 1222 this document or the extent to which any license under such rights 1223 might or might not be available; nor does it represent that it has 1224 made any independent effort to identify any such rights. Information 1225 on the procedures with respect to rights in RFC documents can be 1226 found in BCP 78 and BCP 79. 1228 Copies of IPR disclosures made to the IETF Secretariat and any 1229 assurances of licenses to be made available, or the result of an 1230 attempt made to obtain a general license or permission for the use of 1231 such proprietary rights by implementers or users of this 1232 specification can be obtained from the IETF on-line IPR repository at 1233 http://www.ietf.org/ipr. 1235 The IETF invites any interested party to bring to its attention any 1236 copyrights, patents or patent applications, or other proprietary 1237 rights that may cover technology that may be required to implement 1238 this standard. Please address the information to the IETF at 1239 ietf-ipr@ietf.org. 1241 Disclaimer of Validity 1243 This document and the information contained herein are provided on an 1244 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1245 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1246 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1247 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1248 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1251 Copyright Statement 1253 Copyright (C) The Internet Society (2005). This document is subject 1254 to the rights, licenses and restrictions contained in BCP 78, and 1255 except as set forth therein, the authors retain all their rights. 1257 Acknowledgment 1259 Funding for the RFC Editor function is currently provided by the 1260 Internet Society.