2004/id/draft-petke-http-auth-scheme-00.txt



INTERNET-DRAFT                                                   G Brown
draft-petke-http-auth-scheme-00.txt                           CompuServe
Expires: 15-May-97                                      15 November 1996


                    Remote Passphrase Authentication
                  Part Three:  HTTP Authentication Scheme


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 
   
   Remote Passphrase Authentication provides a way to authenticate a 
   user to a service by using a pass phrase over an insecure network, 
   without revealing the pass phrase to eavesdroppers. In addition, the
   service need not know and does not learn the user's pass phrase, 
   making this scheme useful in distributed environments where it would 
   be difficult or inappropriate to trust a service with a pass phrase 
   database or to allow the server to learn enough to masquerade as the 
   user in a future authentication attempt.

   This draft is part three of a four part series and explains how to
   incorporate the RPA mechanism into HTTP.  Part one of this series
   (draft-petke-ext-intro-00.txt) provides an extended introduction to
   the problems of authentication over insecure networks.  Part two
   (draft-petke-mech-00.txt) explains the RPA mechanism.  Part four
   (draft-petke-serv-deity-protocol-00.txt) explains the protocol
   between the service and deity.

   This scheme was inspired by Dave Raggett's Mediated Digest
   Authentication paper.

   
G Brown                                                         [Page 1]

INTERNET-DRAFT             RPA - Part Three             15 November 1996
  

Table of Contents 
   
   1. INTRODUCTION 
   
   2. USING THIS AUTHENTICATION MECHANISM IN HTTP  
   2.1 AUTHENTICATION      
   2.2 REAUTHENTICATION CHEATING   
   2.3 REAUTHENTICATION    

   3. SECURITY CONSIDERATIONS

   4. AUTHOR'S ADDRESS
   

1. Introduction 
   
   See part two of this series (draft-petke-mech-00.txt) for an
   explanation of the mechanism, its motivation, and its
   specification. This part describes only the HTTP encapsulation of the
   mechanism. 


2. Using this authentication mechanism in HTTP 
   
   The HTTP client may indicate that it supports this authentication 
   mechanism by whatever technique is appropriate. 
   
        [For example, a header like "Extension: 
        Security/Remote-Passphrase" might be appropriate, if that 
        extension mechanism is adopted. The extension mechanism is, 
        of course, independent of authentication, but we mention it 
        here to point out the issue. Theoretically, the server does 
        not need to know ahead of time whether the client supports 
        a particular authentication scheme.] 
   
   We begin by defining a security context, which represents a logical 
   connection between a user and Web server. Because the context spans 
   HTTP connections, the server assigns a security context identifier, 
   an opaque string, when it creates a context, and it informs the 
   client of its value in the Security-Context attribute of the 
   WWW-Authenticate header. The client includes the identifier in the 
   Authorization header of subsequent requests that refer to the same 
   context. 
   
   From the client's point of view, the pair (server IP address, 
   security context identifier) uniquely identifies a context; the same 
   is essentially true for the server, although a server can make its 
   security context identifiers unique, rather than (client IP address, 
   identifier) pairs. 


G Brown                                                         [Page 2]

INTERNET-DRAFT             RPA - Part Three             15 November 1996

   
   Note that a client might refer to the same security context from 
   different IP addresses, if he switches proxies (is that possible?). 
   Note also that the client IP address alone is not adequate to 
   identify the security context. A multiple-user host, an HTTP proxy, 
   and a SOCKS server are examples of situations in which the same IP 
   address may be involved in many security contexts. And even an 
   individual PC running two browsers falls into this category--if I 
   connect to you from both browsers, I'll establish two security 
   contexts, which might or might not refer to the same user identity. 
   
   The server should assign security context identifiers that are unique 
   over time. If the client refers to an old context identifier--the 
   user returns to his PC tomorrow morning and clicks a link that was 
   displayed yesterday--it will do no harm if that identifier had been 
   reused, but the server won't be able to recognize it as such. 
   
   The security context "contains" information appropriate to the 
   context, such as the realm name, user and service names, session key, 
   challenges, state, etc. We'll gloss over the details in this 
   explanation. Note that a session using this mechanism is secure; 
   unlike other "cookie"-type mechanisms, we do not depend on the 
   secrecy of the context identifier. However, the content of requests 
   and responses is not authenticated, in this version of the protocol. 
   
   We define the authentication scheme name "Remote-Passphrase", used as 
   described below. The client begins by making a request for which the 
   server requires identification and authentication; because there is 
   no Authorization header in the request, the server will demand 
   authentication. 
   
   All WWW-Authenticate and Authorization headers used with this scheme 
   may include a Version attribute. When omitted, as in the examples 
   below, Version="1" is implied, for this version of the protocol. 

   
