W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

comments on draft-ietf-http-authentication-01.txt

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Mon, 23 Mar 1998 16:45:41 -0500 (EST)
Message-Id: <199803232145.QAA17636@aleatory.research.bell-labs.com>
To: jg@w3.org, masinter@parc.xerox.com
Cc: http-wg@cuckoo.hpl.hp.com
Here are some comments on draft-ietf-http-authentication-01.

Dave Kristol
Substantive stuff:

    (Formatting)  On a number of pages (e.g., 5,7,9), the text runs
    into the footer.

    The spec. is incomplete in its description of whether auth-params
    are case-sensitive.  For example, "realm" and "stale" are mentioned
    explicitly.  I think it would be simpler to say the
    attribute/parameter/directive (see below) names are
    case-insensitive, but that the values may or may not be

    What should a client do if it receives unrecognized attributes?
    What should a server do if it receives unrecognized attributes?

1.2 Access Authentication Framework
    credentials = basic-credentials | auth-scheme #auth-param

    	I think this should now read
	    credentials = basic-credentials | digest-credentials
		| auth-scheme #auth-param

    The term "protection space" gets used without a definition (here),
    but the spec. describes how a client can reuse credentials for such
    a protection space.  I think we should say that the description of
    any auth-scheme must describe the rules for deciding when two
    objects are in the same protection space.  In particular, a client
    must be able to tell, so it knows whether or not to send credentials

Sect. 3.2.1, The WWW-Authenticate Response Header
    [domain attribute]
    If this keyword is omitted or empty, the client should assume that
    the domain consists of all URIs on the responding server.

	This behavior is different from Basic.  If we want Digest to be
	a more or less drop-in replacement, shouldn't the default
	behavior mimic Basic?

	Furthermore, this paragraph constitutes the equivalent of a
	description of the Digest protection space, but it never calls
	it such.  It would be helpful to be more explicit.  (There's
	additional related information in section 3.3.)

Sect. 3.2.2, The Authorization Request Header
    [cnonce attribute]
    RFC 2069-compliant implementations might break upon receiving this
    new, previously unknown attribute.

    The grammar for nc-value says
	nc-value         = 8LHEX
    but the examples all show four-character nc= values, as in this
    section.  The examples ought to be compliant. :-)

    Also, why have such a restrictive syntax?  Why not 1*LHEX?

    [description of calculations]
    If the "qop" value is "auth":
	Shouldn't this read
	    If the "qop" value is "auth" or "auth-int":

Sect. 3.2.3, The Authentication-Info Header
    What should a client do if the rspauth=response-digest information
    is wrong?
    Isn't there the risk that an intervening proxy could change the
    status code?
	... Authorization header for the request, A2 is
	   A2       = Status-Code ":" digest-uri-value
	and if "qop=auth-int", then A2 is
	   A2       = Status-Code ":" digest-uri-value ":" H(entity-body)


Typographical nits, etc.:

    "This document also provides ..."
    		   ==== -> delete

    "... other new elements have been added - for compatibility, ..."
    change to
    "... other new elements have been added.  For compatibility, ..."

Sect. 1.1, Reliance on...
    "It uses using the extended..."
    	     ===== -> delete

Sect. 2, Basic Authentication Scheme
    The "basic" authentication ...
        ======= -> Basic

    There are no optional [Basic] authentication parameters.
    			  ======= -> add

       credentials = basic-credentials
      ^-- delete extra space
      challenge   = "Basic" realm

    A proxy may respond with the same challenge using the
    			     ======== -> change to: an analogous
    Proxy-Authenticate header field.

Sect. 3.1.1 Purpose
    This document provides the specification for such a scheme, which
	change to: "a different scheme that" <-   ====================
    does not send the password in cleartext. It is referred to as
    "Digest Access Authentication".

Sect. 3.2.1, The WWW-Authenticate Response Header
     digest-challenge  = 1#( realm | [ domain ] | nonce |
                         [ opaque ] |[ stale ] | [ algorithm ] |
                      [ qop-options ] )
		      === -> indent correctly

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

	These thingies get referred to variously (and inconsistently) as
	"parameters", "directives", and "attributes".  It would be nice
	if one term were chosen and used consistently.
    [algorithm attribute]
    ... for the difference in usage, see the description .
    							^-- delete
