rfc2617.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,416 行 · 第 1/5 页

Network Working Group                                          J. Franks
Request for Comments: 2617                       Northwestern University
Obsoletes: 2069                                          P. Hallam-Baker
Category: Standards Track                                 Verisign, Inc.
                                                            J. Hostetler
                                                         AbiSource, Inc.
                                                             S. Lawrence
                                                   Agranat Systems, Inc.
                                                                P. Leach
                                                   Microsoft Corporation
                                                             A. Luotonen
                                     Netscape Communications Corporation
                                                              L. Stewart
                                                       Open Market, Inc.
                                                               June 1999


      HTTP Authentication: Basic and Digest Access Authentication

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   "HTTP/1.0", includes the specification for a Basic Access
   Authentication scheme. This scheme is not considered to be a secure
   method of user authentication (unless used in conjunction with some
   external secure system such as SSL [5]), as the user name and
   password are passed over the network as cleartext.

   This document also provides the specification for HTTP's
   authentication framework, the original Basic authentication scheme
   and a scheme based on cryptographic hashes, referred to as "Digest
   Access Authentication".  It is therefore also intended to serve as a
   replacement for RFC 2069 [6].  Some optional elements specified by
   RFC 2069 have been removed from this specification due to problems
   found since its publication; other new elements have been added for
   compatibility, those new elements have been made optional, but are
   strongly recommended.



Franks, et al.              Standards Track                     [Page 1]

RFC 2617                  HTTP Authentication                  June 1999


   Like Basic, Digest access authentication verifies that both parties
   to a communication know a shared secret (a password); unlike Basic,
   this verification can be done without sending the password in the
   clear, which is Basic's biggest weakness. As with most other
   authentication protocols, the greatest sources of risks are usually
   found not in the core protocol itself but in policies and procedures
   surrounding its use.

Table of Contents

   1   Access Authentication................................   3
    1.1   Reliance on the HTTP/1.1 Specification............   3
    1.2   Access Authentication Framework...................   3
   2   Basic Authentication Scheme..........................   5
   3   Digest Access Authentication Scheme..................   6
    3.1   Introduction......................................   6
     3.1.1  Purpose.........................................   6
     3.1.2  Overall Operation...............................   6
     3.1.3  Representation of digest values.................   7
     3.1.4  Limitations.....................................   7
    3.2   Specification of Digest Headers...................   7
     3.2.1  The WWW-Authenticate Response Header............   8
     3.2.2  The Authorization Request Header................  11
     3.2.3  The Authentication-Info Header..................  15
    3.3   Digest Operation..................................  17
    3.4   Security Protocol Negotiation.....................  18
    3.5   Example...........................................  18
    3.6   Proxy-Authentication and Proxy-Authorization......  19
   4   Security Considerations..............................  19
    4.1   Authentication of Clients using Basic
          Authentication....................................  19
    4.2   Authentication of Clients using Digest
          Authentication....................................  20
    4.3   Limited Use Nonce Values..........................  21
    4.4   Comparison of Digest with Basic Authentication....  22
    4.5   Replay Attacks....................................  22
    4.6   Weakness Created by Multiple Authentication
          Schemes...........................................  23
    4.7   Online dictionary attacks.........................  23
    4.8   Man in the Middle.................................  24
    4.9   Chosen plaintext attacks..........................  24
    4.10  Precomputed dictionary attacks....................  25
    4.11  Batch brute force attacks.........................  25
    4.12  Spoofing by Counterfeit Servers...................  25
    4.13  Storing passwords.................................  26
    4.14  Summary...........................................  26
   5   Sample implementation................................  27
   6   Acknowledgments......................................  31



Franks, et al.              Standards Track                     [Page 2]

RFC 2617                  HTTP Authentication                  June 1999


   7   References...........................................  31
   8   Authors' Addresses...................................  32
   9   Full Copyright Statement.............................  34

1 Access Authentication

