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 8223 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.