Sect. 3.2.2, The Authorization Request Header
    credentials      = "Digest" digest-response
	should be
	    digest-credentials      = "Digest" digest-response

    see below for the defintions for A1 and A2.
    ^-- See	      ========== -> definitions

    This stuff should move after the description of A1:
	   passwd   = < user's password >

    This example needs to quote realm-value:
	username="Mufasa", realm=myhost@testrealm.com
    should be
	username="Mufasa", realm="myhost@testrealm.com"

    The description of white space in the digest is repetitive and
    excessive (IMO).  (And, I suspect, people will *still* get it
    wrong, even with the belabored point.)

Sect. 3.2.3, The Authentication-Info Header
    [message-qop attribute]
    === -> change to: message-qop
       Indicates the "quality of protection" options applied to the
      ^ -- delete
      response by the server.  The value "auth" indicates authentication;

    header, except that if "qop=auth" or is not specified in the
    					^-- insert: qop
    Authorization header for the request, A2 is

Sect. 3.3, Digest Operation
    A client may remember the username, password and nonce values, so
    that future requests within the specified <domain> may include
		change to: domain specified by the domain attribute
    the Authorization header preemptively.

    As with the basic scheme, proxies must be completely transparent
    		===== -> Basic

Sect. 3.6, Proxy-Authentication and Proxy-Authorization

    ... sections 10.30 and 10.31 of the HTTP/1.1 specification [2] and
    		 =====	   =====
    should be:	 14.33	   14.34

    authentication, the proxy/server must issue the "HTTP/1.1 401
    Unauthorized " response with a "Proxy-Authenticate" header.
    		^-- delete

Sect. 3.5, Example
    ... same as that for the WWW-Authenticate header as defined above in
    section 2.1.
    	    === -> should be: 3.2.1

    The client/proxy must then re-issue the request with a Proxy-
    Authorization header, with attributes as specified for the Authorization
    header in section TBD above.
    		      === -> should be: 3.2.2

Sect. 4.1, Authentication of Clients using Basic Authentication
    The first three paragraphs are a bit repetitions.  Here's a

    Basic authentication is not a secure method of user
    authentication.  It essentially transmits the user's password as
    cleartext across the physical network.  Therefore it SHOULD NOT be
    used (without enhancements) to protect sensitive or valuable
    information.  Digest authentication fixes this flaw.

    Basic authentication does not protect the entity, which is
    transmitted as cleartext across the physical network.  Digest
    authentication can reduce this vulnerability.

    HTTP does not preclude additional authentication schemes and
    encryption mechanisms from being employed to increase security, nor
    does it preclude the addition of enhancements (such as schemes to
    use one-time passwords) to the authentication schemes described

Sect. 4.2, Authentication of Clients using Digest Authentication
    authentication is both useful and appropriate (any service in
    				change to:      ==== -> e.  (Any
    present use that uses Basic should be switched to Digest as soon
    as practical).
    		== -> .)

Sect. 4.5, Replay Attacks
    use of  integrity protection most metadata in header fields is
    	   ^-- delete

Sect. 4.6, Weakness Created by Multiple Authentication Schemes
    agent should choose to use  the first challenge it understands and
    			       ^-- delete
    only as good as that of the of the weakest of the authentication
    				====== -> delete

Sect. 4.8, Man in the Middle
    The countermeasure against this attack is to for clients to be
    					      === -> delete

Sect. 4.10, Precomputed dictionary attacks
    The countermeasure against this attack is to for clients to be
    					      === -> delete

Sect. 4.11, Batch brute force attacks
    The countermeasure against this attack is to for clients to be
    					      === -> delete

Sect. 4.14, Summary
    nonces or digests to eliminate the possibility of replay. Others may
    							      add: be ---^
Sect. 7, Authors' Addresses

    Scott D. Lawrence
    Agranat Systems, Inc.
    1345 Main St.
    Waltham, MA  02154, USA

    EMail: stewart@OpenMarket.com
	   ====================== -> lawrence@agranat.com
Received on Monday, 23 March 1998 13:55:50 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:13 EDT