2004/id/draft-lawrence-digest-request-00.txt

INTERNET-DRAFT                                           Scott Lawrence
draft-lawrence-digest-request-00.txt              Agranat Systems, Inc.
Expires: December 1997                                    July 14, 1997


             HTTP/1.1 Message Digest Attribute Request

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).

1. Abstract

   This memo describes a security weakness in the current Proposed
   Standard for HTTP Digest Access Authentication, and proposes a
   change to that scheme to correct the deficiency.  The problem is
   that there is no mechanism for either party to indicate a
   requirement that messages be sent with an authentication digest.


draft-lawrence-digest-request-00.txt                            Page 2/4

2. The Problem

   The Digest Authentication scheme specifies a mechanism (the
   'digest' attribute of the Authentication-Info and Authorization
   header fields) by which a digest of the message body and selected
   headers may be transmitted.  This provides a valuable means of
   protecting the message body from modification or replay attacks
   based on modifying either the message body or the protected
   headers, while preserving the authentication headers.

   The mechanism is only valuable, however, if the message recipient
   can require that the digest attribute is present, but at present
   the authentication scheme does not provide a means to indicate that
   the digest is required.  There are two difficulties created by this
   lack, an interoperability problem and a security problem:

   - The interoperability problem is that if one party (either client
     or server) wishes to require a digest for a particular HTTP
     request or response, the other party cannot be told of the
     requirement.  This leaves us with the situation that in order for
     such a requirement to work that all messages using the Digest
     Authentication scheme would need to use the message digest, even
     those for which it would not be required.  Because computing the
     digest is relatively expensive, this is undesirable.

   - The security problem is that an attacker can remove the
     attribute, preserving the remainder of the authentication
     information, and modify the parts of the message the digest was
     meant to protect.

   For example, a server implementation might provide for a resource
   attribute to require that Digest Authentication be used and a
   message digest supplied in order to submit a form.  This would be
   used to ensure that forms could be defined for which the flimsy
   protections of Basic authentication are not appropriate.  The
   requirement that the Digest Authentication scheme be used can be
   communicated to the client by sending a WWW-Authenticate header
   with 'digest' as the only acceptable scheme, but no mechanism is
   provided to require the message digest.


draft-lawrence-digest-request-00.txt                            Page 3/4

3. Solution

   Attributes should be added to the WWW-Authenticate and
   Authorization headers to indicate that a message digest is required
   on the subsequent message.  The section numbers below refer to [RFC
   2069].

   Note that this draft does not propose that support for Digest
   Access Authentication become a requirement for HTTP/1.1
   conformance.  It does add a requirement to the definition of the
   scheme if it is supported at all.

   ================================================================
   in section 2.1.1:

     WWW-Authenticate    = "WWW-Authenticate" ":" "Digest"
                              digest-challenge

     digest-challenge    = 1#( realm | [ domain ] | nonce |
                          [ opaque ] |[ stale ] | [ algorithm ] |
                          [ digest-required ] )
   ...
     digest-required     = "digest-required"
   ...

   digest-required
   A flag, indicating that any request for the resource to which this
   response applies must include the 'digest' attribute in its
   Authorization header.

   ================================================================
   in section 2.1.2:

   Authorization       = "Authorization" ":" "Digest" digest-response

   digest-response     = 1#( username | realm | nonce | digest-uri |
                            response | [ digest ] | [ algorithm ] |
                            opaque | digest-required )

   ...
     digest-required     = "digest-required"
   ...

   digest-required
   A flag, indicating that the response to this request must include
   the 'digest' attribute in its Authentication-Info header.

   ================================================================

   in section 3.3, paragraph 4:

   The discussion of attacks based on removing the "digest" field of
   the Authentication-Info header can be removed; the remainder is
   still correct.


draft-lawrence-digest-request-00.txt                             Page 4/4

4. Security Considerations

   This entire draft is about security considerations.

5. Author's Addresses

   Scott Lawrence
      Agranat Systems, Inc.
      1345 Main St.
      Waltham, MA 02154
   Phone:  +1-617-893-7868
   Fax:    +1-617-893-5740
   Email:  lawrence@agranat.com

6. References

   [RFC 2068]
       R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee.
       "Hypertext Transfer Protocol -- HTTP/1.1."
       RFC 2068,
       U.C. Irvine, DEC, MIT/LCS,
       January 1997.

   [RFC 2069]
       J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach,
       A. Luotonen, E. Sink, and L. Stewart.
       "An Extension to HTTP : Digest Access Authentication"
       RFC 2069,
       Northwestern University, CERN, Spyglass Inc., Microsoft Corp.,
       Netscape Communications Corp., Spyglass Inc., Open Market Inc.,
       January 1997.


