[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                          N. Shanks
Internet-Draft                                         November 27, 2012
Intended status: Standards Track
Expires: May 31, 2013


     Hypertext Transfer Protocol (HTTP) Form Authentication Scheme
                draft-shanks-http-form-authentication-00

Abstract

   This document defines the "Form" HTTP authentication scheme.  It
   allows web developers access to standard HTTP-based authentication
   mechanisms whilst retaining control over the look and feel of their
   log-in page, without requiring any client-side scripting.  Comments
   are requested and should be addressed to the author.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 31, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Shanks                    Expires May 31, 2013                  [Page 1]

Internet-Draft          HTTP Form Authentication           November 2012


1.  Introduction

   This document builds upon the Digest authentication scheme defined by
   [RFC2617] and amended by [draft-ietf-httpbis-p7-auth], but changes
   the process for creating the A1 value (as is defined by Section
   3.2.2.2 of [RFC2617]), and defines different user agent behaviour.
   It is intended to allow migration away from application/
   x-www-form-urlencoded requests over unencrypted HTTP which transmit
   the password in plaintext; and to do so in a way that, when widely
   supported by user agents and server software, will also allow simple
   migration from Digest authentication, should developers who are
   already using that want to take control of the credentials
   solicitation appearance.  It is not intended for use in conjunction
   with TLS, as it offers little benefit there, but nothing prevents its
   use in that context if so desired.

1.1.  Conformance

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].






























Shanks                    Expires May 31, 2013                  [Page 2]

Internet-Draft          HTTP Form Authentication           November 2012


2.  The "Form" Authentication Scheme

   Supporting user agents MUST present to the user (or to a software/
   hardware agent acting on behalf of the user) the body of a response
   which uses either a HTTP status code of 401 and a WWW-Authenticate
   header specifying the "Form" scheme; or a 407 status code and a
   Proxy-Authenticate header specifying the "Form" scheme.  This
   response body MUST contain a form in a format that the user agent can
   understand, e.g.  HTML <form> element with <input> children, XML
   incorperating XForms <xf:input> elements, or other comparable markup
   which the user agent knows about.

   If the response does not meet these conditions, then the user agent
   MUST ignore this document and process the response as it would
   otherwise.

   When submitting the form, instead of obeying the action, method and
   encoding specified by the form, user agents MUST create an
   Authorization header by concatenating the values of each form input,
   in document order, each seperated from the next by a single colon
   character ":" not surrounded by whitespace, possibly followed by
   nonce and cnonce values also seperated by a colon character, then
   computing the hash of the resulting string using the MD5 algorithm,
   or otherwise per the algorithm parameter (e.g. those defined by
   [draft-ahrens-httpbis-digest-auth-update]).

   When no nonce value is provided by the server

       A1 = *(unq(form-field-value) ":") unq(form-field-value)

   If a nonce value is provided by the server

       A1 = H( *(unq(form-field-value) ":") unq(form-field-value) )
                   ":" unq(nonce-value)
                           ":" unq(cnonce-value)

   The result now forms the "A1" input to the standard Digest
   authentication computation Section 3.2.2.1 of RFC2617 [RFC2617].  The
   user agent MUST then re-submit the original request with this header
   included, to the original Request-URI Section 5.1.2 of RFC2617
   [RFC2617].

   This scheme introduces no new authentication parameters.

2.1.  Examples

   This section is non-normative.




Shanks                    Expires May 31, 2013                  [Page 3]

