RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Held for Document Update (1)

RFC 3875, "The Common Gateway Interface (CGI) Version 1.1", October 2004

Source of RFC: INDEPENDENT

Errata ID: 3556

Status: Held for Document Update
Type: Technical

Reported By: Christoph Anton Mitterer
Date Reported: 2013-03-18
Held for Document Update by: Nevil Brownlee
Date Held: 2014-02-03

Section 4.1.1 says:

   The AUTH_TYPE variable identifies any mechanism used by the server to
   authenticate the user.  It contains a case-insensitive value defined
   by the client protocol or server implementation.

   For HTTP, if the client request required authentication for external
   access, then the server MUST set the value of this variable from the
   'auth-scheme' token in the request Authorization header field.

      AUTH_TYPE      = "" | auth-scheme
      auth-scheme    = "Basic" | "Digest" | extension-auth
      extension-auth = token

   HTTP access authentication schemes are described in RFC 2617 [5].

It should say:

[see below]

Notes:

The current definition of AUTH_TYPE is flawed, namely then when several authentication methods have been used.
One example would be to have first some SSL/TLS client certificate authentication and then (afterwards) HTTP Basic Authentication.
Other examples are e.g. Apache HTTPD's SSL/FakeBasicAuth, where the SSL certs DN is mapped to the HTTP Basic Authentication username (i.e. the CGI REMOTE_USER variable).

Right now, AUTH_TYPE provides not syntax to encode several layers of authentication types, so the behaviour of webservers is basically undefined (e.g. Apache omits AUTH_TYPE in conjunction with SSL altogether (see https://issues.apache.org/bugzilla/show_bug.cgi?id=45058), which is also problematic, as much software depends on it).


I see two possible solutions:

1) Extend the syntax to allow lists of authentication types be specified.
A syntax like this would be possible:
<1st authentication type>;<2nd authentication type>;<3rd authentication type>
and so on, no trailing ";" required.
The ";" seems to be a possible largely backwards compatible separator as right now:
auth-scheme = "Basic" | "Digest" | extension-auth
extension-auth = token
with
token = 1*<any CHAR except CTLs or separators>
separator = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" |
"\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" |
"}" | SP | HT

In the example above (where first SSL client auth took place, then Basic auth) this would look like e.g. "TLS_client_certificate;Basic" (a name for SSL/TLS client certificate authentication would need to be found).


2) Define AUTH_TYPE explicitly to describe the authentication type at _plain_ HTTP level.
I would like this solution less, as it seems less mighty and future-proof.


Cheers,
Chris.

This erratum points out a flaw in RFC 3875, and suggests some improvements to it - of these, (1) seems the simplest. However, this change would require a new RFC, so I'm setting this to "Hold for update" now.

Nevil

Report New Errata



Search RFCs
Advanced Search
×