1.1 Reliance on the HTTP/1.1 Specification

   This specification is a companion to the HTTP/1.1 specification [2].
   It uses the augmented BNF section 2.1 of that document, and relies on
   both the non-terminals defined in that document and other aspects of
   the HTTP/1.1 specification.

1.2 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 to provide authentication information. It uses an extensible,
   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 via that
   scheme.

      auth-scheme    = token
      auth-param     = token "=" ( token | quoted-string )

   The 401 (Unauthorized) response message is used by an origin server
   to challenge the 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
   Authentication Required) response message is used by a proxy to
   challenge the authorization of a client and MUST include a Proxy-
   Authenticate header field containing at least one challenge
   applicable to the proxy for the requested resource.

      challenge   = auth-scheme 1*SP 1#auth-param

   Note: User agents will need to take special care in parsing the WWW-
   Authenticate or Proxy-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 parameters.

   The authentication parameter realm is defined for all authentication
   schemes:

      realm       = "realm" "=" realm-value
      realm-value = quoted-string



Franks, et al.              Standards Track                     [Page 3]

RFC 2617                  HTTP Authentication                  June 1999


   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 URL (the
   absoluteURI for the server whose abs_path is empty; see section 5.1.2
   of [2]) of the server being accessed, defines the protection space.
   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
   (Unauthorized)--MAY do so by including an Authorization header field
   with the request. A client that wishes to authenticate itself with a
   proxy--usually, but not necessarily, after receiving a 407 (Proxy
   Authentication Required)--MAY do so by including a Proxy-
   Authorization header field with the request.  Both the Authorization
   field value and the Proxy-Authorization field value consist of
   credentials containing the authentication information of the client
   for the realm of the resource being requested. The user agent MUST
   choose to use one of the challenges with the strongest auth-scheme it
   understands and request credentials from the user based upon that
   challenge.

   credentials = auth-scheme #auth-param

      Note that many browsers will only recognize Basic and will require
      that it be the first auth-scheme presented. Servers should only
      include Basic if it is minimally acceptable.

   The protection space determines the domain over which credentials can
   be automatically applied. If a prior request has been authorized, the
   same 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
   space cannot extend outside the scope of its server.

   If the origin server does not wish to accept the 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
   resource. If a proxy does not accept the credentials sent with a
   request, it SHOULD return a 407 (Proxy Authentication Required). The
   response MUST include a Proxy-Authenticate header field containing a



Franks, et al.              Standards Track                     [Page 4]

RFC 2617                  HTTP Authentication                  June 1999


   (possibly new) challenge applicable to the proxy for the requested
   resource.

   The 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 level or
   via message 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 headers untouched, and follow the
   rules found in section 14.8 of [2]. Both the Proxy-Authenticate and
   the Proxy-Authorization header fields are hop-by-hop headers (see
   section 13.5.1 of [2]).

2 Basic Authentication Scheme

   The "basic" 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 string
   which can only be compared for equality with other realms on that
   server. The server will service the request only if it can validate
   the user-ID and password for the protection space of the Request-URI.
   There are no optional authentication parameters.

   For Basic, the framework above is utilized as follows:

      challenge   = "Basic" realm
      credentials = "Basic" basic-credentials

   Upon receipt of an unauthorized request for a URI within the
   protection space, the origin server MAY respond with a challenge like
   the following:

      WWW-Authenticate: Basic realm="WallyWorld"

   where "WallyWorld" is the string assigned by the server to identify
   the protection space of the Request-URI. A proxy may respond with the
   same challenge using the Proxy-Authenticate header field.

   To receive authorization, the client sends the userid and password,
   separated by a single colon (":") character, within a base64 [7]
   encoded string in the credentials.

      basic-credentials = base64-user-pass
      base64-user-pass  = <base64 [4] encoding of user-pass,



Franks, et al.              Standards Track                     [Page 5]

RFC 2617                  HTTP Authentication                  June 1999