Re: Syntax (and other) problems in Digest spec

  Ronald Tschalaer points out a number of issues; in the interest of
  getting resolutions for as many as possible before the end of this
  week (the cutoff for December IETF submissions), I've been asked to
  propose specific wording changes for the new draft.  I've used the
  suggestions that Ronald included in some cases and changed them
  slightly in others.  Many thanks to Ronald for all the testing he's
  been doing in this area.

  Note that for the next round of drafts all the authentication
  specifications (digest and basic) for HTTP are being moved out of
  the successor to 2068 and into a separate RFC to be advanced in
  parallel, so references to section numbers here are to those in the
  current documents (...rev-00.txt and rfc2069); sorry for any
  confusion that causes.

  Taking the issues somewhat out of order... Ronald points out that in
  one major way (from my draft :-) and a couple of minor ones, the
  digest scheme did not follow the general syntax for an
  authentication challenge as given in RFCs 1945 and 2068:

RT>      challenge      = auth-scheme 1*SP realm *( "," auth-param )
RT>      credentials    = basic-credentials
RT>                       | auth-scheme #auth-param
RT>      auth-param     = token "=" quoted-string

  It seems unnecessarily complex to require that the value part of the
  auth-param always be a quoted string (given that it will often be a
  simple true/false value, for example).  I propose that the value
  part of an auth-param be allowed to be a single token.  Ronald also
  pointed out that RFC2069 did not require the 'realm' parameter to be
  the first authentication parameter.  It looks to me as though this
  was actually an attempt to write the fact that this parameter was
  required into the syntax, and since there is no ambiguity created by
  removing that requirement, I would prefer to see the more general
  syntax used in 2069.

  The point may be made that some existing browsers may be broken by
  this in that they may have coded to the 1945/2068 general rule.
  I've done considerable testing in this area and have found that
  browsers fall into two categories:
    - They recognize that a challenge is not basic and give up,
      displaying an error to the user saying that they can't deal with
      this server.
    - They just send basic credentials no matter what the challenge is
      and it doesn't work.
  Browser vendors are invited to figure out which thier product does...

  In either case, changing the spec won't have any effect.

  These changes make the general syntax (now presented in 2068 section
  11 - Access Authentication):

  ================
         challenge      = auth-scheme 1*SP 1#auth-param
         credentials    = basic-credentials
                          | auth-scheme #auth-param
         auth-param     = token "=" ( token | quoted-string )

    The authentication parameter 'realm' is defined for all
    authentication schemes:

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

  This rectifies the minor issues that the value parts of the 'stale',
  'algorithm', and 'uri' auth-params for the Digest scheme were not
  specified as quoted-strings.  The syntax for the 'digest-required'
  flag in the WWW-Authenticate and Authorization header fields was
  worse in that it had no value part specified; it should become (in
  the digest spec sections 2.1.1 and 2.1.2):

         digest-required     = "digest-required" "=" ( "true" | "false" )

  The description of that parameter in 2.1.1 (WWW-Authenticate
  Response Header) should be:

  ================
     digest-required

     If the value of the digest-required parameter is 'true', then any
     request with an entity-body (such as a PUT or a POST) for the
     resource(s) to which this response applies MUST include the
     'digest' attribute in its Authorization header.  If the request
     has no entity-body (such as a GET) then the digest-required value
     can be ignored.  If the digest-required parameter is not
     specified, then its value is 'false'.  If the value of the
     digest-required parameter is 'false', then the 'digest' attribute
     is OPTIONAL on requests for the resource(s) to which the response
     applies.
  ================

  The description for 'digest-required' in 2.1.2 (Authorization
  Request Header) should be:

  ================
     If the value of the digest-required parameter is 'true', the
     response to this request MUST either include the 'digest' field
     in its Authentication-Info header or the response should be an
     error message indicating the server is unable or unwilling to
     supply this field.  In the latter case the requested entity MUST
     not be returned as part of the response.  If the digest-required
     parameter is not specified in the request, then its value is
     'false'.  If the value of the digest-required parameter is
     'false', then the 'digest' attribute is OPTIONAL for the response
     to this request.
  ================

================================================================

  Ronald also points out that commas are valid unescaped in URIs, so
  that the 'domain' authentication parameter as specified in the
  Digest draft:

     domain              = "domain" "=" <"> 1#URI <">

  is ambiguous if one or more URI in the list has a comma in it.  I
  propose that we accept his suggestion to make the value part of the
  'domain' authentication parameter a quoted space-separated list of
  URIs:

  ================
     domain              = "domain" "=" <"> URI *( 1*SP URI ) <">

  domain

  A space-separated list of URIs.  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 parameter is omitted or
  empty, the client should assume that the domain consists of all URIs
  on the responding server.
  ================

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Monday, 17 November 1997 14:16:35 UTC