2004/id/draft-ietf-http-digest-aa-02.txt


HTTP Working Group                                  Jeffery L. Hostetler
INTERNET-DRAFT                                               John Franks
<draft-ietf-http-digest-aa-02.txt>                   Philip Hallam-Baker
                                                            Ari Luotonen
                                                            Eric W. Sink
                                                     Lawrence C. Stewart
Expires SIX MONTHS FROM--->                            December 20, 1995

      A Proposed Extension to HTTP : Digest Access Authentication

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 ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   Distribution of this document is unlimited. Please send comments
   to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
   Discussions of the working group are archived at
   <URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
   about HTTP and the applications which use HTTP should take place
   on the <www-talk@info.cern.ch> mailing list.

Abstract

   The protocol referred to as "HTTP/1.0" includes specification
   for a Basic Access Authentication scheme.  This scheme is not
   considered to be a secure method of user authentication, as the
   user name and password are passed over the network in an
   unencrypted form.  A specification for a new authentication scheme
   is needed for future versions of the HTTP protocol.  This document
   provides specification for such a scheme, referred to as "Digest
   Access Authentication".  The encryption method used is the RSA Data
   Security, Inc. MD5 Message-Digest Algorithm [3].

Table of Contents

   1.  Introduction
       1.1  Purpose
       1.2  Overall Operation
       1.3  Representation of MD5 digest values
   2.  Basic Access Authentication Scheme
       2.1  Specification
       2.2  Security protocol negotiation
       2.3  Example
   3.  Acknowledgments
   4.  References
   5.  Authors Addresses


1. Introduction

1.1  Purpose

   The protocol referred to as "HTTP/1.0" includes specification
   for a Basic Access Authentication scheme[1].  This scheme is not
   considered to be a secure method of user authentication, as the
   user name and password are passed over the network in an
   unencrypted form.  A specification for a new authentication scheme
   is needed for future versions of the HTTP protocol.  This document
   provides specification for such a scheme, referred to as "Digest
   Access Authentication".

   The Digest Access Authentication scheme is not intended to be
   a complete answer to the need for security in the World Wide Web.
   This scheme provides no encryption of object content.  The intent
   is simply to facilitate secure access authentication.

   It is proposed that this access authentication scheme be included
   in the proposed HTTP/1.1 specification.

1.2  Overall Operation

   Like Basic Access Authentication, the Digest scheme is based on
   a simple challenge-response paradigm.  The Digest scheme challenges
   using a nonce value.  A valid response contains the MD5 checksum of
   the password and the given nonce value.  In this way, the password
   is never sent in the clear.  Just as with the Basic scheme, the
   username and password must be prearranged in some fashion.

1.3  Representation of MD5 digest values

   For the purposes of this document, an MD5 digest of 128 bits
   is represented as 32 ASCII printable characters.  The bits
   in the 128 bit digest are converted from most significant
   to least significant bit, four bits at a time to their
   ASCII presentation as follows.  Each four bits is
   represented by its familiar hexadecimal notation from the
   characters 0123456789abcdef.  That is binary 0000 gets
   represented by the character '0', 0001, by '1', and so on
   up to the representation of 1111 as 'f'.

2. Digest Access Authentication Scheme

