Proxy authentication draft
Josh (josh@early.com)
Tue, 10 Dec 1996 17:33:58 -0500 (EST)
Here is the first cut t the auth draft
> Network Working Group Josh Cohen
> Internet-Draft Netscape Communications Corp.
> 5 December 1996
> HTTP Proxy Authorization Header Modifications
> <draft-cohen-httpauth-00.txt>
> Status of this Memo
> This document is an Internet-Draft. Internet-Drafts are working
> documents of the Internet Engineering Task Force (IETF), its areas,
> and its working groups. Note that other groups may also distribute
> working documents as Internet-Drafts.
> 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.''
> To learn the current status of any Internet-Draft, please check the
> ``1id-abstracts.txt'' listing contained in the Internet- Drafts
> Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
> munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
> ftp.isi.edu (US West Coast).
> Abstract
> Currently, the HTTP specification allows for client request proxy
> authorization via the Proxy-Authenticate headers. Servers can use
> 'Proxy-Authenticate:' to prompt a client to send 'Proxy-
> Authorization:' including appropriate credentials for use of the
> proxy.
> While the 'realm', a parameter to the authentication scheme, allows
> usage of different credentials based on the URL being processed,
> there is no specific way to link different credentials with different
> proxies a chain. This makes is impossible to have more than one
> proxy in a chain which requires authentication based on different
> credential databases.
> J. Cohen [Page 1]
> INTERNET-DRAFTHTTP Proxy Authorization Header Modifications5 December 1996
> Header Modifications
> WWW-Authenticate:
> In section 14.46 of the HTTP/1.1 Internet Draft, it reads
> WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
> this draft proposes to change that to:
> WWW-Authenticate = "WWW-Authenticate" ":" 1#(realm-id
> challenge)
> Authorization:
> In section 14.8 of the HTTP/1.1 Internet Draft, it reads
> Authorization = "Authorization" ":" credentials
> this draft proposes to change that to:
> Authorization = "Authorization" ":" realm-id ";" credentials
> Proxy-Authenticate:
> In section 14.33 of the HTTP/1.1 Internet Draft, it reads
> Proxy-Authenticate = "Proxy-Authenticate" ":" challenge
> this draft proposes to change that to:
> Proxy-Authenticate = "Proxy-Authenticate" ":" realm-id challenge
> Proxy-Authorization:
> In section 14.34 of the HTTP/1.1 Internet Draft, it reads
> Proxy-Authorization = "Proxy-Authorization" ":" credentials
> this draft proposes to change that to:
> Proxy-Authorization = "Proxy-Authorization" ":" realm-id ";"
> credentials
> J. Cohen [Page 2]
> INTERNET-DRAFTHTTP Proxy Authorization Header Modifications5 December 1996
> challenge Definition
> In section 11 of the HTTP/1.1 Internet Draft, it reads
> auth-scheme = token
> this draft proposes to change that to:
> auth-scheme = "auth-scheme" "=" token
> and where it reads:
> challenge = auth-scheme 1*SP realm *( "," auth-param )
> this draft proposes to change that to:
> challenge = auth-scheme 1*SP realm *( ";" auth-param )
> realm-id Field Format
> realm-id = "realm-id" "=" ( token | quoted-string )
> Discussion
> While the original intentions of the draft meant to provide a
> way to authenticate multiple proxies in a chain, the solution has
> become more involved. To implement the change, and satisfy
> consistency rules in HTTP/1.1, specifically rules about header
> collapsing, syntactical changes are required to the definitions of
> the 'challenge'. This can affect both WWW-Authenticate as well as
> Proxy-Authenticate, as well as add to the backward incompatibility of
> version 1.1 with previous versions.
> In addition to the Proxy-Authenticate headers, we propose to
> modify the WWW-Authenticate: and Authorization: headers as well.
> This is to maintain syntactic consistency. With the modification of
> the challenge definition, and the inclusion of the 'realm-id' field,
> the challenge becomes a set of paramters to the value of 'realm-id'.
> We feel this is correct since the challenge is unique to the server
> requesting the credentials. Unfortunately, this has ill effects for
> the current definition of the WWW-Authenticate: and Authorization:
> headers in the HTTP/1.1 Draft. Without the 'realm-id' field, the
> challenge becomes a set of parameters with no associated header field
> value. While contemplating this it became apparent that there would
> be benefits to having the 'realm-id' field in those headers as well.
> Currently, the 'realm' parameter serves as both a user prompt
> J. Cohen [Page 3]
> INTERNET-DRAFTHTTP Proxy Authorization Header Modifications5 December 1996
> as well as an identifier to manage the scope of authorization
> credentials. This is problematic at best since while the user
> prefers a verbose message, the protocol would seem to prefer a short,
> unique identification to define the scope of the credentials. By
> adding the 'realm-id' field, we now have two different parameters to
> represent the two different functions which had been previously
> overloaded into a single parameter.
> Despite the extra effort required, we feel that it is a
> worthwhile change. While it complicates implementations in the short
> term, it makes the authentication headers comply with HTTP/1.1's own
> rules about header collapsing, which it previously did not. In
> addition to the compliance issues, this allows multiple proxies to
> exist in a chain which require separate authorization credentials.
> This type of proxy usage is becoming more widespread as caches play a
> more important role in the protocol itself and as organizations are
> deploying larger and more complex cache hierarchies. In addition to
> the benefits in proxies, it allows authorization scopes to have
> unique identifiers separate from a user prompt which can be prone to
> name collisions.
> Security Considerations
> This draft does not address any security considerations.
> Author's Address
> Josh Cohen
> Netscape Communications Corporation
> 501 E. Middlefield Rd
> Mountain View, CA 94043
> Phone (415) 937-4157
> EMail: josh@netscape.com
> J. Cohen [Page 4]
> --
> -----------------------------------------------------------------------------
> Josh Cohen Netscape Communications Corp.
> Netscape Fire Department
> Server Engineering
> josh@netscape.com http://home.netscape.com/people/josh/
> -----------------------------------------------------------------------------
--
-----------------------------------------------------------------------------
Josh R Cohen /Server Engineer josh@early.com
Netscape Communications Corp.
(This message is sent from my private email account to reach me for
business related issues, mailto:josh@netscape.com )
-----------------------------------------------------------------------------