2.1 Authentication 
   
   The server creates a new security context, assigns it an identifier, 
   and responds 401 Unauthorized and includes the header 
   
       WWW-Authenticate:
               Remote-Passphrase
               Realm="compuserve.com",
               State="Initial",
               Realms="foo@compuserve.com
                       bar@aol.com:iso-8859-1,lc,md5",
               Challenge="base64 encoding of service challenge",
               Timestamp="19950808132430",
               Security-Context="opaque"


G Brown                                                         [Page 3]

INTERNET-DRAFT             RPA - Part Three             15 November 1996

   
   The first token specifies the authentication scheme, 
   Remote-Passphrase. That's followed by a comma-separated list of 
   attribute-value pairs. HTTP requires the first attribute to be called 
   "Realm" and specify the realm in which the user must indicate his 
   identity, but we support multiple realms, so this is merely one realm 
   acceptable to the server, perhaps its preferred realm. 
   
   The State attribute distinguishes this as the initial request for 
   authentication. 
   
   The Realms attribute provides a list of realms in the order preferred 
   by the server, with the server's name in each realm. Each may be 
   followed by a colon and a list of parameters separated by commas, to 
   drive the transformation from pass phrase to 128-bit shared secret 
   for that particular realm. Refer to part two of this specification 
   (draft-petke-mech-00.txt) for more information about the
   transformation. 
   
   The default transformation, if the colon and parameters are omitted, 
   is specified in part two of this specification
   (draft-petke-mech-00.txt), the Unicode character set in
   big-endian ("network") byte order, with all characters converted to
   lowercase, and the MD5 hash algorithm. 
   
   Otherwise, a single parameter, "none", implies that the client must 
   already possess a 128-bit value, and no transformation from a textual 
   pass phrase is defined. 
   
   Otherwise, three parameters control the transformation from a textual 
   pass phrase to the 128-bit shared secret used by the authentication 
   mechanism, if such a transformation takes place (it might not, if the 
   client believes it already knows a 128-bit value for this user). The 
   three parameters specify the character set: Unicode 1.1 
   ("unicode-1-1") or ISO 8859-1 ("iso-8859-1"); case conversion: 
   convert to all caps ("uc"), all lowercase ("lc"), or as-is with no 
   case conversion ("nc"); and hash function: MD5 ("md5"). Omitting the 
   colon and parameters is equivalent to specifying 
   "unicode-1-1,lc,md5". 
   
        [There's no need for US-ASCII as a character set, because 
        ISO 8859-1 will give the same results. Note that these 
        parameters are part of the base authentication mechanism 
        specification; only the means of conveying them, and the 
        textual names shown above, are specific to this HTTP 
        authentication scheme. Other variations can be added, but 
        they must be added to the authentication mechanism defined 
        by part two of this specification
        (draft-petke-mech-00.txt) as well as here in part three.] 


G Brown                                                         [Page 4]