Internet-Draft          HTTP Form Authentication           November 2012


   An example in HTML:

   <form action=/login.php method=POST>
       <input name=user required>
       <input name=realm type=hidden value=admin>
       <input name=pass type=password required>
       <input name=pin type=password size=4>
       <button>Log In</button>
   </form>

   When filled out by the user (or acting agent) with values of
   user=dave, pass=p455w0rd and pin=9876, and assuming the default MD5
   algorithm is to be used, this form will result in an Authorization
   header being generated by conforming user agents by means of
   computing the function H(A1) = md5(dave:admin:p455w0rd:9876), then
   combining that with qop, nonce and other parameters as per [RFC2617].

   An empty field results in an empty string being concatenated, with no
   special treatment, i.e. if no value for the PIN were provided in the
   above example, the MD5 hash would be computed as md5(dave:admin:
   p455w0rd:).  An empty value between two others would result in a
   double colon appearing in the string to be hashed, "::".  The input
   names, if provided, are not used in any way.  They serve only as
   fallback for UAs that do not support this document.  In the above
   case, user agents which do not support this document are expected to
   send a POST request to the path /login.php with the form fields URL-
   encoded in the request body.  This allows for incremental support to
   be introduced as user agents are released which support this document
   and users upgrade.






















Shanks                    Expires May 31, 2013                  [Page 4]

Internet-Draft          HTTP Form Authentication           November 2012


3.  Security Considerations

   Yet to be written (mostly).

   All security considerations in [RFC2617] pertaining to Digest
   authentication method apply to the Form method too.

   Until such time as standard server software (such as Apache,
   Lighttpd, Nginx, etc.) nativly supports this authentication scheme,
   web developers will have to implement support using server-side
   processing langauges (such as Ruby, Node.js or PHP).  All incoming
   requests to URIs beyond the authentication point will need to be
   caught and processed for authentication credentials, to avoid
   exposing valid URIs from invalid ones.  It is expected that third-
   party libraries will be developed to ease this.




































Shanks                    Expires May 31, 2013                  [Page 5]

Internet-Draft          HTTP Form Authentication           November 2012


4.  IANA Considerations

   IANA is to register the "Form" authentication scheme, citing
   Section 4.1 of this document as the reference, within the http-
   authschemes registry at
   <http://www.iana.org/assignments/http-authschemes> as established by
   Section 2.3 of [draft-ietf-httpbis-p7-auth].

4.1.  Authentication Scheme Registration

   Authentication scheme name: Form

   Specification text: This document

   Notes: A variant of the Digest authentication scheme, with new
   processing requirements for the server and the user agent.



































Shanks                    Expires May 31, 2013                  [Page 6]

Internet-Draft          HTTP Form Authentication           November 2012


5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC2617]  Franks, J., "HTTP Authentication: Basic and Digest Access
              Authentication", RFC 2617, June 1999.

   [draft-ietf-httpbis-p7-auth]
              Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Authentication", October 2012.

5.2.  Informational References

   [draft-ietf-httpbis-authscheme-registrations]
              Reschke, J., "Initial Hypertext Transfer Protocol (HTTP)
              Authentication Scheme Registrations", October 2012.

   [draft-ahrens-httpbis-digest-auth-update]
              Ahrens, D. and R. Shekh Yusef, "HTTP Digest Access
              Authentication Algorithm Update", July 2012.




























Shanks                    Expires May 31, 2013                  [Page 7]

Internet-Draft          HTTP Form Authentication           November 2012


Appendix A.  Known Issues

   o  Server requirements and User Agent requirements are inter-mixed in
      Section 2, and both are poorly defined.

   o  How should the realm, and other authentication header parameters,
      be reflected in the form.  Should form fields with the same name
      as a parameter adopt the value of the parameter in supporting UAs?
      The value of the form field will be submitted to the action URI by
      old UAs.  Should this be true only for "realm"?









































Shanks                    Expires May 31, 2013                  [Page 8]

Internet-Draft          HTTP Form Authentication           November 2012


Author's Address

   Nicholas Shanks
   45 Oaklands Wood
   Hatfield, Hertfordshire  AL10 8LU
   United Kingdom

   Phone: +44 (0)1707 258219
   Email: nickshanks@nickshanks.com
   URI:   http://nickshanks.com/









































Shanks                    Expires May 31, 2013                  [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/