1	INTERNET-DRAFT Scott Lawrence
2	draft-lawrence-digest-request-00.txt Agranat Systems, Inc.
3	Expires: December 1997 July 14, 1997
4
5
6	HTTP/1.1 Message Digest Attribute Request
7
8	Status of this Memo
9
10	This document is an Internet-Draft. Internet-Drafts are working
11	documents of the Internet Engineering Task Force (IETF), its
12	areas, and its working groups. Note that other groups may also
13	distribute working documents as Internet-Drafts.
14
15	Internet-Drafts are draft documents valid for a maximum of six
16	months and may be updated, replaced, or obsoleted by other
17	documents at any time. It is inappropriate to use Internet-
18	Drafts as reference material or to cite them other than as
19	``work in progress.''
20
21	To learn the current status of any Internet-Draft, please check
22	the ``1id-abstracts.txt'' listing contained in the Internet-
23	Drafts Shadow Directories on ftp.is.co.za (Africa),
24	nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
25	ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
26
27	1. Abstract
28
29	This memo describes a security weakness in the current Proposed
30	Standard for HTTP Digest Access Authentication, and proposes a
31	change to that scheme to correct the deficiency. The problem is
32	that there is no mechanism for either party to indicate a
33	requirement that messages be sent with an authentication digest.
34
35
36	draft-lawrence-digest-request-00.txt Page 2/4
37
38	2. The Problem
39
40	The Digest Authentication scheme specifies a mechanism (the
41	'digest' attribute of the Authentication-Info and Authorization
42	header fields) by which a digest of the message body and selected
43	headers may be transmitted. This provides a valuable means of
44	protecting the message body from modification or replay attacks
45	based on modifying either the message body or the protected
46	headers, while preserving the authentication headers.
47
48	The mechanism is only valuable, however, if the message recipient
49	can require that the digest attribute is present, but at present
50	the authentication scheme does not provide a means to indicate that
51	the digest is required. There are two difficulties created by this
52	lack, an interoperability problem and a security problem:
53
54	- The interoperability problem is that if one party (either client
55	or server) wishes to require a digest for a particular HTTP
56	request or response, the other party cannot be told of the
57	requirement. This leaves us with the situation that in order for
58	such a requirement to work that all messages using the Digest
59	Authentication scheme would need to use the message digest, even
60	those for which it would not be required. Because computing the
61	digest is relatively expensive, this is undesirable.
62
63	- The security problem is that an attacker can remove the
64	attribute, preserving the remainder of the authentication
65	information, and modify the parts of the message the digest was
66	meant to protect.
67
68	For example, a server implementation might provide for a resource
69	attribute to require that Digest Authentication be used and a
70	message digest supplied in order to submit a form. This would be
71	used to ensure that forms could be defined for which the flimsy
72	protections of Basic authentication are not appropriate. The
73	requirement that the Digest Authentication scheme be used can be
74	communicated to the client by sending a WWW-Authenticate header
75	with 'digest' as the only acceptable scheme, but no mechanism is
76	provided to require the message digest.
77
78
79	draft-lawrence-digest-request-00.txt Page 3/4
80
81	3. Solution
82
83	Attributes should be added to the WWW-Authenticate and
84	Authorization headers to indicate that a message digest is required
85	on the subsequent message. The section numbers below refer to [RFC
86	2069].
87
88	Note that this draft does not propose that support for Digest
89	Access Authentication become a requirement for HTTP/1.1
90	conformance. It does add a requirement to the definition of the
91	scheme if it is supported at all.
92
93	================================================================
94	in section 2.1.1:
95
96	WWW-Authenticate = "WWW-Authenticate" ":" "Digest"
97	digest-challenge
98
99	digest-challenge = 1#( realm \| [ domain ] \| nonce \|
100	[ opaque ] \|[ stale ] \| [ algorithm ] \|
101	[ digest-required ] )
102	...
103	digest-required = "digest-required"
104	...
105
106	digest-required
107	A flag, indicating that any request for the resource to which this
108	response applies must include the 'digest' attribute in its
109	Authorization header.
110
111	================================================================
112	in section 2.1.2:
113
114	Authorization = "Authorization" ":" "Digest" digest-response
115
116	digest-response = 1#( username \| realm \| nonce \| digest-uri \|
117	response \| [ digest ] \| [ algorithm ] \|
118	opaque \| digest-required )
119
120	...
121	digest-required = "digest-required"
122	...
123
124	digest-required
125	A flag, indicating that the response to this request must include
126	the 'digest' attribute in its Authentication-Info header.
127
128	================================================================
129
130	in section 3.3, paragraph 4:
131
132	The discussion of attacks based on removing the "digest" field of
133	the Authentication-Info header can be removed; the remainder is
134	still correct.
135
136
137	draft-lawrence-digest-request-00.txt Page 4/4
138
139	4. Security Considerations
140
141	This entire draft is about security considerations.
142
143	5. Author's Addresses
144
145	Scott Lawrence
146	Agranat Systems, Inc.
147	1345 Main St.
148	Waltham, MA 02154
149	Phone: +1-617-893-7868
150	Fax: +1-617-893-5740
151	Email: lawrence@agranat.com
152
153	6. References
154
155	[RFC 2068]
156	R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee.
157	"Hypertext Transfer Protocol -- HTTP/1.1."
158	RFC 2068,
159	U.C. Irvine, DEC, MIT/LCS,
160	January 1997.
161
162	[RFC 2069]
163	J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach,
164	A. Luotonen, E. Sink, and L. Stewart.
165	"An Extension to HTTP : Digest Access Authentication"
166	RFC 2069,
167	Northwestern University, CERN, Spyglass Inc., Microsoft Corp.,
168	Netscape Communications Corp., Spyglass Inc., Open Market Inc.,
169	January 1997.
170
171
172
173
174