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	wakaba	1.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