rfc2069.txt

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

Network Working Group                                          J. Franks
Request for Comments: 2069                       Northwestern University
Category: Standards Track                                P. Hallam-Baker
                                                                    CERN
                                                            J. Hostetler
                                                          Spyglass, Inc.
                                                                P. Leach
                                                   Microsoft Corporation
                                                             A. Luotonen
                                     Netscape Communications Corporation
                                                                 E. Sink
                                                          Spyglass, Inc.
                                                              L. Stewart
                                                       Open Market, Inc.
                                                            January 1997


          An Extension to HTTP : 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.

Abstract

   The protocol referred to as "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, as the user name and
   password are passed over the network as clear text.  A specification
   for a different authentication scheme is needed to address this
   severe limitation.  This document provides specification for such a
   scheme, referred to as "Digest Access Authentication".  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.








Franks, et. al.             Standards Track                     [Page 1]

RFC 2069              Digest Access Authentication          January 1997


Table of Contents

   INTRODUCTION......................................................  2
    1.1  PURPOSE ....................................................  2
    1.2  OVERALL OPERATION ..........................................  3
    1.3  REPRESENTATION OF DIGEST VALUES ............................  3
    1.4  LIMITATIONS ................................................  3
   2. DIGEST ACCESS AUTHENTICATION SCHEME............................  3
    2.1 SPECIFICATION OF DIGEST HEADERS .............................  3
     2.1.1 THE WWW-AUTHENTICATE RESPONSE HEADER .....................  4
     2.1.2 THE AUTHORIZATION REQUEST HEADER .........................  6
     2.1.3 THE AUTHENTICATION-INFO HEADER ...........................  9
    2.2 DIGEST OPERATION ............................................ 10
    2.3 SECURITY PROTOCOL NEGOTIATION ............................... 10
    2.4 EXAMPLE ..................................................... 11
    2.5 PROXY-AUTHENTICATION AND PROXY-AUTHORIZATION ................ 11
   3. SECURITY CONSIDERATIONS........................................ 12
    3.1 COMPARISON WITH BASIC AUTHENTICATION ........................ 13
    3.2 REPLAY ATTACKS .............................................. 13
    3.3 MAN IN THE MIDDLE ........................................... 14
    3.4 SPOOFING BY COUNTERFEIT SERVERS ............................. 15
    3.5 STORING PASSWORDS ........................................... 15
    3.6 SUMMARY ..................................................... 16
   4.  ACKNOWLEDGMENTS............................................... 16
   5. REFERENCES..................................................... 16
   6. AUTHORS' ADDRESSES............................................. 17

Introduction

1.1  Purpose

   The protocol referred to as "HTTP/1.0" includes specification for a
   Basic Access Authentication scheme[1].  This scheme is not considered
   to be a secure method of user authentication, as the user name and
   password are passed over the network in an unencrypted form.  A
   specification for a new authentication scheme is needed for future
   versions of the HTTP protocol.  This document provides specification
   for such a scheme, 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. This
   scheme provides no encryption of object content. The intent is simply
   to create a weak access authentication method which avoids the most
   serious flaws of Basic authentication.

   It is proposed that this access authentication scheme be included in
   the proposed HTTP/1.1 specification.




Franks, et. al.             Standards Track                     [Page 2]

RFC 2069              Digest Access Authentication          January 1997


1.2  Overall Operation

   Like Basic Access Authentication, the Digest scheme is based on a
   simple challenge-response paradigm.  The Digest scheme challenges
   using a nonce value.  A valid response contains a checksum (by
   default the MD5 checksum) of the username, the password, the given
   nonce value, the HTTP method, and the requested URI.  In this way,
   the password is never sent in the clear.  Just as with the Basic
   scheme, the username and password must be prearranged in some fashion
   which is not addressed by this document.

1.3  Representation of digest values

   An optional header allows the server to specify the algorithm used to
   create the checksum or digest.  By default the MD5 algorithm is used
   and that is the only algorithm described in this document.

   For the purposes of this document, an MD5 digest of 128 bits is
   represented as 32 ASCII printable characters.  The bits in the 128
   bit digest are converted from most significant to least significant
   bit, four bits at a time to their ASCII presentation as follows.
   Each four bits is represented by its familiar hexadecimal notation
   from the characters 0123456789abcdef.  That is, binary 0000 gets
   represented by the character '0', 0001, by '1', and so on up to the
   representation of 1111 as 'f'.

1.4  Limitations

   The 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) suffers from all the same problems of any
   password system.  In particular, no provision is made in this
   protocol for the initial secure arrangement between user and server
   to establish the user's password.

   Users and implementors should be aware that this protocol is not as
   secure as kerberos, and not as secure as any client-side private-key
   scheme.  Nevertheless it is better than nothing, better than what is
   commonly used with telnet and ftp, and better than Basic
   authentication.

2. Digest Access Authentication Scheme

2.1 Specification of Digest Headers

   The Digest Access Authentication scheme is conceptually similar to
   the Basic scheme.  The formats of the modified WWW-Authenticate



Franks, et. al.             Standards Track                     [Page 3]