2.1 Specification

   The Digest Access Authentication scheme is conceptually similar to the Basic
   scheme.  The formats of the modified WWW-Authenticate header line and the
   Authorization header line are specified below.  In addition, a new header,
   Digest-MessageDigest, is specified as well.

   Due to formatting constraints, all of the headers are depicted here
   on multiple lines.  In actual usage, they must follow the syntactic
   rules for HTTP/1.0 header lines [1].  Whitespace between the
   attribute-value pairs is allowed.

   If a server receives a request for an access-protected object, and an
   acceptable Authorizatation header is not sent, the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="<realm>",
                            domain="<domain>",
                            nonce="<nonce>",
                            opaque="<opaque>",
                            stale="<TRUE | FALSE>"


   The meanings of the identifers used above are as follows:

      <realm>
         A name given to users so they know which username and password
         to send.

      <domain>  OPTIONAL
         A comma separated list of URIs, as specified for HTTP/1.0.  The
         intent is that the client could use this information to know the
         set of URIs for which the same authentication information should be
         sent.  The URIs in this list may exist on different servers.  If
         this keyword is omitted or empty, the client should assume that
         the domain consists of all URIs on the responding server.

      <nonce>
         A server-specified integer value which may be uniquely generated each
         time a 401 response is made.  Servers may defend themselves against
         replay attacks by refusing to reuse nonce values.  The nonce should be
         considered opqaue by the client.

      <opaque>  OPTIONAL
         A string of data, specified by the server, which should returned by
         the client unchanged.  It is recommended that this string be
         base64 or hexadecimal data.  Specifically, since the string is passed
         in the header lines as a quoted string, the double-quote character
         is not allowed.

      <stale>   OPTIONAL
         A flag, indicating that the previous request from the client
         was rejected because the nonce value was stale.  If stale
         is TRUE, the client may wish to simply retry the request with
         a new encrypted response, without reprompting the user for a
         new username and password.


   The client is expected to retry the request, passing an Authorization header
   line as follows:

Authorization: Digest
           username="<username>",             -- required
           realm="<realm>",                   -- required
           nonce="<nonce>",                   -- required
           uri="<requested-uri>",             -- required
           response="<digest>",               -- required
           message="<message-digest>",        -- OPTIONAL
           opaque="<opaque>"                  -- required if provided by server

        where <digest> := H( H(A1) + ":" + N + ":" + H(A2) )
  and <message-digest> := H( H(A1) + ":" + N + ":" + H(<message-body>) )

        where:

                A1 := U + ':' + R + ':' + P
                A2 := <Method> + ':' + <requested-uri>

                with:
                        N -- nonce value
                        U -- username
                        R -- realm
                        P -- password
                        <Method> -- from header line 0
                        <requested-uri> -- uri sans proxy/routing

    When authorization succeeds, the Server may optionally provide the
    following:

HTTP/1.1 200 OK
Digest-MessageDigest:
              username="<username>",
              realm="<realm>",
              nonce="<nonce>",
              message="<message-digest>"

        The Digest-MessageDigest header indicates that the server wants to
        communicate some info regarding the successful
        authentication (such as a message digest or a
        receipt of some kind).

        <message-digest> is computed as given above for
        the client.  this allows the client to verify that
        the message body has not been changed en-route.

        (The server would probably only send this when it
         has the document and can compute it (like the
         content-length field); the server would probably
         not bother generating this header for CGI output.)


   Upon receiving the Authorization information, the server may check its
   validity by looking up its known password which corresponds to the submitted
   <username>.  Then, the server must perform the same MD5 operation performed
   by the client, and compare the result to the given <response>.

   Note that the HTTP server does not actually need to know the user's
   clear text password.  As long as H(A1) is available to the server, the
   validity of an Authorization header may be verified.

   All keyword-value pairs must be expressed in characters from the
   US-ASCII character set, excluding control characters.

   A client may remember the username, password and nonce values, so that
   future requests within the specified <domain> may include the Authorization
   line preemptively.  The server may choose to accept the old Authorization
   information, even though the nonce value included might not be fresh.
   Alternatively, the server could return a 401 response with a new nonce
   value, causing the client to retry the request.  By specifying stale=TRUE
   with this response, the server hints to the client that the request should
   be retried with the new nonce, without reprompting the user for a new
   username and password.

   The <opaque> data is useful for transporting state information around.
   For example, a server could be responsible for authenticating content
   which actual sits on another server.  The first 401 response would include
   a <domain> which includes the URI on the second server, and the <opaque>
   for specifying state information.  The client will retry the request, at
   which time the server may respond with a 301/302 redirection, pointing
   to the URI on the second server.  The client will follow the redirection,
   and pass the same Authorization line, including the <opaque> data which
   the second server may require.

   As with the basic scheme, proxies must be completely transparent in
   the Digest access authentication scheme. That is, they must forward the
   WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched.
   If a proxy wants to authenticate a client before a request is forwarded to
   the server, it can be done using the Proxy-Authenticate and
   Proxy-Authorization headers.