INTERNET-DRAFT             RPA - Part Three             15 November 1996

   
   We convey this information to the client because there's no reason 
   the client would otherwise know whether a particular realm's pass 
   phrases are case sensitive, etc. The server, on the other hand, 
   simply must "know" how its particular realm uses pass phrases; these 
   characteristics are a part of server's configuration along with its 
   name in the realm, deity addresses, etc. 
   
   The Challenge attribute specifies the service's challenge. It is an 
   arbitrarily long sequence of octets containing arbitrary bit 
   patterns, represented in base64. The client must decode it before 
   using it in the authentication calculations; it might contain nulls 
   or any other bit patterns. The client may decline to trust the server 
   and abort at this point, if it deems the challenge to be too short. 
   
   The Timestamp attribute specifies the server's timestamp. This is a 
   UTC date and time in the format specified by the authentication 
   standard. It may be treated as an opaque string by the client, unless 
   the client chooses to interpret it to make a judgment about its 
   reality; but beware that you probably don't have a reliable source of 
   universal time. 
   
   The Security-Context attribute contains the server-assigned security 
   context identifier, an opaque string. 
   
   The client creates its security context and repeats the request with 
   an Authorization header: 
   
       Authorization:
               Remote-Passphrase
               State="Initial",
               Security-Context="opaque",
               Realm="compuserve.com",
               Username="70003.1215",
               Challenge="base64 encoding of user challenge",
               Response="base64 encoding of response"
   
   The first token specifies the authorization scheme. That's followed 
   by the state, "Initial" for the initial authentication; the security 
   context identifier; the realm chosen by the user; the user's identity 
   in that realm; the user's challenge; and the user's response. 
   
   The service looks up the security context. If the security context 
   identifier refers to no context or refers to a context that is 
   already established, the server creates a new security context with a 
   new identifier, then responds 401 Unauthorized and includes a fresh 
   WWW-Authenticate header as shown above, with which the client can 
   repeat the request with correct authentication information. 
   
        [Or does this risk a loop? We could just respond with an 
        error.] 


G Brown                                                         [Page 5]

INTERNET-DRAFT             RPA - Part Three             15 November 1996

   
   Any existing security context is unaffected; if I send you a request 
   that specifies someone else's security context, you should not delete 
   his context. 
   
   Otherwise--the context identifier is recognized and that context is 
   in the awaiting authentication state--the server performs the 
   authentication process. 
   
   The server may verify that the client's IP address matches that in 
   the previous request that created the "pending" context. The only 
   risk is that someone might change proxies at whim, which seems 
   unlikely. 
   
   If the authentication process fails, the server refuses to process 
   the request, but does not delete the "pending" security context. It 
   generates a 401 Unauthorized response with a WWW-Authenticate header 
   that indicates failure: 
   
       WWW-Authenticate:
               Remote-Passphrase
               Realm="nonsense",
               State="Failed"
   
   It is up to the client to try the request again (without an 
   Authorization header), restarting the entire process, if it believes 
   that it was using the wrong pass phrase but it now has the right pass 
   phrase. 

        [Sending another "Initial" WWW-Authenticate header would 
        provoke a loop: the browser would calculate a new response 
        and retry the request, which is pointless if the browser's 
        idea of the pass phrase is wrong, so we indicate the 
        failure.] 
   
        [One could argue that the browser should forget whichever 
        cached pass phrase it used, in order to prompt for it again 
        if the user tries to next time. But the pass phrase might 
        have been correct, depending on what exactly went wrong at 
        the server.] 
   
   Otherwise, having successfully authenticated the user, the server 
   processes the client's request and returns an appropriate response, 
   including in its reply: 
   
       WWW-Authenticate:
               Remote-Passphrase
               Realm="realm in use",
               State="Authenticated",
               Session-Key="base64 encoding of session key",
               Response="base64 encoding of response"


G Brown                                                         [Page 6]

INTERNET-DRAFT             RPA - Part Three             15 November 1996

   
   The "Authenticated" state indicates that the user was successfully 
   authenticated, and includes the session key, masked so only the user 
   can extract it (Kusu), and the authentication deity's proof of the 
   service's identity (Au, not Rs). The realm is ignorable, but should 
   indicate the realm in which the identity was authenticated. 

   