RFC 2069              Digest Access Authentication          January 1997


   header line and the Authorization header line are specified below,
   using the extended BNF defined in the HTTP/1.1 specification, section
   2.1.  In addition, a new header, Authentication-info, is specified.

2.1.1 The WWW-Authenticate Response Header

   If a server receives a request for an access-protected object, and an
   acceptable Authorization header is not sent, the server responds with
   a "401 Unauthorized" status code, and a WWW-Authenticate header,
   which is defined as follows:

     WWW-Authenticate    = "WWW-Authenticate" ":" "Digest"
                              digest-challenge

     digest-challenge    = 1#( realm | [ domain ] | nonce |
                          [ digest-opaque ] |[ stale ] | [ algorithm ] )

     realm               = "realm" "=" realm-value
     realm-value         = quoted-string
     domain              = "domain" "=" <"> 1#URI <">
     nonce               = "nonce" "=" nonce-value
     nonce-value         = quoted-string
     opaque              = "opaque" "=" quoted-string
     stale               = "stale" "=" ( "true" | "false" )
     algorithm           = "algorithm" "=" ( "MD5" | token )

   The meanings of the values of the parameters used above are as
   follows:

     realm
     A string to be displayed to users so they know which username and
     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 "[e-mail]".  The realm is a
     "quoted-string" as specified in section 2.2 of the HTTP/1.1
     specification [2].

     domain
     A comma-separated list of URIs, as specified for HTTP/1.0.  The
     intent is that the client could use this information to know the
     set of URIs for which the same authentication information should be
     sent.  The URIs in this list may exist on different servers.  If
     this keyword is omitted or empty, the client should assume that the
     domain consists of all URIs on the responding server.






Franks, et. al.             Standards Track                     [Page 4]

RFC 2069              Digest Access Authentication          January 1997


     nonce
     A server-specified data string which may be uniquely generated each
     time a 401 response is made.  It is recommended that this string be
     base64 or hexadecimal data.  Specifically, since the string is
     passed in the header lines as a quoted string, the double-quote
     character is not allowed.

     The contents of the nonce are implementation dependent.  The
     quality of the implementation depends on a good choice.  A
     recommended nonce would include

             H(client-IP ":" time-stamp ":" private-key )

     Where client-IP is the dotted quad IP address of the client making
     the request, time-stamp is a server-generated time value,  private-
     key is data known only to the server.  With a nonce of this form a
     server would normally recalculate the nonce after receiving the
     client authentication header and reject the request if it did not
     match the nonce from that header. In this way the server can limit
     the reuse of a nonce to the IP address to which it was issued and
     limit the time of the nonce's validity.  Further discussion of the
     rationale for nonce construction is in section 3.2 below.

     An implementation might choose not to accept a previously used
     nonce or a previously used digest to protect against a replay
     attack.  Or, an implementation might choose to use one-time nonces
     or digests for POST or PUT requests and a time-stamp for GET
     requests.  For more details on the issues involved see section 3.
     of this document.

     The nonce is opaque to the client.

     opaque
     A string of data, specified by the server, which should be
     returned by the client unchanged.  It is recommended that this
     string be base64 or hexadecimal data.  This field is a
     "quoted-string" as specified in section 2.2 of the HTTP/1.1
     specification [2].

     stale
     A flag, indicating that the previous request from the client was
     rejected because the nonce value was stale.  If stale is TRUE (in
     upper or lower case), the client may wish to simply retry the
     request with a new encrypted response, without reprompting the
     user for a new username and password.  The server should only set
     stale to true if it receives a request for which the nonce is
     invalid but with a valid digest for that nonce (indicating that
     the client knows the correct username/password).



Franks, et. al.             Standards Track                     [Page 5]

RFC 2069              Digest Access Authentication          January 1997


     algorithm
     A string indicating a pair of algorithms used to produce the
     digest and a checksum.  If this not present it is assumed to be
     "MD5". In this document the string obtained by applying the
     digest algorithm to the data "data" with secret "secret" will be
     denoted by KD(secret, data), and the string obtained by applying
     the checksum algorithm to the data "data" will be denoted
     H(data).

     For the "MD5" algorithm

        H(data) = MD5(data)

     and

        KD(secret, data) = H(concat(secret, ":", data))

     i.e., the digest is the MD5 of the secret concatenated with a colon
     concatenated with the data.

2.1.2 The Authorization Request Header

   The client is expected to retry the request, passing an Authorization
   header line, which is defined as follows.

Authorization       = "Authorization" ":" "Digest" digest-response

digest-response     = 1#( username | realm | nonce | digest-uri |
                         response | [ digest ] | [ algorithm ] |
                         opaque )

username            = "username" "=" username-value
username-value      = quoted-string
digest-uri          = "uri" "=" digest-uri-value
digest-uri-value    = request-uri         ; As specified by HTTP/1.1
response            = "response" "=" response-digest
digest             = "digest" "=" entity-digest

response-digest     = <"> *LHEX <">
entity-digest      = <"> *LHEX <">
LHEX                = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                      "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f"

   The definitions of response-digest and entity-digest above indicate
   the encoding for their values. The following definitions show how the
   value is computed:





Franks, et. al.             Standards Track                     [Page 6]