2.2 Security Protocol Negotiation

   It is useful for a server to be able to know which security schemes
   a client is capable of handling.  It is recommended that the HTTP extension
   mechanism proposed by Dave Kristol [2] be used.  If the client includes
   the following header line with the request, then a server can safely assume
   that the client can handle Digest authentication.

Extension: Security/Digest

   If this proposal is accepted as a required part of the HTTP/1.1
   specification, then a server may assume Digest support when a client
   identifies itself as HTTP/1.1 compliant.

   It is possible that a server may want to require Digest as its
   authentication method, even if the server does not know that the client
   supports it.  A client is encouraged to fail gracefully if the server
   specifies any authentication scheme it cannot handle.

2.3 Example

   The following example assumes that an access-protected document is being
   requested from the server.  The URI of the document is
   "http://www.nowhere.org/simp/".

   Both client and server know that the username for this document is "eric",
   and the password is "spyglass".

   The first time the client requests the document, no Authorization header
   is sent, so the server responds with:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest    realm="testrealm",
                            nonce="72540723369",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"

   The client may prompt the user for the username and password, after which it
   will respond with a new request, including the following Authorization
header:

Authorization: Digest       username="eric",
                            realm="testrealm",
                            nonce="72540723369",
                            uri="/simp/",
                            response="e966c932a9242554e42c8ee200cec7f6",
                            opaque="5ccc069c403ebaf9f0171e9517f40e41"

3. References

   [1]  T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
        "Hypertext Transfer Protocol -- HTTP/1.0"
        Internet-Draft (work in progress), UC Irvine,
        <URL:http://ds.internic.net/internet-drafts/
        draft-ietf-http-v10-spec-00.txt>, March 1995.

   [2]  D. Kristol. "A Proposed Extension Mechanism for HTTP"
        <URL:http://ds.internic.net/internet-drafts/
        draft-kristol-http-extensions-00.txt>,
        December 1994.

   [3]  RFC 1321.  R.Rivest, "The MD5 Message-Digest Algorithm",
        <URL:http://ds.internic.net/rfc/rfc1321.txt>,
        April 1992.

4. Authors Addresses

   John Franks
   john@math.nwu.edu
   Professor of Mathematics
   Department of Mathematics
   Northwestern University
   Evanston, IL 60208-2730, USA

   Phillip M. Hallam-Baker
   hallam@w3.org
   European Union Fellow
   CERN
   Geneva
   Switzerland

   Jeffery L. Hostetler
   jeff@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   3200 Farber Drive
   Champaign, IL  61821, USA

   Ari Luotonen
   luotonen@netscape.com
   Member of Technical Staff
   Netscape Communications Corporation
   501 East Middlefield Road
   Mountain View, CA 94043, USA

   Eric W. Sink
   eric@spyglass.com
   Senior Software Engineer
   Spyglass, Inc.
   3200 Farber Drive
   Champaign, IL  61821, USA

   Lawrence C. Stewart
   stewart@OpenMarket.com
   Open Market, Inc.
   215 First Street
   Cambridge, MA  02142, USA


--
Eric W. Sink
eric@spyglass.com

