Problem with authentication challenge BNF and Digest

As far as I know this has not been mentioned on the list...

While writing the parser for the access authentication challenge parser, it 
became clear that it is almost impossible to distinguish the auth-param from 
a new challenge (there may be multiple challenges separated by comma).

The only way to do this is to look at the first token after a comma and 
check if the first sign after this token is a '='. If so then it is a 
parameter to the current challenge, otherwise it is a new challenge. The 
text in Section 14.46 actually mentions this risk of conflict but I don't 
think that is sufficient.

According to the latest Digest Authentication draft from John Franks the 
described syntax for the WWW-authenticate header doesn't contain a comma at 
all (however, it does include them in the examples in Section 2.4). Hence 
the two versions are in conflict and digest is in internal conflict. Another 
problem is that the challenge BNF requires a single space between the 
auth-scheme and the realm and digest doesn't. 

We can do two things:

1) Use the Digest draft version and remove the comma intirely. This will 
require
   changes to the HTTP/1.1 draft

2) Use a ";" instead as a delimiter and change both drafts

I am in favor of 2) as this will make parsing a challenge similar to parsing 
an accept header and hence make implementor's life easier and the change of 
getting things right bigger.

A second difference is that the challenge BNF requires a single SP between 
the auth-scheme and the realm and digest does not. The one SP seems to me to 
be due to backwards compatibility problems, but do we have any proof that 
LWS would break existing applications?

Solution 2) will require changes in two places:

Change 1
--------

11 Access Authentication

HTTP provides a simple challenge-response authentication mechanism which
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 "=" 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.

!       challenge      = auth-scheme 1*SP realm *( "," auth-param )
!       challenge      = auth-scheme 1*SP realm *( ";" auth-param )

Change 2
--------

14.46 WWW-Authenticate

The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at least
one challenge that indicates the authentication scheme(s) and parameters
applicable to the Request-URI.

       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

! The HTTP access authentication process is described in section 11. User
! The HTTP access authentication process is described in section 11.
- agents MUST take special care in parsing the WWW-Authenticate 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.

-- 
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Friday, 5 July 1996 15:38:45 UTC