- From: Josh <josh@early.com>
- Date: Tue, 10 Dec 1996 17:33:58 -0500 (EST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 ) -----------------------------------------------------------------------------
Received on Tuesday, 10 December 1996 14:41:03 UTC