HTTP digest Authentication

Source: Internet
Author: User
Tags http digest authentication rfc dns names

The definition of "response-value" abve indicates the encoding for its value -- 32 lower case hex characters. The following definitions show how the value is computed.

Although qop-value and components of digest-Uri-value may be case-insensitive, the case which the client supplies in Step two is preserved for the purpose of computing and verifying the response-value.

      response-value  =         HEX( KD ( HEX(H(A1)),                 { nonce-value, ":" nc-value, ":",                   cnonce-value, ":", qop-value, ":", HEX(H(A2)) }))

If authzid is specified, then A1 is

      A1 = { H( { username-value, ":", realm-value, ":", passwd } ),           ":", nonce-value, ":", cnonce-value, ":", authzid-value }

If authzid is not specified, then A1 is

      A1 = { H( { username-value, ":", realm-value, ":", passwd } ),           ":", nonce-value, ":", cnonce-value }

Where

         passwd   = *OCTET

The "username-value", "realm-value" and "passwd" are encoded according to the value of the "charset" directive. if "charset = UTF-8" is present, and all the characters of either "username-value" or "passwd" are in the ISO 8859-1 character set, then it must be converted to ISO 8859-1 before being hashed. this is so that authentication databases that store the hashed username, realm and password (which is common) can be shared compatibly with HTTP, which specifies ISO 8859-1.

If the "qop" Directive's value is "auth", then A2 is:

      A2       = { "AUTHENTICATE:", digest-uri-value }

If the "qop" value is "Auth-int" or "auth-conf" then A2 is:

      A2       = { "AUTHENTICATE:", digest-uri-value,               ":00000000000000000000000000000000" }

Note that "Authenticate:" must be in upper case, and the second string constant is a string with a colon followed by 32 zeros.

These apparently strange values of A2 are for compatibility with HTTP; they were arrived at by setting "method" to "authenticate" and the hash of the entity body to zero in the HTTP Digest Calculation of A2.