2.2 Reauthentication cheating 
   
   In subsequent requests, the client tries to cheat by including an 
   Authorization header in its request: 
   
       Authorization:
               Remote-Passphrase
               State="Cheating",
               Security-Context="opaque",
               Response="base64 encoding of response"
   
   where the response is calculated based on the previously agreed-upon 
   values plus the canonicalized method and URI of this request as 
   explained in part two of this specification
   (draft-petke-mech-00.txt).
   
        [The HTTP specification suggests that clients be allowed to 
        replay the previous Authorization header, but it includes 
        an escape clause--"for a period of time determined by the 
        authentication scheme"--so we simply declare that period of 
        time to be zero.] 
   
   If the server is willing to accept the use of reauthentication 
   cheating, and the response is correct, the server processes the 
   request without comment. If it recognizes the security context but is 
   not willing to cheat--e.g., it recognizes a replay--the server 
   demands reauthentication. If it does not recognize the security 
   context or if it recognizes the context but the client's response is 
   incorrect, the server demands authentication but does not delete the 
   existing security context. 
   
        [Perhaps the user is referring to a security context that 
        has expired because it's been a long time since the user 
        last referred to it. And this can happen legitimately, if 
        the user refers to an expired security context and the 
        server reuses context identifiers. We do not delete an 
        existing context because that would provide a way for an 
        attacker to delete security contexts.] 
   
   In either of these cases, the server responds 401 Unauthorized and 
   includes the appropriate WWW-Authenticate header. To require 
   authentication, refer to the preceding section; to require 
   reauthentication, refer to the next section. 


G Brown                                                         [Page 7]

INTERNET-DRAFT             RPA - Part Three             15 November 1996

   
2.3 Reauthentication 
   
   If the server chooses to require reauthentication, it replies 401 
   Unauthorized and includes the header 
   
       WWW-Authenticate:
               Remote-Passphrase
               Realm="realm in use",
               State="Reauthenticate",
               Challenge="base64 encoding of service challenge"
   
   The client retries the request with an Authorization field: 
   
       Authorization:
               Remote-Passphrase
               State="Reauthenticate",
               Security-Context="opaque",
               Challenge="base64 encoding of user challenge",
               Response="base64 encoding of response"
   
   If the response is correct--the user has proven his knowledge of the 
   previously generated Kus for this context--the server processes the 
   request and includes in its reply: 
   
       WWW-Authenticate:
               Remote-Passphrase
               Realm="realm in use",
               State="Reauthenticated",
               Response="base64 encoding of response"

   The past-tense state indicates successful reauthentication, and 
   includes the server's response; this response is of debatable 
   relevance to HTTP, of course, given that the client's use of 
   reauthentication cheating implies its willingness to trust that the 
   server's identity has not changed. 
   
   If the client's response is incorrect, the server does not process 
   the request. However, there's a possibility that the client attempted 
   to do reauthentication with an old security context identifier that 
   has been reused by the server. Although the server should avoid 
   reusing security context identifiers, it can attempt to avert the 
   problem by forcing authentication by responding 401 Unauthorized and 
   including the header described above under Authentication. 
   

3. Security Considerations 
   
   This entire document is about security. 
   

G Brown                                                         [Page 8]

INTERNET-DRAFT             RPA - Part Three             15 November 1996


4. Author's Address 
   
   Gary S. Brown
   CompuServe Incorporated
   5000 Britton Rd
   P.O. Box 5000
   Hilliard OH 43026-5000
   USA
   
   +1 614 723 1127
   <gsb@csi.compuserve.com>


G Brown                                                         [Page 9]