1
2	HTTP Working Group Jeffery L. Hostetler
3	INTERNET-DRAFT John Franks
4	<draft-ietf-http-digest-aa-02.txt> Philip Hallam-Baker
5	Ari Luotonen
6	Eric W. Sink
7	Lawrence C. Stewart
8	Expires SIX MONTHS FROM---> December 20, 1995
9
10	A Proposed Extension to HTTP : Digest Access Authentication
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 areas,
16	and its working groups. Note that other groups may also distribute
17	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 ds.internic.net (US East Coast),
28	nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
29	munnari.oz.au (Pacific Rim).
30
31	Distribution of this document is unlimited. Please send comments
32	to the proposed HTTP working group at <http-wg@cuckoo.hpl.hp.com>.
33	Discussions of the working group are archived at
34	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
35	about HTTP and the applications which use HTTP should take place
36	on the <www-talk@info.cern.ch> mailing list.
37
38	Abstract
39
40	The protocol referred to as "HTTP/1.0" includes specification
41	for a Basic Access Authentication scheme. This scheme is not
42	considered to be a secure method of user authentication, as the
43	user name and password are passed over the network in an
44	unencrypted form. A specification for a new authentication scheme
45	is needed for future versions of the HTTP protocol. This document
46	provides specification for such a scheme, referred to as "Digest
47	Access Authentication". The encryption method used is the RSA Data
48	Security, Inc. MD5 Message-Digest Algorithm [3].
49
50	Table of Contents
51
52	1. Introduction
53	1.1 Purpose
54	1.2 Overall Operation
55	1.3 Representation of MD5 digest values
56	2. Basic Access Authentication Scheme
57	2.1 Specification
58	2.2 Security protocol negotiation
59	2.3 Example
60	3. Acknowledgments
61	4. References
62	5. Authors Addresses
63
64
65	1. Introduction
66
67	1.1 Purpose
68
69	The protocol referred to as "HTTP/1.0" includes specification
70	for a Basic Access Authentication scheme[1]. This scheme is not
71	considered to be a secure method of user authentication, as the
72	user name and password are passed over the network in an
73	unencrypted form. A specification for a new authentication scheme
74	is needed for future versions of the HTTP protocol. This document
75	provides specification for such a scheme, referred to as "Digest
76	Access Authentication".
77
78	The Digest Access Authentication scheme is not intended to be
79	a complete answer to the need for security in the World Wide Web.
80	This scheme provides no encryption of object content. The intent
81	is simply to facilitate secure access authentication.
82
83	It is proposed that this access authentication scheme be included
84	in the proposed HTTP/1.1 specification.
85
86	1.2 Overall Operation
87
88	Like Basic Access Authentication, the Digest scheme is based on
89	a simple challenge-response paradigm. The Digest scheme challenges
90	using a nonce value. A valid response contains the MD5 checksum of
91	the password and the given nonce value. In this way, the password
92	is never sent in the clear. Just as with the Basic scheme, the
93	username and password must be prearranged in some fashion.
94
95	1.3 Representation of MD5 digest values
96
97	For the purposes of this document, an MD5 digest of 128 bits
98	is represented as 32 ASCII printable characters. The bits
99	in the 128 bit digest are converted from most significant
100	to least significant bit, four bits at a time to their
101	ASCII presentation as follows. Each four bits is
102	represented by its familiar hexadecimal notation from the
103	characters 0123456789abcdef. That is binary 0000 gets
104	represented by the character '0', 0001, by '1', and so on
105	up to the representation of 1111 as 'f'.
106
107	2. Digest Access Authentication Scheme
108
109	2.1 Specification
110
111	The Digest Access Authentication scheme is conceptually similar to the Basic
112	scheme. The formats of the modified WWW-Authenticate header line and the
113	Authorization header line are specified below. In addition, a new header,
114	Digest-MessageDigest, is specified as well.
115
116	Due to formatting constraints, all of the headers are depicted here
117	on multiple lines. In actual usage, they must follow the syntactic
118	rules for HTTP/1.0 header lines [1]. Whitespace between the
119	attribute-value pairs is allowed.
120
121	If a server receives a request for an access-protected object, and an
122	acceptable Authorizatation header is not sent, the server responds with:
123
124	HTTP/1.1 401 Unauthorized
125	WWW-Authenticate: Digest realm="<realm>",
126	domain="<domain>",
127	nonce="<nonce>",
128	opaque="<opaque>",
129	stale="<TRUE \| FALSE>"
130
131
132
133	The meanings of the identifers used above are as follows:
134
135	<realm>
136	A name given to users so they know which username and password
137	to send.
138
139	<domain> OPTIONAL
140	A comma separated list of URIs, as specified for HTTP/1.0. The
141	intent is that the client could use this information to know the
142	set of URIs for which the same authentication information should be
143	sent. The URIs in this list may exist on different servers. If
144	this keyword is omitted or empty, the client should assume that
145	the domain consists of all URIs on the responding server.
146
147	<nonce>
148	A server-specified integer value which may be uniquely generated each
149	time a 401 response is made. Servers may defend themselves against
150	replay attacks by refusing to reuse nonce values. The nonce should be
151	considered opqaue by the client.
152
153	<opaque> OPTIONAL
154	A string of data, specified by the server, which should returned by
155	the client unchanged. It is recommended that this string be
156	base64 or hexadecimal data. Specifically, since the string is passed
157	in the header lines as a quoted string, the double-quote character
158	is not allowed.
159
160	<stale> OPTIONAL
161	A flag, indicating that the previous request from the client
162	was rejected because the nonce value was stale. If stale
163	is TRUE, the client may wish to simply retry the request with
164	a new encrypted response, without reprompting the user for a
165	new username and password.
166
167
168	The client is expected to retry the request, passing an Authorization header
169	line as follows:
170
171	Authorization: Digest
172	username="<username>", -- required
173	realm="<realm>", -- required
174	nonce="<nonce>", -- required
175	uri="<requested-uri>", -- required
176	response="<digest>", -- required
177	message="<message-digest>", -- OPTIONAL
178	opaque="<opaque>" -- required if provided by server
179
180	where <digest> := H( H(A1) + ":" + N + ":" + H(A2) )
181	and <message-digest> := H( H(A1) + ":" + N + ":" + H(<message-body>) )
182
183	where:
184
185	A1 := U + ':' + R + ':' + P
186	A2 := <Method> + ':' + <requested-uri>
187
188	with:
189	N -- nonce value
190	U -- username
191	R -- realm
192	P -- password
193	<Method> -- from header line 0
194	<requested-uri> -- uri sans proxy/routing
195
196	When authorization succeeds, the Server may optionally provide the
197	following:
198
199	HTTP/1.1 200 OK
200	Digest-MessageDigest:
201	username="<username>",
202	realm="<realm>",
203	nonce="<nonce>",
204	message="<message-digest>"
205
206	The Digest-MessageDigest header indicates that the server wants to
207	communicate some info regarding the successful
208	authentication (such as a message digest or a
209	receipt of some kind).
210
211	<message-digest> is computed as given above for
212	the client. this allows the client to verify that
213	the message body has not been changed en-route.
214
215	(The server would probably only send this when it
216	has the document and can compute it (like the
217	content-length field); the server would probably
218	not bother generating this header for CGI output.)
219
220
221	Upon receiving the Authorization information, the server may check its
222	validity by looking up its known password which corresponds to the submitted
223	<username>. Then, the server must perform the same MD5 operation performed
224	by the client, and compare the result to the given <response>.
225
226	Note that the HTTP server does not actually need to know the user's
227	clear text password. As long as H(A1) is available to the server, the
228	validity of an Authorization header may be verified.
229
230	All keyword-value pairs must be expressed in characters from the
231	US-ASCII character set, excluding control characters.
232
233	A client may remember the username, password and nonce values, so that
234	future requests within the specified <domain> may include the Authorization
235	line preemptively. The server may choose to accept the old Authorization
236	information, even though the nonce value included might not be fresh.
237	Alternatively, the server could return a 401 response with a new nonce
238	value, causing the client to retry the request. By specifying stale=TRUE
239	with this response, the server hints to the client that the request should
240	be retried with the new nonce, without reprompting the user for a new
241	username and password.
242
243	The <opaque> data is useful for transporting state information around.
244	For example, a server could be responsible for authenticating content
245	which actual sits on another server. The first 401 response would include
246	a <domain> which includes the URI on the second server, and the <opaque>
247	for specifying state information. The client will retry the request, at
248	which time the server may respond with a 301/302 redirection, pointing
249	to the URI on the second server. The client will follow the redirection,
250	and pass the same Authorization line, including the <opaque> data which
251	the second server may require.
252
253	As with the basic scheme, proxies must be completely transparent in
254	the Digest access authentication scheme. That is, they must forward the
255	WWW-Authenticate, Digest-MessageDigest and Authorization headers untouched.
256	If a proxy wants to authenticate a client before a request is forwarded to
257	the server, it can be done using the Proxy-Authenticate and
258	Proxy-Authorization headers.
259
260	2.2 Security Protocol Negotiation
261
262	It is useful for a server to be able to know which security schemes
263	a client is capable of handling. It is recommended that the HTTP extension
264	mechanism proposed by Dave Kristol [2] be used. If the client includes
265	the following header line with the request, then a server can safely assume
266	that the client can handle Digest authentication.
267
268	Extension: Security/Digest
269
270	If this proposal is accepted as a required part of the HTTP/1.1
271	specification, then a server may assume Digest support when a client
272	identifies itself as HTTP/1.1 compliant.
273
274	It is possible that a server may want to require Digest as its
275	authentication method, even if the server does not know that the client
276	supports it. A client is encouraged to fail gracefully if the server
277	specifies any authentication scheme it cannot handle.
278
279	2.3 Example
280
281	The following example assumes that an access-protected document is being
282	requested from the server. The URI of the document is
283	"http://www.nowhere.org/simp/".
284
285	Both client and server know that the username for this document is "eric",
286	and the password is "spyglass".
287
288	The first time the client requests the document, no Authorization header
289	is sent, so the server responds with:
290
291	HTTP/1.1 401 Unauthorized
292	WWW-Authenticate: Digest realm="testrealm",
293	nonce="72540723369",
294	opaque="5ccc069c403ebaf9f0171e9517f40e41"
295
296	The client may prompt the user for the username and password, after which it
297	will respond with a new request, including the following Authorization
298	header:
299
300	Authorization: Digest username="eric",
301	realm="testrealm",
302	nonce="72540723369",
303	uri="/simp/",
304	response="e966c932a9242554e42c8ee200cec7f6",
305	opaque="5ccc069c403ebaf9f0171e9517f40e41"
306
307	3. References
308
309	[1] T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
310	"Hypertext Transfer Protocol -- HTTP/1.0"
311	Internet-Draft (work in progress), UC Irvine,
312	<URL:http://ds.internic.net/internet-drafts/
313	draft-ietf-http-v10-spec-00.txt>, March 1995.
314
315	[2] D. Kristol. "A Proposed Extension Mechanism for HTTP"
316	<URL:http://ds.internic.net/internet-drafts/
317	draft-kristol-http-extensions-00.txt>,
318	December 1994.
319
320	[3] RFC 1321. R.Rivest, "The MD5 Message-Digest Algorithm",
321	<URL:http://ds.internic.net/rfc/rfc1321.txt>,
322	April 1992.
323
324	4. Authors Addresses
325
326	John Franks
327	john@math.nwu.edu
328	Professor of Mathematics
329	Department of Mathematics
330	Northwestern University
331	Evanston, IL 60208-2730, USA
332
333	Phillip M. Hallam-Baker
334	hallam@w3.org
335	European Union Fellow
336	CERN
337	Geneva
338	Switzerland
339
340	Jeffery L. Hostetler
341	jeff@spyglass.com
342	Senior Software Engineer
343	Spyglass, Inc.
344	3200 Farber Drive
345	Champaign, IL 61821, USA
346
347	Ari Luotonen
348	luotonen@netscape.com
349	Member of Technical Staff
350	Netscape Communications Corporation
351	501 East Middlefield Road
352	Mountain View, CA 94043, USA
353
354	Eric W. Sink
355	eric@spyglass.com
356	Senior Software Engineer
357	Spyglass, Inc.
358	3200 Farber Drive
359	Champaign, IL 61821, USA
360
361	Lawrence C. Stewart
362	stewart@OpenMarket.com
363	Open Market, Inc.
364	215 First Street
365	Cambridge, MA 02142, USA
366
367
368	--
369	Eric W. Sink
370	eric@spyglass.com
371