HTTP SASL: use of HTTP OPTIONS method for authentication

Hi,

Magnus Nystrom, Robert Zuccherato and myself have written a draft that
adds a generic authentication framework (SASL, RFC 2222) to HTTP 1.1
(currently draft-nystrom-http-sasl-01.txt). SASL framework allows a
client to select an authentication mechanism from the list of mechanisms
supported by a server. This document is the next logical step after HTTP
Basic and Digest authentication.

Firstly, I would like to solicit an input from the HTTP community about
the document and its approach.

Secondly, I would like to request some suggestions about the use of HTTP
OPTIONS.
The problem is better described using the following example. Imagine a
client that tries to post some data to a server using the POST method.
Also imagine that the server requires authentication using SRP SASL
mechanism when posting to the requested URL. Now SRP authentication
requires multiple exchanges between client and server. If the document
being posted is big, it is unwise to include its body with every
authentication step. The proposed solution is to use the OPTIONS method
(with no body) instead of the POST for the duration of the
authentication exchange. Is it a legitimate use of OPTIONS method? From
the description of OPTIONS (in RFC 2616) the proposed usage seems
appropriate:

   The OPTIONS method represents a request for information about the
   communication options available on the request/response chain
   identified by the Request-URI. This method allows the client to
   determine the options and/or requirements associated with a resource,

   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

The following protocol example illustrates what was said above:

  C: POST http://classified.example.com/classified/feedback-form.pl
HTTP/1.1
     Host: classified.example.com

     ...Request body...

  S: HTTP/1.1 401 Unauthorized
     WWW-Authenticate: SASL
              mechanism="DIGEST-MD5,GSSAPI,CRAM-MD5",
              realm="testrealm@example.com",
              id="0001"

  C: OPTIONS http://classified.example.com/classified/feedback-form.pl
HTTP/1.1
     Host: classified.example.com
     Authorization: SASL
              mechanism="DIGEST-MD5",
              id="0001"

  S: HTTP/1.1 401 Unauthorized
     WWW-Authenticate: SASL id="0001",

challenge=cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0

RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hhcnNldD11dG
                YtOA==

  C: OPTIONS http://classified.example.com/classified/feedback-form.pl
HTTP/1.1
     Host: classified.example.com
     Authorization: SASL id="0001",

credential=Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2

QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw

MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im

ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw
                ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=

  S: HTTP/1.1 401 Unauthorized
     WWW-Authenticate: SASL
              id="0001",

challenge=cnNwYXV0aD00YjJiYjM3ZjA0OTEwNTA1Nzc3YzJmNjM4YzkyMjcyNQ==

  C: POST http://classified.example.com/classified/feedback-form.pl
HTTP/1.1
     Host: classified.example.com
     Authorization: SASL id="0001"

     ...Request body...

  S: HTTP/1.1 200 OK
      WWW-Authenticate: SASL id="0001"

     ...Response Document follows...

Comments?

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Received on Thursday, 13 June 2002 06:44:41 UTC