1
2
3	INTERNET-DRAFT G Brown
4	draft-petke-http-auth-scheme-00.txt CompuServe
5	Expires: 15-May-97 15 November 1996
6
7
8	Remote Passphrase Authentication
9	Part Three: HTTP Authentication Scheme
10
11
12	Status of this Memo
13
14	This document is an Internet-Draft. Internet-Drafts are working
15	documents of the Internet Engineering Task Force (IETF), its
16	areas, and its working groups. Note that other groups may also
17	distribute working documents as Internet-Drafts.
18
19	Internet-Drafts are draft documents valid for a maximum of six
20	months and may be updated, replaced, or obsoleted by other
21	documents at any time. It is inappropriate to use Internet-
22	Drafts as reference material or to cite them other than as
23	"work in progress."
24
25	To learn the current status of any Internet-Draft, please check
26	the "1id-abstracts.txt" listing contained in the Internet-
27	Drafts Shadow Directories on ftp.is.co.za (Africa),
28	nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
29	ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
30
31
32	Abstract
33
34	Remote Passphrase Authentication provides a way to authenticate a
35	user to a service by using a pass phrase over an insecure network,
36	without revealing the pass phrase to eavesdroppers. In addition, the
37	service need not know and does not learn the user's pass phrase,
38	making this scheme useful in distributed environments where it would
39	be difficult or inappropriate to trust a service with a pass phrase
40	database or to allow the server to learn enough to masquerade as the
41	user in a future authentication attempt.
42
43	This draft is part three of a four part series and explains how to
44	incorporate the RPA mechanism into HTTP. Part one of this series
45	(draft-petke-ext-intro-00.txt) provides an extended introduction to
46	the problems of authentication over insecure networks. Part two
47	(draft-petke-mech-00.txt) explains the RPA mechanism. Part four
48	(draft-petke-serv-deity-protocol-00.txt) explains the protocol
49	between the service and deity.
50
51	This scheme was inspired by Dave Raggett's Mediated Digest
52	Authentication paper.
53
54
55
56
57
58	G Brown [Page 1]
59
60	INTERNET-DRAFT RPA - Part Three 15 November 1996
61
62
63	Table of Contents
64
65	1. INTRODUCTION
66
67	2. USING THIS AUTHENTICATION MECHANISM IN HTTP
68	2.1 AUTHENTICATION
69	2.2 REAUTHENTICATION CHEATING
70	2.3 REAUTHENTICATION
71
72	3. SECURITY CONSIDERATIONS
73
74	4. AUTHOR'S ADDRESS
75
76
77	1. Introduction
78
79	See part two of this series (draft-petke-mech-00.txt) for an
80	explanation of the mechanism, its motivation, and its
81	specification. This part describes only the HTTP encapsulation of the
82	mechanism.
83
84
85	2. Using this authentication mechanism in HTTP
86
87	The HTTP client may indicate that it supports this authentication
88	mechanism by whatever technique is appropriate.
89
90	[For example, a header like "Extension:
91	Security/Remote-Passphrase" might be appropriate, if that
92	extension mechanism is adopted. The extension mechanism is,
93	of course, independent of authentication, but we mention it
94	here to point out the issue. Theoretically, the server does
95	not need to know ahead of time whether the client supports
96	a particular authentication scheme.]
97
98	We begin by defining a security context, which represents a logical
99	connection between a user and Web server. Because the context spans
100	HTTP connections, the server assigns a security context identifier,
101	an opaque string, when it creates a context, and it informs the
102	client of its value in the Security-Context attribute of the
103	WWW-Authenticate header. The client includes the identifier in the
104	Authorization header of subsequent requests that refer to the same
105	context.
106
107	From the client's point of view, the pair (server IP address,
108	security context identifier) uniquely identifies a context; the same
109	is essentially true for the server, although a server can make its
110	security context identifiers unique, rather than (client IP address,
111	identifier) pairs.
112
113
114
115	G Brown [Page 2]
116
117	INTERNET-DRAFT RPA - Part Three 15 November 1996
118
119
120	Note that a client might refer to the same security context from
121	different IP addresses, if he switches proxies (is that possible?).
122	Note also that the client IP address alone is not adequate to
123	identify the security context. A multiple-user host, an HTTP proxy,
124	and a SOCKS server are examples of situations in which the same IP
125	address may be involved in many security contexts. And even an
126	individual PC running two browsers falls into this category--if I
127	connect to you from both browsers, I'll establish two security
128	contexts, which might or might not refer to the same user identity.
129
130	The server should assign security context identifiers that are unique
131	over time. If the client refers to an old context identifier--the
132	user returns to his PC tomorrow morning and clicks a link that was
133	displayed yesterday--it will do no harm if that identifier had been
134	reused, but the server won't be able to recognize it as such.
135
136	The security context "contains" information appropriate to the
137	context, such as the realm name, user and service names, session key,
138	challenges, state, etc. We'll gloss over the details in this
139	explanation. Note that a session using this mechanism is secure;
140	unlike other "cookie"-type mechanisms, we do not depend on the
141	secrecy of the context identifier. However, the content of requests
142	and responses is not authenticated, in this version of the protocol.
143
144	We define the authentication scheme name "Remote-Passphrase", used as
145	described below. The client begins by making a request for which the
146	server requires identification and authentication; because there is
147	no Authorization header in the request, the server will demand
148	authentication.
149
150	All WWW-Authenticate and Authorization headers used with this scheme
151	may include a Version attribute. When omitted, as in the examples
152	below, Version="1" is implied, for this version of the protocol.
153
154
155	2.1 Authentication
156
157	The server creates a new security context, assigns it an identifier,
158	and responds 401 Unauthorized and includes the header
159
160	WWW-Authenticate:
161	Remote-Passphrase
162	Realm="compuserve.com",
163	State="Initial",
164	Realms="foo@compuserve.com
165	bar@aol.com:iso-8859-1,lc,md5",
166	Challenge="base64 encoding of service challenge",
167	Timestamp="19950808132430",
168	Security-Context="opaque"
169
170
171
172	G Brown [Page 3]
173
174	INTERNET-DRAFT RPA - Part Three 15 November 1996
175
176
177	The first token specifies the authentication scheme,
178	Remote-Passphrase. That's followed by a comma-separated list of
179	attribute-value pairs. HTTP requires the first attribute to be called
180	"Realm" and specify the realm in which the user must indicate his
181	identity, but we support multiple realms, so this is merely one realm
182	acceptable to the server, perhaps its preferred realm.
183
184	The State attribute distinguishes this as the initial request for
185	authentication.
186
187	The Realms attribute provides a list of realms in the order preferred
188	by the server, with the server's name in each realm. Each may be
189	followed by a colon and a list of parameters separated by commas, to
190	drive the transformation from pass phrase to 128-bit shared secret
191	for that particular realm. Refer to part two of this specification
192	(draft-petke-mech-00.txt) for more information about the
193	transformation.
194
195	The default transformation, if the colon and parameters are omitted,
196	is specified in part two of this specification
197	(draft-petke-mech-00.txt), the Unicode character set in
198	big-endian ("network") byte order, with all characters converted to
199	lowercase, and the MD5 hash algorithm.
200
201	Otherwise, a single parameter, "none", implies that the client must
202	already possess a 128-bit value, and no transformation from a textual
203	pass phrase is defined.
204
205	Otherwise, three parameters control the transformation from a textual
206	pass phrase to the 128-bit shared secret used by the authentication
207	mechanism, if such a transformation takes place (it might not, if the
208	client believes it already knows a 128-bit value for this user). The
209	three parameters specify the character set: Unicode 1.1
210	("unicode-1-1") or ISO 8859-1 ("iso-8859-1"); case conversion:
211	convert to all caps ("uc"), all lowercase ("lc"), or as-is with no
212	case conversion ("nc"); and hash function: MD5 ("md5"). Omitting the
213	colon and parameters is equivalent to specifying
214	"unicode-1-1,lc,md5".
215
216	[There's no need for US-ASCII as a character set, because
217	ISO 8859-1 will give the same results. Note that these
218	parameters are part of the base authentication mechanism
219	specification; only the means of conveying them, and the
220	textual names shown above, are specific to this HTTP
221	authentication scheme. Other variations can be added, but
222	they must be added to the authentication mechanism defined
223	by part two of this specification
224	(draft-petke-mech-00.txt) as well as here in part three.]
225
226
227
228
229	G Brown [Page 4]
230
231	INTERNET-DRAFT RPA - Part Three 15 November 1996
232
233
234	We convey this information to the client because there's no reason
235	the client would otherwise know whether a particular realm's pass
236	phrases are case sensitive, etc. The server, on the other hand,
237	simply must "know" how its particular realm uses pass phrases; these
238	characteristics are a part of server's configuration along with its
239	name in the realm, deity addresses, etc.
240
241	The Challenge attribute specifies the service's challenge. It is an
242	arbitrarily long sequence of octets containing arbitrary bit
243	patterns, represented in base64. The client must decode it before
244	using it in the authentication calculations; it might contain nulls
245	or any other bit patterns. The client may decline to trust the server
246	and abort at this point, if it deems the challenge to be too short.
247
248	The Timestamp attribute specifies the server's timestamp. This is a
249	UTC date and time in the format specified by the authentication
250	standard. It may be treated as an opaque string by the client, unless
251	the client chooses to interpret it to make a judgment about its
252	reality; but beware that you probably don't have a reliable source of
253	universal time.
254
255	The Security-Context attribute contains the server-assigned security
256	context identifier, an opaque string.
257
258	The client creates its security context and repeats the request with
259	an Authorization header:
260
261	Authorization:
262	Remote-Passphrase
263	State="Initial",
264	Security-Context="opaque",
265	Realm="compuserve.com",
266	Username="70003.1215",
267	Challenge="base64 encoding of user challenge",
268	Response="base64 encoding of response"
269
270	The first token specifies the authorization scheme. That's followed
271	by the state, "Initial" for the initial authentication; the security
272	context identifier; the realm chosen by the user; the user's identity
273	in that realm; the user's challenge; and the user's response.
274
275	The service looks up the security context. If the security context
276	identifier refers to no context or refers to a context that is
277	already established, the server creates a new security context with a
278	new identifier, then responds 401 Unauthorized and includes a fresh
279	WWW-Authenticate header as shown above, with which the client can
280	repeat the request with correct authentication information.
281
282	[Or does this risk a loop? We could just respond with an
283	error.]
284
285
286	G Brown [Page 5]
287
288	INTERNET-DRAFT RPA - Part Three 15 November 1996
289
290
291	Any existing security context is unaffected; if I send you a request
292	that specifies someone else's security context, you should not delete
293	his context.
294
295	Otherwise--the context identifier is recognized and that context is
296	in the awaiting authentication state--the server performs the
297	authentication process.
298
299	The server may verify that the client's IP address matches that in
300	the previous request that created the "pending" context. The only
301	risk is that someone might change proxies at whim, which seems
302	unlikely.
303
304	If the authentication process fails, the server refuses to process
305	the request, but does not delete the "pending" security context. It
306	generates a 401 Unauthorized response with a WWW-Authenticate header
307	that indicates failure:
308
309	WWW-Authenticate:
310	Remote-Passphrase
311	Realm="nonsense",
312	State="Failed"
313
314	It is up to the client to try the request again (without an
315	Authorization header), restarting the entire process, if it believes
316	that it was using the wrong pass phrase but it now has the right pass
317	phrase.
318
319	[Sending another "Initial" WWW-Authenticate header would
320	provoke a loop: the browser would calculate a new response
321	and retry the request, which is pointless if the browser's
322	idea of the pass phrase is wrong, so we indicate the
323	failure.]
324
325	[One could argue that the browser should forget whichever
326	cached pass phrase it used, in order to prompt for it again
327	if the user tries to next time. But the pass phrase might
328	have been correct, depending on what exactly went wrong at
329	the server.]
330
331	Otherwise, having successfully authenticated the user, the server
332	processes the client's request and returns an appropriate response,
333	including in its reply:
334
335	WWW-Authenticate:
336	Remote-Passphrase
337	Realm="realm in use",
338	State="Authenticated",
339	Session-Key="base64 encoding of session key",
340	Response="base64 encoding of response"
341
342
343	G Brown [Page 6]
344
345	INTERNET-DRAFT RPA - Part Three 15 November 1996
346
347
348	The "Authenticated" state indicates that the user was successfully
349	authenticated, and includes the session key, masked so only the user
350	can extract it (Kusu), and the authentication deity's proof of the
351	service's identity (Au, not Rs). The realm is ignorable, but should
352	indicate the realm in which the identity was authenticated.
353
354
355	2.2 Reauthentication cheating
356
357	In subsequent requests, the client tries to cheat by including an
358	Authorization header in its request:
359
360	Authorization:
361	Remote-Passphrase
362	State="Cheating",
363	Security-Context="opaque",
364	Response="base64 encoding of response"
365
366	where the response is calculated based on the previously agreed-upon
367	values plus the canonicalized method and URI of this request as
368	explained in part two of this specification
369	(draft-petke-mech-00.txt).
370
371	[The HTTP specification suggests that clients be allowed to
372	replay the previous Authorization header, but it includes
373	an escape clause--"for a period of time determined by the
374	authentication scheme"--so we simply declare that period of
375	time to be zero.]
376
377	If the server is willing to accept the use of reauthentication
378	cheating, and the response is correct, the server processes the
379	request without comment. If it recognizes the security context but is
380	not willing to cheat--e.g., it recognizes a replay--the server
381	demands reauthentication. If it does not recognize the security
382	context or if it recognizes the context but the client's response is
383	incorrect, the server demands authentication but does not delete the
384	existing security context.
385
386	[Perhaps the user is referring to a security context that
387	has expired because it's been a long time since the user
388	last referred to it. And this can happen legitimately, if
389	the user refers to an expired security context and the
390	server reuses context identifiers. We do not delete an
391	existing context because that would provide a way for an
392	attacker to delete security contexts.]
393
394	In either of these cases, the server responds 401 Unauthorized and
395	includes the appropriate WWW-Authenticate header. To require
396	authentication, refer to the preceding section; to require
397	reauthentication, refer to the next section.
398
399
400	G Brown [Page 7]
401
402	INTERNET-DRAFT RPA - Part Three 15 November 1996
403
404
405	2.3 Reauthentication
406
407	If the server chooses to require reauthentication, it replies 401
408	Unauthorized and includes the header
409
410	WWW-Authenticate:
411	Remote-Passphrase
412	Realm="realm in use",
413	State="Reauthenticate",
414	Challenge="base64 encoding of service challenge"
415
416	The client retries the request with an Authorization field:
417
418	Authorization:
419	Remote-Passphrase
420	State="Reauthenticate",
421	Security-Context="opaque",
422	Challenge="base64 encoding of user challenge",
423	Response="base64 encoding of response"
424
425	If the response is correct--the user has proven his knowledge of the
426	previously generated Kus for this context--the server processes the
427	request and includes in its reply:
428
429	WWW-Authenticate:
430	Remote-Passphrase
431	Realm="realm in use",
432	State="Reauthenticated",
433	Response="base64 encoding of response"
434
435	The past-tense state indicates successful reauthentication, and
436	includes the server's response; this response is of debatable
437	relevance to HTTP, of course, given that the client's use of
438	reauthentication cheating implies its willingness to trust that the
439	server's identity has not changed.
440
441	If the client's response is incorrect, the server does not process
442	the request. However, there's a possibility that the client attempted
443	to do reauthentication with an old security context identifier that
444	has been reused by the server. Although the server should avoid
445	reusing security context identifiers, it can attempt to avert the
446	problem by forcing authentication by responding 401 Unauthorized and
447	including the header described above under Authentication.
448
449
450	3. Security Considerations
451
452	This entire document is about security.
453
454
455
456
457	G Brown [Page 8]
458
459	INTERNET-DRAFT RPA - Part Three 15 November 1996
460
461
462	4. Author's Address
463
464	Gary S. Brown
465	CompuServe Incorporated
466	5000 Britton Rd
467	P.O. Box 5000
468	Hilliard OH 43026-5000
469	USA
470
471	+1 614 723 1127
472	<gsb@csi.compuserve.com>
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514	G Brown [Page 9]
515
516