authentication
Click on the red underlined text to get to the source
... Access Authentication ...
... Access Authentication Framework ...
... HTTP provides a simple challenge-response authentication mechanism
that MAY be used by a server to challenge a client request and by a
...
... client request and by a
client to provide authentication information. It uses an extensible,
case-insensitive token ...
... case-insensitive token to identify the authentication scheme,
followed by a comma-separated list of attribute-value pairs which
carry the parameters necessary for achieving authentication ...
... authentication scheme,
followed by a comma-separated list of attribute-value pairs which
carry the parameters necessary for achieving authentication via that
scheme.
...
... authorization of a user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource. The 407 (Proxy ...
... challenge applicable to the requested resource. The 407 (Proxy
Authentication Required) response message is used by a proxy to
...
... client and MUST include a Proxy-
Authenticate header field containing at least one challenge
applicable to the proxy ...
... Note: User agents will need to take special care in parsing the WWW-
Authenticate or Proxy-Authenticate header field ...
... Authenticate or Proxy-Authenticate header field value if it contains
more than one challenge, or if more than one WWW-Authenticate ...
... Authenticate header field value if it contains
more than one challenge, or if more than one WWW-Authenticate header
field is provided, since the contents of a challenge may itself
contain a comma-separated list of authentication ...
... WWW-Authenticate header
field is provided, since the contents of a challenge may itself
contain a comma-separated list of authentication parameters.
...
...
The authentication parameter realm is defined for all authentication
schemes:
...
...
The authentication parameter realm is defined for all authentication
schemes:
...
... The realm directive (case-insensitive) is required for all
authentication schemes that issue a challenge. The realm value
(case-sensitive), in combination with the canonical root ...
... These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value
...
... is a string, generally assigned by the origin server, which may have
additional semantics specific to the authentication scheme. Note that
there may be multiple challenges with the same auth-scheme but
different realms.
...
...
A user agent that wishes to authenticate itself with an origin
server--usually, but not necessarily, after receiving a 401
...
... header field
with the request. A client that wishes to authenticate itself with a
proxy--usually, but not necessarily, after receiving ...
... receiving a 407 (Proxy
Authentication Required)--MAY do so by including a Proxy-
Authorization ...
... Authorization field value consist of
credentials containing the authentication information of the client
for the realm of the resource being requested. The user agent ...
... credentials MAY be reused for all other requests within that
protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection
...
... authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection
space cannot extend outside the scope of its server.
...
... credentials sent
with a request, it SHOULD return a 401 (Unauthorized) response. The
response MUST include a WWW-Authenticate header field containing at
least one (possibly new) challenge applicable to the requested
...
... credentials sent with a
request, it SHOULD return a 407 (Proxy Authentication Required). The
response MUST include a Proxy-Authenticate ...
... Authentication Required). The
response MUST include a Proxy-Authenticate header field containing a
(possibly new) challenge applicable to the proxy ...
... HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional
mechanisms MAY be used, such as encryption at the transport ...
... encapsulation, and with additional header fields
specifying authentication information. However, these additional
mechanisms are not defined by this specification.
...
... Proxies MUST be completely transparent regarding user agent
authentication by origin servers. That is, they must forward the
WWW-Authenticate and Authorization ...
... authentication by origin servers. That is, they must forward the
WWW-Authenticate and Authorization headers untouched, and follow the
...
... Basic Authentication Scheme ...
... authentication scheme is based on the model that the
client must authenticate itself with a user-ID and a password for
each realm. The realm value should be considered an opaque ...
... password for the protection space of the Request-URI.
There are no optional authentication parameters.
...
...
WWW-Authenticate: Basic realm="WallyWorld"
...
... proxy server. See section 4 for
security considerations associated with Basic authentication.
...
... Digest Access Authentication Scheme ...
... The protocol referred to as "HTTP/1.0" includes the specification for
a Basic Access Authentication scheme[1]. That scheme is not
considered to be a secure method ...
... 1]. That scheme is not
considered to be a secure method of user authentication, as the user
name and password are passed over the network ...
... This section provides the specification for a scheme that does not
send the password in cleartext, referred to as "Digest Access
Authentication".
...
...
The Digest Access Authentication scheme is not intended to be a
complete answer to the need for security in the World Wide Web ...
... encryption of message content. The intent is
simply to create an access authentication method that avoids the most
serious flaws of Basic authentication ...
...
Like Basic Access Authentication, the Digest scheme is based on a
simple challenge-response paradigm. The Digest scheme challenges
...
...
The Digest authentication scheme described in this document suffers
from many known limitations. It is intended as a replacement for
Basic authentication ...
... Digest authentication scheme described in this document suffers
from many known limitations. It is intended as a replacement for
Basic authentication and nothing more. It is a password-based system
and (on the server side ...
... scheme. Nevertheless it is better than nothing, better than what is
commonly used with telnet and ftp, and better than Basic
authentication.
...
...
The Digest Access Authentication scheme is conceptually similar to
the Basic scheme. The formats of the modified WWW-Authenticate header ...
... The Digest Access Authentication scheme is conceptually similar to
the Basic scheme. The formats of the modified WWW-Authenticate header
line and the Authorization ...
... header line are specified below. In
addition, a new header, Authentication-Info, is specified.
...
... The WWW-Authenticate Response Header ...
... header is not sent, the server responds with
a "401 Unauthorized" status code, and a WWW-Authenticate header as
per the framework ...
... password to use. This string should contain at least the name of
the host performing the authentication and might additionally
indicate the collection of users who might have access. An example
might be "registered_users@gotham.news.com".
...
... this list to determine the set of URIs for which the same
authentication information may be sent: any URI that has a URI in
...
...
This directive is not meaningful in Proxy-Authenticate headers, for
which the protection space is always the entire proxy ...
... hash portion after receiving the client authentication header and
reject the request if it did not match the nonce ...
... MD5-sess" algorithm is intended to
allow efficient 3rd party authentication servers; for the
difference in usage, see the description in section 3.2.2.2.
...
... quality of protection" values supported by the server. The
value "auth" indicates authentication; the value "auth-int"
indicates authentication with integrity protection ...
... value "auth" indicates authentication; the value "auth-int"
indicates authentication with integrity protection; see the
...
... opaque and algorithm fields must be those supplied
in the WWW-Authenticate response header for the entity being
requested.
...
... client has applied to
the message. If present, its value MUST be one of the alternatives
the server indicated it supports in the WWW-Authenticate header.
These values affect the computation of the request-digest. Note
...
... that this is a single token, not a quoted list of alternatives as
in WWW- Authenticate. This directive is optional in order to
preserve backward compatibility with a minimal implementation of
...
... 2069(-> 2617draft) [6], but SHOULD be used if the server indicated that qop
is supported by providing a qop directive in the WWW-Authenticate
header field.
...
... This MUST be specified if a qop directive is sent (see above), and
MUST NOT be specified if the server did not send a qop directive in
the WWW-Authenticate header field. The cnonce-value is an opaque
...
... client
and server to avoid chosen plaintext attacks, to provide mutual
authentication, and to provide some message integrity protection.
See the descriptions below of the calculation of the response-
...
... This MUST be specified if a qop directive is sent (see above), and
MUST NOT be specified if the server did not send a qop directive in
the WWW-Authenticate header field. The nc-value is the hexadecimal
count of the number of requests (including the current request)
...
... calculated only once - on the first request by the client following
receipt of a WWW-Authenticate challenge from the server. It uses the
server nonce from that challenge, and the first client ...
... This creates a 'session key' for the authentication of subsequent
requests and responses which is different for each "authentication
...
... session key' for the authentication of subsequent
requests and responses which is different for each "authentication
session", thus limiting the amount of material hashed with any one
...
... session", thus limiting the amount of material hashed with any one
key. (Note: see further discussion of the authentication session in
section 3.3.) Because the server need only use the hash ...
... be used in conjunction with a third party authentication service so
that the web server would not need the actual password ...
... but MUST first revalidate it with the origin server, using the
request headers from the new request to allow the origin server to
authenticate the new request. Alternatively, if the original response
included the "public" Cache-Control directive, the response entity ...
... The Authentication-Info Header ...
... header is used by the server to communicate
some information regarding the successful authentication in the
response.
...
... "Authentication-Info" ":" auth-info ...
... nonce the server wishes
the client to use for a future authentication response. The server
may send the Authentication-Info header ...
... client to use for a future authentication response. The server
may send the Authentication-Info header with a nextnonce field as a
means of implementing one-time or otherwise changing nonces ...
... header for its next request. Failure of the client
to do so may result in a request to re-authenticate from the server
with the "stale=TRUE".
...
... quality of protection" options applied to the
response by the server. The value "auth" indicates authentication;
the value "auth-int" indicates authentication with integrity
protection ...
... by the server. The value "auth" indicates authentication;
the value "auth-int" indicates authentication with integrity
protection. The server SHOULD use the same value for the message-
qop directive in the response as was sent by the client ...
...
The optional response digest in the "response-auth" directive
supports mutual authentication -- the server proves that it knows the
user's secret, and with qop=auth-int also provides limited integrity
protection of the response. The "response-digest" value is calculated
...
...
The Authentication-Info header is allowed in the trailer of an HTTP
message transferred via chunked transfer-coding.
...
...
The client response to a WWW-Authenticate challenge for a protection
space starts an authentication ...
... WWW-Authenticate challenge for a protection
space starts an authentication session with that protection space.
The authentication ...
... authentication session with that protection space.
The authentication session lasts until the client receives another
...
... session lasts until the client receives another
WWW-Authenticate challenge from any server in the protection space. A
client should remember the username ...
... nonce count and
opaque values associated with an authentication session to use to
construct the Authorization ...
... preemptively; doing so improves server efficiency and avoids extra
round trips for authentication challenges. The server may choose to
accept the old Authorization header information ...
... As with the basic scheme, proxies must be completely transparent in
the Digest access authentication scheme. That is, they must forward
the WWW-Authenticate, Authentication ...
... the Digest access authentication scheme. That is, they must forward
the WWW-Authenticate, Authentication-Info and Authorization headers ...
... access authentication scheme. That is, they must forward
the WWW-Authenticate, Authentication-Info and Authorization headers
...
... headers
untouched. If a proxy wants to authenticate a client before a request
is forwarded to the server, it can be done using the Proxy ...
... is forwarded to the server, it can be done using the Proxy-
Authenticate and Proxy-Authorization headers ...
...
It is possible that a server may want to require Digest as its
authentication method, even if the server does not know that the
client supports it. A client ...
... client supports it. A client is encouraged to fail gracefully if the
server specifies only authentication schemes it cannot handle.
...
...
The digest authentication scheme may also be used for authenticating
users to proxies, proxies ...
... transactions for proxy
authentication are very similar to those already described. Upon
receiving a request which requires authentication ...
... authentication are very similar to those already described. Upon
receiving a request which requires authentication, the proxy/server
must issue the "407 Proxy ...
... proxy/server
must issue the "407 Proxy Authentication Required" response with a
"Proxy-Authenticate ...
... Authentication Required" response with a
"Proxy-Authenticate" header. The digest-challenge used in the
Proxy ...
... header. The digest-challenge used in the
Proxy-Authenticate header is the same as that for the WWW-
Authenticate ...
... Authenticate header is the same as that for the WWW-
Authenticate header as defined above in section 3.2.1.
...
...
On subsequent responses, the server sends Proxy-Authentication-Info
with directives the same as those for the Authentication-Info header
field ...
... Proxy-Authentication-Info
with directives the same as those for the Authentication-Info header
field.
...
...
Note that in principle a client could be asked to authenticate itself
to both a proxy and an end-server, but never in the same response.
...
...
The Basic authentication scheme is not a secure method of user
authentication, nor does it in any way protect the entity ...
... The Basic authentication scheme is not a secure method of user
authentication, nor does it in any way protect the entity, which is
transmitted in cleartext across the physical ...
... network used as the
carrier. HTTP does not prevent additional authentication schemes and
encryption mechanisms from being employed to increase security ...
... addition of enhancements (such as schemes to use one-time passwords)
to Basic authentication.
...
...
The most serious flaw in Basic authentication is that it results in
the essentially cleartext transmission of the user's password over
...
...
Because Basic authentication involves the cleartext transmission of
passwords it SHOULD NOT be used (without enhancements) to protect
...
...
A common use of Basic authentication is for identification purposes
-- requiring the user to provide a user name and password ...
...
Basic Authentication is also vulnerable to spoofing by counterfeit
servers. If a user can be led to believe that he is connecting to a
...
... servers. If a user can be led to believe that he is connecting to a
host containing information protected by Basic authentication when,
in fact, he is connecting to a hostile server or gateway, then the
...
... password, store it for later use, and feign an
error. This type of attack is not possible with Digest
Authentication. Server implementers SHOULD guard against the
possibility of this sort of counterfeiting by gateways ...
...
Digest Authentication does not provide a strong authentication
mechanism, when compared to public key based mechanisms, for example.
...
...
Digest Authentication does not provide a strong authentication
mechanism, when compared to public key based mechanisms, for example.
...
...
Digest Authentication offers no confidentiality protection beyond
protecting the actual password ...
...
Digest Authentication offers only limited integrity protection for
the messages in either direction. If qop=auth-int mechanism is used,
...
... the messages in either direction. If qop=auth-int mechanism is used,
those parts of the message used in the calculation of the WWW-
Authenticate and Authorization header field response directive values
...
... Many needs for secure HTTP transactions cannot be met by Digest
Authentication. For those needs TLS or SHTTP are more appropriate
protocols. In particular Digest authentication ...
... Digest
Authentication. For those needs TLS or SHTTP are more appropriate
protocols. In particular Digest authentication cannot be used for any
transaction requiring confidentiality ...
... transaction requiring confidentiality protection. Nevertheless many
functions remain for which Digest authentication is both useful and
appropriate. Any service in present use that uses Basic should be
...
... nonce has been returned and
sending a next-nonce directive in the Authentication-Info header
field of every response. This protects against even an immediate
replay attack ...
... replay attack, but has a high cost checking nonce values, and perhaps
more important will cause authentication failures for any pipelined
requests (presumably returning a stale nonce indication). Similarly,
...
... Comparison of Digest with Basic Authentication ...
...
Both Digest and Basic Authentication are very much on the weak end of
the security strength spectrum. But a comparison ...
... database whose use is
restricted to paying subscribers. With Basic authentication an
eavesdropper can obtain the password of the user. This not only
...
...
By contrast, with Digest Authentication the eavesdropper only gets
access to the transaction in question and not to the user's password ...
...
A replay attack against Digest authentication would usually be
pointless for a simple GET request since an eavesdropper would
already have seen the only document he could obtain with a replay.
...
... client request and the server will only deliver that document. By
contrast under Basic Authentication once the eavesdropper has the
user's password, any document protected by that password ...
... Weakness Created by Multiple Authentication Schemes ...
... An HTTP/1.1 server may return multiple challenges with a 401
(Authenticate) response, and each challenge may use a different
auth-scheme. A user agent MUST choose to use the strongest auth-
...
... When the server offers choices of authentication schemes using the
WWW-Authenticate header, the strength of the resulting authentication
...
... WWW-Authenticate header, the strength of the resulting authentication
is only as good as that of the of the weakest of the authentication
...
... header, the strength of the resulting authentication
is only as good as that of the of the weakest of the authentication
schemes. See section 4.8 below for discussion of particular attack ...
... A possible man-in-the-middle attack would be to add a weak
authentication scheme to the set of choices, hoping that the client
will use one that exposes the user's credentials ...
... MITM attack would be to remove all offered choices,
replacing them with a challenge that requests only Basic
authentication, then uses the cleartext credentials from the Basic
authentication to authenticate ...
... replacing them with a challenge that requests only Basic
authentication, then uses the cleartext credentials from the Basic
authentication to authenticate to the origin server using the
stronger scheme it requested. A particularly insidious way to mount
...
... Basic
authentication, then uses the cleartext credentials from the Basic
authentication to authenticate to the origin server using the
stronger scheme it requested. A particularly insidious way to mount
such a MITM attack ...
... indication at the time of the credentials request of what
authentication scheme is to be used, or remembering the strongest
authentication scheme ever requested by a server and produce a
...
... authentication scheme is to be used, or remembering the strongest
authentication scheme ever requested by a server and produce a
warning message before using a weaker one. It might also be a good
idea for the user agent ...
... warning message before using a weaker one. It might also be a good
idea for the user agent to be configured to demand Digest
authentication in general, or from specific sites.
...
... client wanted. Of course, this is
still much harder than a comparable attack against Basic
Authentication.
...
...
Basic Authentication is vulnerable to spoofing by counterfeit
servers. If a user can be led to believe that she is connecting to a
...
... password, store it away for later use, and feign
an error. This type of attack is more difficult with Digest
Authentication -- but the client must know to demand that Digest
authentication be used, perhaps using some of the techniques
...
... attack is more difficult with Digest
Authentication -- but the client must know to demand that Digest
authentication be used, perhaps using some of the techniques
described above to counter "man-in-the-middle ...
... user can be helped in detecting this attack by a visual indication of
the authentication mechanism in use with appropriate guidance in
interpreting the implications of each scheme.
...
...
Digest authentication requires that the authenticating agent (usually
the server) store some data derived from the user's name and password ...
... realm is part of the digested data stored in the password file. It
means that if one Digest authentication password file is compromised,
it does not automatically compromise others with the same username ...
... particular a realm string should include the name of the host doing
the authentication. The inability of the client to authenticate the
server is a weakness of Digest Authentication ...
... host doing
the authentication. The inability of the client to authenticate the
server is a weakness of Digest Authentication.
...
... authentication. The inability of the client to authenticate the
server is a weakness of Digest Authentication.
...
...
By modern cryptographic standards Digest Authentication is weak. But
for a large range of purposes it is valuable as a replacement for
...
... for a large range of purposes it is valuable as a replacement for
Basic Authentication. It remedies some, but not all, weaknesses of
Basic Authentication. Its strength may vary depending on the
...
... Basic Authentication. It remedies some, but not all, weaknesses of
Basic Authentication. Its strength may vary depending on the
implementation. In particular the structure of the nonce (which is
...
... relatively weak by cryptographic standards, but *any* compliant
implementation will be far superior to Basic Authentication.
...
... Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069(-> 2617draft), January 1997. ...
... Kaliski, B.,Robshaw, M., "Message Authentication with MD5", CryptoBytes, Sping 1995, RSA Inc, (http://www.rsa.com/rsalabs/pubs/cryptobytes/spring95/md5.htm ...
... Morgan, B., Alvestrand, H., Hodges, J., Wahl, M., "Authentication Methods for LDAP", Work in Progress. ...