Also, in the HTTP usage of digest, several ctictives in the "digest-Challenge" sent by the server have to be returned by the client in the "digest-response". These are:

  • Opaque
  • Algorithm

    These directives are not needed when digest is used as a SASL Mechanic (I. e., must not be sent, and must be ignored if already ed ).

     Structure:

    digest-response  = 1#( username | realm | nonce | cnonce |                          nonce-count | qop | digest-uri | response |                          maxbuf | charset | cipher | authzid |                          auth-param )       username         = "username" "=" <"> username-value <">       username-value   = qdstr-val       cnonce           = "cnonce" "=" <"> cnonce-value <">       cnonce-value     = qdstr-val       nonce-count      = "nc" "=" nc-value       nc-value         = 8LHEX       qop              = "qop" "=" qop-value       digest-uri       = "digest-uri" "=" <"> digest-uri-value <">       digest-uri-value  = serv-type "/" host [ "/" serv-name ]       serv-type        = 1*ALPHA       host             = 1*( ALPHA | DIGIT | "-" | "." )       serv-name        = host       response         = "response" "=" response-value       response-value   = 32LHEX       LHEX             = "0" | "1" | "2" | "3" |                          "4" | "5" | "6" | "7" |                          "8" | "9" | "a" | "b" |                          "c" | "d" | "e" | "f"       cipher           = "cipher" "=" cipher-value       authzid          = "authzid" "=" <"> authzid-value <">       authzid-value    = qdstr-val

    Username
    The user's name in the specified realm, encoded according to the value of the "charset" Directive. This directive is required and must be present exactly once; otherwise, authentication fails.

    Realm
    The realm containing the user's account. this directive is required if the server provided any realms in the "digest-Challenge", in which case it may appear exactly once and Its Value shocould be one of those realms. if the directive is missing, "realm-value" will set to the empty string when computing A1 (see below for details ).

    Nonce
    The server-specified data string received in the preceding digest-challenge. This directive is required and must be present exactly once; otherwise, authentication fails.

    Cnonce
    A client-specified data string which must be different each time a digest-response is sent as part of initial authentication. the cnonce-value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, and to provide mutual authentication. the security of the implementation depends on a good choice. it is recommended that it contain at least 64 bits of entropy. this directive is required and must be present exactly once; otherwise, authentication fails.

    Nonce-count
    The NC-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. for example, in the first request sent in response to a given nonce value, the client sends "nc = 00000001 ". the purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count-if the same nc-value is seen twice, then the request is a replay. see the description below of the construction of the response value. this directive may appear at most once; if multiple instances are present, the client shocould abort the authentication exchange.

    Qop
    Indicates what "quality of protection" the client accepted. if present, it may appear exactly once and its value must be one of the alternatives in qop-Options. if not present, it defaults to "auth ". these values affect the computation of the response. note that this is a single token, not a quoted list of alternatives.

    Serv-type
    Indicates the type of service, such as "www" for Web service, "ftp" for FTP service, "SMTP" for mail delivery service, etc. the service name as defined in the SASL profile for the Protocol see section 4 of [RFC 2222], registered in the IANA registry of "service" elements for the gssapi host-based service name form [RFC 2078].

    Host
    The DNS host name or IP address for the Service requested. the DNS host name must be the fully-qualified canonical name of the host. the DNS host name is the preferred form; see Notes on server processing of the digest-Uri.

    Serv-name
    Indicates the name of the service if it is replicated. the service is considered to be replicated if the client's service-location process involves resolution using standard DNS lookup operations, and if these operations involve DNS records (such as SRV, or MX) which resolve one DNS name into a set of other DNS names. in this case, the initial name used by the client is the "Serv-name", and the final name is the "host" component. for example, the incoming mail service for "example.com" may be replicated through the use of MX records stored in the DNS, one of which points at an SMTP server called "mail3.example.com "; it's "Serv-name" wocould be "example.com", it's "host" wocould be "mail3.example.com ". if the service is not replicated, or the Serv-name is identical to the host, then the Serv-name component must be omitted.

    Digest-Uri
    Indicates the principal name of the service with which the client wishes to connect, formed from the Serv-type, host, and Serv-name. for example, the FTP service on "ftp.example.com" wocould have a "digest-Uri" value of "FTP/ftp.example.com "; the SMTP server from the example abve wowould have a "digest-Uri" value of "SMTP/mail3.example.com/example.com ".

    Servers shoshould check that the supplied value is correct. this will detect accidental connection to the incorrect server. it is also so that clients will be trained to provide values that will work with implementations that use a shared back-end authentication service that can provide server authentication.

    The Serv-type component shoshould match the service being offered. the host component shoshould match one of the host names of the host on which the service is running, or it's IP address. servers shoshould not normally support the IP address form, because server authentication by IP address is not very useful; they shoshould only do so if the DNS is unavailable or unreliable. the Serv-name component shoshould match one of the Service's configured service names.

    This directive may appear at most once; if multiple instances are present, the client shocould abort the authentication exchange.

    Note: in the HTTP use of digest authentication, the digest-Uri is the URI (usually a URL) of the resource requested -- hence the name of the directive.

    Response
    A string of 32 hex digits computed as defined below, which proves that the user knows a password. This directive is required and must be present exactly once; otherwise, authentication fails.

    Maxbuf
    A number indicating the size of the largest buffer the client is able to receive. if this directive is missing, the default value is 65536. this directive may appear at most once; if multiple instances are present, the server shocould abort the authentication exchange.

    Charset
    This directive, if present, specifies that the client has used UTF-8 encoding for the username and password. if not present, the username and password must be encoded in ISO 8859-1 (of which US-ASCII is a subset ). the client shocould send this directive only if the server has indicated it supports UTF-8. the directive is needed for backwards compatibility with HTTP digest, which only supports ISO 8859-1.

    Lhex
    32 hex digits, where the alphabetic characters must be lower case, because MD5 is not case insensitive.

    Cipher
    The cipher chosen by the client. This directive must appear exactly once if "auth-conf" is negotiated; if required and not present, authentication fails.

    Authzid
    The "Authorization ID" as per RFC 2222, encoded in UTF-8. this directive is optional. if present, and the Authenticating user has sufficient privilege, and the server supports it, then after authentication the server will use this identity for making all accesses and access checks. if the client specifies it, and the server does not support it, then the response-value will be incorrect, and authentication will fail.

    The size of a digest-response must be less than 4096 bytes.

  • Contact Us

    The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

    If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.