idnits 2.17.1 draft-cunnings-salz-soap-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (October 2001) is 8191 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') ** Obsolete normative reference: RFC 2279 (ref. '5') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2617 (ref. '6') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Cunnings 3 Internet-Draft Lectrosonics 4 Expires: April 1, 2002 R. Salz 5 Zolera 6 October 2001 8 SOAP Extensions: Basic and Digest Authentication 9 draft-cunnings-salz-soap-auth-01 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 1, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 This memo defines SOAP Extensions which implement a basic access 41 authentication mechanism and a digest access authentication 42 mechanism for use in request/response message exchange patterns. 43 These mechanisms are adaptations of the corresponding mechanisms 44 defined in RFC 2617. 46 1. Introduction 48 This specification defines SOAP Extensions [2] which implement a 49 "Basic" access authentication mechanism and a "Digest" access 50 authentication mechanism for use in request/response message 51 exchange patterns. These are adaptations of the corresponding 52 mechanisms presented in RFC 2617[6]. A SOAP node utilizing one of 53 these extensions will process requests for protected resources only 54 if the client can be "authenticated"; that is, only if the client 55 has presented valid "credentials" in the request message. These 56 credentials are presented in response to a "challenge" sent by the 57 server after a request for access to a protected resource. 59 The term "client" is defined as the node originating a SOAP request 60 message, and the term "server" is defined as the node responsible 61 for implementing an Authentication Extension. This server node is 62 the target of any header entries in request messages, and source of 63 any header entries in the response message that are defined by this 64 specification. The authentication server may be either a SOAP 65 processing intermediary node, or the ultimate destination node 66 (endpoint) of the request/response message exchange. 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 70 this document are to be interpreted as described in RFC 2119[4]. 72 2. Basic Access Authentication 74 The Basic mechanism allows a client to authenticate itself by 75 presenting credentials consisting of a username/password pair, 76 directly transmitted in the request message. This is a 77 challenge/response protocol in which the client presents its 78 credentials in response to a challenge from the server, which 79 consists of the name of a security realm within which the requested 80 resource is protected. The realm name serves as a hint to the client 81 for the choice of username and password. 83 2.1 Challenge/Response Protocol 85 When a client wishes to access a protected resource, it presents 86 credentials contained in an instance of the "BasicAuth" header 87 entry, which is included in the SOAP request message sent to the 88 server. If the responsible SOAP actor fails to find this header 89 entry in a request message envelope, or the credentials are invalid, 90 the client is not "authenticated" and a "challenge" is issued to the 91 client in the response. The challenge is contained in a 92 "BasicChallenge" header entry included in a SOAP Fault message. To 93 proceed, the client must resend the request, including a "response" 94 to the challenge in an instance of the header entry "BasicAuth". If 95 the server finds this response to be correct, the client is 96 authenticated, and the request can be processed. Clients may 97 preemptively include the "BasicAuth" header entry in a request 98 message in order to avoid a challenge from the server. 100 2.2 Header Entry Element Definitions 102 The header entry elements described below are defined in the XML 103 Schema document found in Appendix A. These elements are defined in 104 XML namespace "http://soap-authentication.org/2002/01/". This 105 namespace MUST be used by implementations. The nature of this SOAP 106 extension requires that the "SOAP-ENV:mustUnderstand" attribute 107 SHOULD be present with a value of "1". 109 2.2.1 BasicChallenge Element 111 This element is contained in the header of the fault message 112 returned by the server when a request is received with missing or 113 invalid credentials. It is a structure with the following member: 115 Realm serves as a hint to the client for the choice of user name and 116 password, e.g. the name of a group of users authorized to access 117 a resource. The realm name identifies the protection space 118 associated with the requested resource. 120 In this example the server is responding to a request which did not 121 contain a "BasicAuth" header entry, or contained invalid 122 credentials, with a SOAP fault message. The "BasicChallenge" header 123 entry element represents the challenge to the client. 125 131 132 135 test@whitemesa.net 136 137 138 139 140 SOAP-ENV:Client 141 142 Authentication failed: missing, malformed, 143 or invalid credentials. 144 145 146 147 149 2.2.2 BasicAuth Element 151 This element is contained in the header of the request message sent 152 by a client. It is a structure and contains the following members: 154 Name This member is of type "string" and contains the name 155 identifying the entity for which the authentication is being 156 attempted. 158 Password This member is of type "string" and contains the password. 160 In this example the client is resending a request message and 161 including the "BasicAuth" header entry element. This contains its 162 response (the "BasicAuth" element) to a previous challenge from the 163 server. 165 171 172 175 admin 176 broccoli 177 178 179 180 181 This is a test. 182 183 184 186 2.3 Processing Rules 188 A server receiving a request MUST respond with a SOAP Fault message 189 if the request header entry element "BasicAuth" is not present, is 190 malformed, or contains invalid credentials. The Fault message header 191 MUST contain the header entry element "BasicChallenge" with member 192 "Realm" containing the name of a security realm with which the 193 resource is associated. 195 A client responding to a challenge from a server MUST include the 196 "BasicAuth" header entry element in the header of the message sent 197 in the next attempt to access the resource. The "Name" and 198 "Password" elements MUST be present. 200 A client MAY preemptively include a "BasicAuth" header entry element 201 containing its credentials in a request message in order to avoid a 202 challenge from the server. The "Name" and "Password" elements MUST 203 be present. 205 After receiving a request in which the "BasicAuth" header entry 206 element is present and contains valid credentials, the server MUST 207 allow normal request processing to take place. 209 3. Digest Access Authentication 211 The Digest mechanism allows a client to authenticate itself by 212 presenting credentials consisting of a message digest (such as 213 MD5[3] or a SHA[1] variant) transmitted in a request message. It is 214 based on the principle that the client and server are in possession 215 of a shared secret, a password string. The advantage of this method 216 is that the client password is only used in calculating the digest, 217 so it remains safe from network exposure. 219 The Digest mechanism is a challenge/response protocol in which the 220 client presents its credentials in response to a challenge from the 221 server, which consists of an opaque data string called a "nonce". 222 This nonce serves as additional input to the digest function, and 223 allows the server to influence the digest value in a way not 224 controlled by the client; this increases the security of the 225 mechanism. In order to authenticate the client, the server simply 226 compares the digest value received from the client with the value it 227 has computed internally. If the values match, the client must be in 228 possession of the same nonce and password as the server, so the 229 client is "authenticated". The same technique is used in the mutual 230 authentication scenario, where the server authenticates itself to 231 the client by presenting a digest as credentials in response to a 232 challenge from the client. In this case also the challenge consists 233 of a client-produced nonce to be used as input to the digest 234 function, allowing the client to influence the digest value in a way 235 not controlled by the server. The full specification for digest 236 computation is found in in Section 3.3. 238 3.1 Challenge/response protocol 240 When a client wishes to access a protected resource, it presents 241 credentials contained in an instance of the "ClientAuth" header 242 entry element, which is included in the SOAP request message sent to 243 the server. If the responsible SOAP actor fails to find this header 244 entry in a request message envelope, or finds an instance containing 245 invalid or expired credentials, the client is not "authenticated", 246 and a "challenge" is issued to the client in the response. The 247 challenge is contained in a "Challenge" header entry included in a 248 SOAP Fault message. To proceed, the client must resend the request, 249 including a "response" to the challenge in an instance of the header 250 entry "ClientAuth". The response consists of a message digest 251 computed as specified in Section 3.3. 253 If the server finds this response to be correct, the client is 254 authenticated, and the request can be processed. When processing is 255 complete, the response message returned to the client by the server 256 will include a header entry, "NextChallenge", containing the next 257 challenge to the client. If the client wishes to send another 258 request, it will re-authenticate itself by supplying a response to 259 this new challenge, as part of the "ClientAuth" header entry it 260 includes in the request message. Thus each request/response SOAP 261 message exchange involves a separate authentication of the client to 262 the server. 264 A mechanism is provided for mutual authentication. If the client 265 wishes to authenticate the server, it includes a challenge of its 266 own to the server as part of the "ClientAuth" header entry it sends 267 in a request message. The server supplies a response to this 268 challenge in the "NextChallenge" header entry it includes in 269 response message returned to the client. The response consists of a 270 message digest computed as specified in Section 3.3. If the client 271 finds this response to be correct, the server is authenticated. 273 A method is provided for a client to explicitly solicit a challenge 274 from a server, optionally including a challenge of its own to the 275 server. Including a challenge is useful when the client wishes to 276 immediately determine the authenticity of the server, before sending 277 any further resource request messages for processing. The client 278 initiates the exchange by including the "InitChallenge" header entry 279 in a request message. The server responds with a challenge, 280 contained in an instance of the "NextChallenge" header entry 281 contained in a SOAP Fault message. If the client has included a 282 challenge to the server in the "InitChallenge" header entry, the 283 server supplies a response in the "NextChallenge" header entry 284 returned to the client. This response can then be used by the client 285 determine the authenticity of the server. If the client wishes to 286 proceed with a request at this point, it will authenticate itself by 287 supplying a response to the challenge from the server, as part of 288 the "ClientAuth" header entry it includes in the request message. 290 3.2 Header Entry Element Definitions 292 The header entry elements described below are defined in the XML 293 Schema document found in Appendix A. These elements are defined in 294 XML namespace "http://soap-authentication.org/2002/01/" This 295 namespace MUST be used by implementations. The nature of this SOAP 296 extension requires that the "SOAP-ENV:mustUnderstand" attribute 297 SHOULD be present with a value of "1". 299 3.2.1 Challenge Element 301 This element is contained in the header of the fault message 302 returned by the server when a request is received with missing or 303 invalid credentials. It is a structure and contains the following 304 members: 306 Status This member is of type "string" and contains a code 307 indicating the reason for the challenge. Status code values are 308 defined in Section 4. 310 Nonce This member is of type "string" and contains the nonce which 311 represents the challenge issued by the server to the client. 313 Realm This member is of type "string" and contains a name which 314 serves as a hint to the client for the choice of user id and 315 password, e.g. the name of a group of users authorized to access 316 a resource. The realm name identifies the protection space 317 associated with the requested resource. 319 In addition, the "Challenge" element may have a "digest" attribute 320 whose value is a URI identifying the digest mechanism to be used. If 321 not present, the identifier for MD5 is assumed. 323 In this example the server is responding to a request which did not 324 contain a "ClientAuth" header entry with a SOAP fault message. The 325 "Challenge" header entry contains the challenge ("Nonce" member) 326 issued to the client. 328 334 335 338 Unauthenticated.NoCredentials 339 950C60A74BAA9BB7EDAC95F02EEC497C 340 test@whitemesa.net 341 342 343 344 345 SOAP-ENV:Client 346 347 Authentication failed: missing, malformed, 348 or invalid credentials. 349 350 351 352 354 3.2.2 ClientAuth Element 356 This element is contained in the header of a request message sent by 357 a client. It is a structure and contains the following members: 359 Nonce This member is of type "string" and echoes the nonce value 360 received from the server representing the challenge to the client. 362 Auth This member is of type "hexBinary" and contains the response by 363 the client to the challenge received from the server. This is a 364 hex encoded message digest computed as specified in Section 3.3. 366 UserID This member is of type "string" and contains the User ID 367 identifying the account for which the authentication is being 368 attempted. 370 Realm This member is of type "string" and identifies the security 371 realm for which the authentication is being attempted. 373 ClientNonce (Optional) This member is of type "string" and contains 374 the nonce which represents a challenge issued by the client to 375 the server when mutual authentication is desired. 377 In addition, the "ClientAuth" element may have a "digest" attribute 378 whose value is a URI identifying the digest mechanism to be used. If 379 not present, the identifier for MD5 is assumed. 381 In this example the client is responding to a challenge by resending 382 the request message and including the "ClientAuth" header entry 383 element. This contains its response ("Auth" member) to the challenge 384 from the server. Also present is the client nonce ("ClientNonce" 385 member) representing a challenge issued by the client to the server. 387 393 394 397 950C60A74BAA9BB7EDAC95F02EEC497C 398 C48F2DEEC547D9BF590B4C72283445A5 399 admin 400 test@whitemesa.net 401 CEA8A3DB3C06C7970A61B92AE9560A08 402 403 404 405 406 This is a test. 407 408 409 411 3.2.3 NextChallenge Element 413 This element is contained in the header of a response message sent 414 by the server. It is a structure and contains the following members: 416 Status This member is of type "string" and contains a code 417 indicating the outcome of the authentication attempt made by the 418 client in the request. Status code values are defined in Section 419 4. 421 Nonce This member is of type "string" and contains the nonce which 422 represents a new challenge issued by the server to the client. It 423 will form the basis of the response by the client in the next 424 request, if any. 426 ClientNonce (Optional) This member is of type "string" and echoes 427 the nonce value received from the client, representing a 428 challenge issued by the client to the server. If no challenge 429 was received from the client, this member is omitted. 431 ServerAuth (Optional) This member is of type "hexBinary" and 432 contains the response by the server to a challenge received from 433 the client. This is a hex encoded message digest computed as 434 given in Section 3.3. If no challenge was received from the 435 client, this member is omitted. 437 In addition, the "NextChallenge" element may have a "digest" 438 attribute whose value is a URI identifying the digest mechanism to 439 be used. If not present, the identifier for MD5 is assumed. 441 In this example the server has received a request message containing 442 a correct response to the last challenge issued to the client. It 443 responds with this message containing the "NextChallenge" header 444 entry which includes its response ("ServerAuth" member) to the 445 challenge issued by the client in the request message. Also included 446 is the next challenge issued to the client ("Nonce" member). 448 454 455 458 Authenticated 459 574F38FFDE076F9006AC0014146DFD14 460 CEA8A3DB3C06C7970A61B92AE9560A08 461 CA834D49323368101AC51CA15E745DBF 462 463 464 465 466 This is a test. 467 468 469 471 3.2.4 InitChallenge Element 473 This element is contained in the header of a request message sent by 474 a client. It is a structure and contains the following members: 476 UserID This member is of type "string" and contains the User ID 477 identifying the account for which the authentication is being 478 attempted. 480 Realm This member is of type "string" and identifies the security 481 realm for which the authentication is being attempted. 483 ClientNonce (Optional) This member is of type "string" and contains 484 the nonce which represents a challenge issued by the client to 485 the server when immediate authentication of the server is desired. 487 In addition, the "InitChallenge" element may have a "digest" 488 attribute whose value is a URI identifying the digest mechanism to 489 be used. If not present, the identifier for MD5 is assumed. 491 In this example the client is soliciting a challenge from the server 492 by sending a request message including the "InitChallenge" header 493 entry element. This contains the client nonce ("ClientNonce" member) 494 representing a challenge issued by the client to the server. 496 502 503 506 admin 507 test@whitemesa.net 508 CEA8A3DB3C06C7970A61B92AE9560A08 509 510 511 512 513 514 515 516 518 The server responds with a fault message which includes the 519 "NextChallenge" header entry element. This includes its response 520 ("ServerAuth" member) to the challenge issued by the client in the 521 request message. Also included is the challenge issued by the server 522 to the client ("Nonce" member). 524 530 531 534 Unauthenticated.NoCredentials 535 574F38FFDE076F9006AC0014146DFD14 536 CEA8A3DB3C06C7970A61B92AE9560A08 537 CA834D49323368101AC51CA15E745DBF 538 539 540 541 542 SOAP-ENV:Client 543 544 Authentication failed: missing, malformed, 545 or invalid credentials. 546 547 548 549 551 3.3 Digest Computation 553 The response to a challenge is computed as follows: 555 o "HASHMECH( concat(secret, ":", sn, ":", cn) )" When mutual 556 authentication is required. 558 o "HASHMECH( concat(secret, ":", sn) )" When only client 559 authentication is required. 561 Where: 563 secret (string) represents the hex encoding of the digest "HASHMECH( 564 concat(uid, ":", realm, ":", pwd) )" where: 566 uid (string) represents the User ID. 568 realm (string) represents the Realm name. 570 pwd (string) represents the password. 572 sn (string) represents the nonce serving as the challenge from the 573 server to the client. 575 cn (string) represents the client nonce serving as the challenge 576 from the client to the server. 578 concat(stringA, stringB, ...) represents the string concatenation 579 operation. 581 HASHMECH(string) represents the digesting operation. 583 All strings, including literals, are presented as the UTF-8[5] 584 encodings of Unicode strings. 586 4. Status Codes 588 The Status Code values defined by this specification are: 590 Authenticated 592 Unauthenticated 594 Unauthenticated.NoCredentials 596 Unauthenticated.InvalidResponse 598 Unauthenticated.ExpiredNonce 600 Unauthenticated.InvalidUser 602 Unauthenticated.InvalidRealm 604 Interop.UnsupportedDigest 606 These codes consist of dot (".") separated values, and are 607 interpreted by considering the value to the left of a dot to be more 608 general in meaning than the value to the right. For instance, the 609 value "Unauthenticated.NoCredentials" represents the extension of 610 the value "Unauthenticated" by the value "NoCredentials". In this 611 manner applications may extend the existing set of codes in a 612 backwards compatible way by appending additional values (e.g. 613 "Unauthenticated.ExpiredNonce.ServerReboot", which could be 614 substituted for "Unauthenticated.ExpiredNonce" where appropriate). 616 5. Digest Mechanisms 618 Digest mechanisms are identified by URI. The URI 619 "http://www.w3.org/2000/09/xmldsig#md5" is used to indicate MD5[3]. 620 The URI "http://soap-authentication.org/2002/01/#sha-1" is used to 621 indicate the SHA-1[1] (160-bit) digest; other standards may, e.g., 622 define SHA-384. 624 For compatibility with this document's base specifications, the 625 default digest mechanism is MD5[3]. 627 6. Processing Rules 629 A client MAY include the "InitChallenge" header entry element in a 630 request message, in order to explicitly solicit a challenge from a 631 server. The "digest" attribute, if present, specifies the digest 632 mechanism to be used by the server in generating its response; if 633 omitted, MD5 MUST be used. The "ClientNonce" member MAY contain a 634 nonce serving as a challenge to the server. security realm with 635 which the resource is associated, and the "UserID" member MUST 636 contain a valid value for the specified realm. 638 A server receiving an explicit request for a challenge (indicated by 639 the presence of the "InitChallenge" header entry element in the 640 request message), MUST respond with a SOAP Fault message containing 641 a challenge. If the "Realm" and "UserID" members of the 642 "InitChallenge" header entry element are valid for the requested 643 resource, and the server implements the desired digest mechanism, 644 the Fault message MUST include the "NextChallenge" header entry 645 element with a newly generated nonce in the "Nonce" member, and a 646 "Status" member value of "Unauthenticated.NoCredentials". The 647 "digest" attribute, if present, mechanism to be used by the client 648 to generate a response; if omitted, MD5 MUST be used. If the request 649 message included a challenge from the client, the "ServerAuth" 650 member MUST be present and contain the response to the challenge. 651 The server MUST respond using the same digest mechanism used by the 652 "InitChallenge" header entry, and the "ClientNonce" member MUST be 653 present echoing the value of the "ClientNonce" member of the 654 received "InitChallenge" header entry element. 656 If the "Realm" or "UserID" members of the "InitChallenge" header 657 entry element are not valid for the requested resource, or the 658 "digest" attribute specifies a digest mechanism not supported by the 659 server, the Fault message MUST include the "Challenge" header entry 660 element with a newly generated nonce in the "Nonce" member. The 661 "digest" attribute, if present, specifeis the digest mechanism to 662 use for the reply; if omitted, MD5 MUST be used. The "Realm" member 663 MUST contain the name of a security realm with which the resource is 664 associated. The value of the "Status" member is determined by the 665 nature of the fault: 667 Unauthenticated.InvalidUser if the "InitChallenge" header entry 668 contains an invalid "UserID" member value. 670 Unauthenticated.InvalidRealm if the "InitChallenge" header entry 671 contains an invalid "Realm" member value. 673 Interop.UnsupportedDigest if the "InitChallenge" header entry 674 "digest" attribute specifies an unsupported digest mechanism, or 675 if the attribute is omitted and MD5 is not supported. 677 A server receiving a request without an explicit solicitation of a 678 challenge (indicated by the absence of the "InitChallenge" header 679 entry element in the request message), but containing invalid 680 credentials (the "ClientAuth" header entry element is not present, 681 is malformed, uses an unsupported digest mechanism, or 682 authentication fails), MUST respond with a SOAP Fault message 683 containing a challenge. The Fault message header MUST contain the 684 header entry "Challenge" with a newly generated nonce in the "Nonce" 685 member. The "digest" attribute, if present, specifies the digest 686 mechanism for the client to use in its response; if omitted, MD5 687 MUST be used. The "Realm" member MUST contain the name of a security 688 realm with which the resource is associated. The value of the 689 "Status" member is determined by the nature of the fault: 691 Unauthenticated.NoCredentials if the request made by the client 692 contained no "ClientAuth" header entry. 694 Unauthenticated.InvalidResponse if the "ClientAuth" header entry 695 contains an incorrect response to a challenge. 697 Unauthenticated.ExpiredNonce if the "ClientAuth" header entry 698 contains a reponse to an expired challenge. 700 Unauthenticated.InvalidUser if the "ClientAuth" header entry 701 contains an invalid "UserID" member value. 703 Unauthenticated.InvalidRealm if the "ClientAuth" header entry 704 contains an invalid "Realm" member value. 706 Interop.UnsupportedDigest if the "ClientAuth" header entry "digest" 707 attribute specifies an unsupported digest mechanism, or the 708 attribute is omitted and MD5 is not supported. 710 A client responding to a challenge from a server in the form of the 711 "Challenge" header entry element MUST include the "ClientAuth" 712 header entry element in the header of the message sent in the next 713 attempt to access the resource. The client MUST respond using the 714 same digest mechanism used in the "Challenge" header entry, and 715 properly identify it. If the client does not support the digest 716 mechanism given in the "Challenge" header entry, it MAY re-send the 717 original request specifying an alternate digest mechanism. The 718 "Auth" member MUST contain a response to the challenge, and the 719 "ClientNonce" member MAY contain a nonce serving as a challenge to 720 the server. This challenge MUST assume the use of the digest 721 mechanism specified in the enclosing "ClientAuth" header entry 722 element. The "Realm" and "Nonce" members MUST echo the values 723 received in the members of the same name in the "Challenge" header 724 entry element in the prior response message from the server. The 725 "UserID" member MUST contain a valid value for the specified realm. 727 A client responding to a challenge from a server in the form of the 728 "NextChallenge" header entry element MUST include the "ClientAuth" 729 header entry element in the header of the message sent in the next 730 attempt to access the resource. The client MUST respond using the 731 same digest mechanism given in the "NextChallenge" header entry, and 732 properly identify it. The "Auth" member MUST contain a response to 733 the challenge, and the "ClientNonce" member MAY contain a nonce 734 serving as a challenge to the server. This challenge MUST assume 735 the use of the digest mechanism specified in the enclosing 736 "ClientAuth" header entry element. The "Nonce" member MUST echo the 737 value received in the member of the same name in the "NextChallenge" 738 header entry element received in the prior response message from the 739 server. The "Realm" member MUST contain the name of a security realm 740 with which the resource is associated, and the "UserID" member MUST 741 contain a valid value for the specified realm. 743 A server receiving a request in which the "ClientAuth" header entry 744 element is present, specifies a supported digest mechanism, and 745 contains valid credentials, MUST allow normal request processing to 746 take place. Once this processing is complete, the server MUST 747 include the header entry element "NextChallenge" in the response 748 message header, with a "Status" member value of "Authenticated". The 749 "Nonce" member MUST contain a newly generated nonce value 750 representing the next challenge to the client. The "digest" 751 attribute, if present, specifies the digest mechanism to be used by 752 the client to generate a response; if omitted, MD5 MUST be used. If 753 the request message included a challenge from the client, the 754 "ServerAuth" member MUST be present and contain the response to the 755 challenge. The server MUST respond using the digest mechanism given 756 in the "ClientAuth" header entry, and the "ClientNonce" member MUST 757 be present echoing the value of the "ClientNonce" member of the 758 "ClientAuth" header entry element received. 760 7. Security Considerations 762 This specification provides Authentication facilities only. Message 763 integrity or confidentiality requirements are not satisfied by these 764 SOAP Extensions. The Basic Authentication mechanism is vulnerable to 765 network snooping, as the password is present in the header entry. It 766 is RECOMMENDED in this case that communication be done over a 767 transport protocol that provides privacy, such as SSL/TLS. This 768 weakness is avoided in the Digest Authentication mechanism. 770 The use of a client supplied nonce (optional) and one-time server 771 nonces (required) increases the resistance of this mechanism to 772 certain kinds of attacks. Well chosen nonce values are important to 773 the quality of the protection afforded. An useful analysis of 774 security considerations for Basic and Digest access authentication 775 mechanisms is found in [6]. 777 References 779 [1] US DoC/NISC, "US Federal Information Processing Standard 180-1, 780 Secure Hash Standard (SHS)", April 1995, 781 . 783 [2] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, 784 N., Nielsen, H. F., Thatte, S. and D. Winer, "Simple Object 785 Access Protocol (SOAP) 1.1", May 2000, 786 . 788 [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 789 1992. 791 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 792 Levels", RFC 2119, March 1997. 794 [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 795 2279, January 1998. 797 [6] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 798 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 799 Basic and Digest Access Authentication", RFC 2617, June 1999. 801 Authors' Addresses 803 Robert Cunnings 804 Lectrosonics, Inc. 805 581 Laser Road 806 Rio Rancho, NM 87124 807 US 809 Phone: +1-505-892-4501 810 EMail: cunnings@lectrosonics.com 811 URI: http://www.lectrosonics.com 813 Rich Salz 814 Zolera Systems, Inc. 815 600 West Cummings Park 816 Suite 2000 817 Woburn, MA 01801 818 US 820 Phone: +1-781-759-1122 821 EMail: rsalz@zolera.com 822 URI: http://www.zolera.com/ 824 Appendix A. Full Schema 826 828 834 837 838 839 840 841 842 843 844 846 847 848 849 850 851 852 853 854 856 857 858 859 860 861 862 863 864 865 866 868 869 870 871 872 873 874 875 876 877 878 879 880 882 883 884 885 886 887 888 889 890 891 892 893 895 896 897 898 899 900 901 902 903 904 905 907 909 Appendix B. Changes since the last version 911 Added support for multiple digest mechanisms, the "digest" 912 attribute, and the SHA-1 URI. 914 Consolidated everything into the new 915 "http://soap-authentication.org/2002/01/" namespace. 917 Full Copyright Statement 919 Copyright (C) The Internet Society (2001). All Rights Reserved. 921 This document and translations of it may be copied and furnished to 922 others, and derivative works that comment on or otherwise explain it 923 or assist in its implementation may be prepared, copied, published 924 and distributed, in whole or in part, without restriction of any 925 kind, provided that the above copyright notice and this paragraph 926 are included on all such copies and derivative works. However, this 927 document itself may not be modified in any way, such as by removing 928 the copyright notice or references to the Internet Society or other 929 Internet organizations, except as needed for the purpose of 930 developing Internet standards in which case the procedures for 931 copyrights defined in the Internet Standards process must be 932 followed, or as required to translate it into languages other than 933 English. 935 The limited permissions granted above are perpetual and will not be 936 revoked by the Internet Society or its successors or assigns. 938 This document and the information contained herein is provided on an 939 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 940 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 941 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 942 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 943 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 945 Acknowledgement 947 Funding for the RFC editor function is currently provided by the 948 Internet Society.