Subject: Digest Authentication

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 16 Oct 2001 11:12:37 -0400

I would like to propose a small change to the webDAV specification.

Digest Authentication requires that a server store its passwords in such a
way that they be available in clear text format.

Our experience with our customers has shown that this is TOTALLY
UNACCEPTABLE.

As a result, we will not be able to implement digest authentication in our
webDAV server.

I would like to propose that the Digest Authentication requirement be
demoted from mandatory to optional.

--Dylan

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Tue, 16 Oct 2001 20:01:46 +0200 (CEST)

> way that they be available in clear text format.

Actually though your implementation -could- store the password on disk as
plain text - most do not; and it is technically not required. Some bad
implementations do store it plain - but (for example) the apache web
server stores the password as a hash (md5 or crypt) on the server side.

See http://cvs.apache.org -> apache-1.3 -> src/support/htpasswd.c and
src/support/htdigest.c to get an idea of the code).

So it is not a requirement - just an implementation choise.

It is true that with normal basic auth the password goes over the wire in
the clear; but with digest auth this is not the case.

Dw

---

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 16 Oct 2001 14:36:56 -0400

We did think of this solution, but that means that we always have to use the
same nonce value and we end up getting no security improvement over basic
authentication - so the argument that it is more secure than basic is bogus
if you do this.

--Dylan

> -----Original Message-----
> From: Dirk-Willem van Gulik [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 2:02 PM
> To: Dylan Barrell
> Cc: WebDAV
> Subject: Re: Digest Authentication
>
>
>
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 16 Oct 2001 13:38:18 -0700

Dylan,

I'm not sure I understand your nonce issue. You do not need to store
the password on disk in the clear. In order to compute (or verify) the 
the client's authenticator you need to have the value H(A1). For the
MD5 authentication scheme A1 is:

A1       = unq(username-value) ":" unq(realm-value) ":" passwd

(see RFC 2617 S 3.2.2.2).

This is a fixed value for any user so it can be stored on disk
directly. 

There's no need to use a fixed nonce in order to use a fixed H(A1)
since the nonce is not an input to A1.

Perhaps what you're referring to here is that compromise of H(A1)
on a given server allows the attacker to impersonate the user to
that server. However, this is not the same as compromise of the
password since it does not permit the attacker to impersonate the
user to any other server, even if the user has used the same password
on that user.

Admittedly, this problem does not exist with basic auth. However,
most people consider sniffing a more serious threat than password
file theft, which is why DAV so strongly "encourages" digest.

What threat model are you concerned with here?  Would you be 
implementing BASIC if you don't implement DIGEST, or is neither
good enough?  What would be good enough?

Lisa

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dylan Barrell
> Sent: Tuesday, October 16, 2001 11:37 AM
> To: Dirk-Willem van Gulik
> Cc: WebDAV
> Subject: RE: Digest Authentication
> 
>

---

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 16 Oct 2001 17:44:00 -0400

Lisa,

But the passwd is a portion of A1. So how is storing this different from
storing the password?

I am saying that neither basic nor digest is good enough - and so there is
no added benefit of implementing digest when the real solution is transport
layer security or some other authentication mechanism like kerberos.

--Dylan

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 4:38 PM
> To: Dylan Barrell
> Cc: WebDAV

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 16 Oct 2001 16:08:47 -0700

I agree that storing A1 is little better than storing the password.  I just
disagree with your nonce issue and conclusion.

If you plan to support transport layer security, how do you intend to get
the password from the client?  Using Basic auth within a TLS-secured
communication can be very secure indeed.

lisa

> From: Dylan Barrell [mailto:[email-masked]]
> Sent: Tuesday, October 16, 2001 2:44 PM
> To: Lisa Dusseault
> Cc: WebDAV

---

From: Alan Kent <[email-masked]>
Date: Wed, 17 Oct 2001 10:06:49 +1000

Just thought I would add my 2 cents (oh, given Australian/US currency
conversion that might only be 1 cent :-) and say that our product is
unable to implement digest authentication for reasons similar to
those put forward by others.

Our product has to work in a range of different environments where
there are existing authentication mechanisms out of our control.
We cannot even guarantee that a user name and password will be
available for authentication! (One site uses SSL certificates only).
There is no way we can ask for plain text passwords. And there is
usually no way we can access even an encrypted version of it because
the supplied API does not permit it and its to hard for the customer
to change their security infrastructure just for us.

Bottom line is that I think that WebDAV does not need to specify
a security scheme - it can just say to use normal HTTP security
methods. It seems like an orthogonal issue to WebDAV to me.

Alan

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 16 Oct 2001 17:44:21 -0700

> methods. It seems like an orthogonal issue to WebDAV to me.

The diversity of WebDAV deployment scenarios was one of the key drivers
behind RFC 2518 *not* mandating the *use* of a particular authentication
mechanism.  RFC 2518 merely states that implementations MUST implement
Digest, not that they must use it.

But, I believe Dylan is saying that the requirement to implement Digest is
causing his server to store passwords in the clear, and hence implementing
Digest (even if it isn't used) is causing him problems.

- Jim

---

From: Alan Kent <[email-masked]>
Date: Wed, 17 Oct 2001 11:32:37 +1000

> Digest, not that they must use it.

Well, since its not possible for us to use Digest authentiction at
customer sites, I guess our 'digest implementation' will just have
to reject all attempts to connect :-) :-) :-)

Sorry, could not resist!
Alan

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 17 Oct 2001 04:45:38 +0200 (CEST)

Please check RFC2617. This issue was noted during the design of the digest
method and effectively addressed.

Or in other words: As long as the hash over the username/real/password is
known to the server - any nonce can be used. See

	http://httpd.apache.org/docs/mod/mod_auth_digest.html

and it's source for what and how.

Dw

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 17 Oct 2001 04:50:11 +0200 (CEST)

Actually beasts like apache do not store A1 but a Hash(A1) which is not as
bad as storing A1. Some other web servers do store A1. It is an
implementation choise.

Dw

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Wed, 17 Oct 2001 02:13:04 -0400

Sigh, this debate has been going on for eight years.

There are two potential points of vulnerability for a password, in storage
and in transit.

If you have a system that protects the password in storage and in transit
then it can be used as a public key system, therefore any system based on a
symetric key alone cannot provide protection in both cases.

The reason I first proposed Digest Authentication is that the vulnerabilty
of a password in transit is considerably greater than the vulnerability in
storage for practically any conceivable network application. The original
Moris analysis of the one way encryption scheme in UNIX considered only the
vulnerability of stored passwords because networking was not common at the
time.

The original Moris analysis is in any case hopelessly flawed, in the
original paper the proposal is made that read protecting the password file
in addition to encryption is a bad idea and should be dimissed as 'security
through obscurity'. It took several generations of password crackers before
the UNIX sysadmin world silently abandoned that particular piece of nonsense
and started using shaddow password files.

At the time the proposal was made public key encryption was encumbered by
the Diffie-Hellman and RSA patents, hence there was a need for a symetric
key scheme designed to protect the key in transit.

The second issue the digest authentication design attempts to address is
limiting the risks involved in sharing passwords between sites.

The Basic authentication scheme, even over SSL is vulnerable to practically
every scenario in which the Digest scheme is vulnerable in addition to many
in which the Digest scheme is secure. If the attacker is presumed to have
read access to a critical systen file such as the password file it is
unreasonable to assume that the attacker cannot gain write access to the web
server executable, or for that matter gain access to whatever security
sensitive resource that was meant to be protected.

Today a much better approach than Digest Authentication would be to use a
federated authentication system such as SAML being standardized in the OASIS
standards group.

		Phill

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Tuesday, October 16, 2001 7:09 PM
> To: Dylan Barrell
> Cc: WebDAV
> > > > We did think of this solution, but that means that we
> always have
> > > > to use the

---

From: "Dylan Barrell" <[email-masked]>
Date: Wed, 17 Oct 2001 09:22:04 -0400

I have no problem with Digest Authentication, simply its status in RFC2518.

--Dylan

> From: Phillip Hallam-Baker [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2001 2:13 AM
> To: 'Lisa Dusseault'; 'Dylan Barrell'
> Cc: 'WebDAV'

---

From: "Dylan Barrell" <[email-masked]>
Date: Wed, 17 Oct 2001 09:22:03 -0400

Ah, right.  It does get a bit complicated:

Yes, the concern is the storage of H(A1), because this is a
plaintext-password equivalent.  The only advantage to storing H(A1) over the
plaintext password itself is that leaking the "password file" wouldn't
compromise other systems on which the user uses the same password.  Apart
from that, it's the same as a plaintext-password, because you can use it to
log in as the user in question.

Livelink stores its "password file" in the database, and it does _not_
assume that anyone who can access the password info has the right to
impersonate any user.  The way Livelink stores this information ensures that
you cannot impersonate a user with it.  This is a feature of _many_
authentication mechanisms, including the old /etc/passwd.

Right now, we can have a very secure Livelink install by using SSL with
Basic authentication.  If we must support Digest authentication, however,
then it would seem that we need to store H(A1), and so we would be
introducing a hole that does not exist Today -- bad.

You see, the problem is not so much that the spec forbids us from offering
Basic over insecure channels (though I would argue that it is overly
presumptuous).  The significant problem is that the spec _insists_ that we
support Digest -- even if we only use secure connections.

The only way I can see implementing Digest without introducing this new
security hole is to use a constant server nonce and no qop, so that for any
username/password/realm, the request-digest is constant.  Then I can store
salt+H(salt,request-digest) in the database.  While this _would_ produce a
compatible implementation, it would violate several directives in rfc2617,
and would render the protocol vulnerable to sniffing again -- just like
Basic.

Hence my request to demote digest authentication to the same level as basic
i.e. optional.

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Fri, 19 Oct 2001 21:47:12 -0400

IETF security policy is the reason why Digest is mandatory.

W3C policy is not going to accept sending passwords in the clear
either.

		Phill

> Sent: Wednesday, October 17, 2001 9:22 AM
> To: WebDAV; Lisa Dusseault

---

From: "Dylan Barrell" <[email-masked]>
Date: Mon, 22 Oct 2001 09:28:22 -0400

So we have to stick to policy even when there are indisputable reasons why
it doesn't make sense?

This doesn't seem like a very sensible thing to do.

--Dylan

---

From: "Matt Timmermans" <[email-masked]>
Date: Mon, 22 Oct 2001 18:28:40 -0400

Hi All,

I'm working on Open Text's WebDAV server, so these issues are somewhat
important to me.

At issue is not whether or not it's OK to allow Basic, but whether or not
it's necessary, or even acceptable, to require Digest.  This is not a binary
decision.  These are separate questions.

The offending sentence is in paragraph 3 of 17.1, where it says "WebDAV
applications MUST support the Digest authentication scheme".

For a server application, a reasonable interpretation of this directive
means that a client can authenticate with any WebDAV server using Digest
authentication.  This implies (in the strong sense) that a server _cannot_
require stronger authentication.  It similarly implies that a client
_cannot_ require stronger authentication.  It also implies that WebDAV
servers cannot exist in authenticated environments that are _too_secure_ to
support Digest.

I'm willing to accept that IETF and W3C policies would forbid sending
passwords in the clear, and I'll admit to not having done an exhaustive
search, but I cannot believe that it is the policy of either IETF or W3C to
forbid organizational requirements for strong authentication mechanisms.

Paragraph 2 in 17.1 already sets the appropriate lower bound on
authentication security, by giving the admonition against Basic over
insecure channels.  Paragraph 3 sets only _upper_ bounds on authentication
security, which is completely inappropriate.

I suspect that the intent of paragraph 3 was to guarantee some level of
interoperability when Basic was disallowed, because Basic is usually used as
the final fallback.  Appropriate wording would be "If a WebDAV client
application supports the Basic authentication scheme, then it must also
support Digest, and must choose to use Digest over Basic in all
circumstances where the server permits both".  This leaves both clients and
servers free to require strong authentication.  It also lets the server
require at least Digest as its lowest common denominator, without
sacrificing interoperability with any clients.

> [mailto:[email-masked]]On Behalf Of Phillip Hallam-Baker
> Sent: Friday, October 19, 2001 9:47 PM
> To: 'Dylan Barrell'; 'WebDAV'; 'Lisa Dusseault'

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 22 Oct 2001 16:59:16 -0700

> applications MUST support the Digest authentication scheme".

I wrote this section of 2518.

The intent was to ensure that:
(a) all server implementations were capable, if properly configured, of
performing Digest authentication.
(b) all client implementations were capable of responding to a Digest
authentication challenge, if issued by a server.

The rationale behind this was the IETF's stated policy of not approving new
protocols that sent username/password pairs over the wire in the clear.

Note, however, that RFC 2518 does NOT say that servers must USE Digest,
merely that they "support" (i.e., "implement") it. RFC 2518 also does NOT
say that you cannot implement or use other authentication technologies. IIS
5, for example, can be configured to use NTLM, and/or Digest, and/or Basic.

We recognized that there are a wide, wide range of deployment scenarios, and
we could not, a priori, predict what they would be like. Thus we left the
decision on whether to actually use Digest to the people deploying WebDAV
servers. And, yes, we did realize that initially, most DAV use would involve
Basic authentication over the open Internet, or within an intranet.

> authentication.

The cause-effect is a little skewed here. The interpretation is that it must
be possible to configure a client such that it can respond to a Digest
authentication challenge issued by the server.

> This implies (in the strong sense) that a server _cannot_
> require stronger authentication.

I do not see how this follows. IIS 5/6 is a counter-example of a server that
has successfully implemented an additional authentication scheme, NTLM, in
addition to Digest and Basic.

> It similarly implies that a client _cannot_ require stronger
> authentication.

In a challenge-response authentication scheme, I don't see how a client can
require *anything*.  A client could be configured to refuse to answer a
challenge in a particular authentication scheme (say, Basic), but not
answering is a different beast from *requiring* a specific authentication
scheme.

> It also implies that WebDAV servers cannot exist in authenticated
> environments that are _too_secure_ to support Digest.

I disagree. Following RFC 2518, someone deploying a DAV server could disable
Digest authentication, require connections only via SSL, and only allow
Basic authentication.

> search, but I cannot believe that it is the policy of either IETF
> or W3C to forbid organizational requirements for strong authentication
> mechanisms.

Correct. But, you're making a strawman out of 2518 that isn't true. Nothing
in 2518 prevents the use of stronger (or any) authentication schemes other
than Basic and Digest. Since Digest is unsatisfactory to a large number of
implementors, we felt that it was quite likely that new authentication
schemes would be developed over time, and wanted to make sure we could
accommodate them.

> Appropriate wording would be "If a WebDAV client
> circumstances where the server permits both".

Actually, this is too strong, since Basic over SSL is reasonably secure.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 22 Oct 2001 17:04:48 -0700

Let me note that the DAV WG was never given the mandate to develop new
authentication schemes, and we never wanted to.

There is widespread agreement that Digest has many drawbacks. Yet, as a
protocol specifier, I currently do not have an open protocol specification
free of IP restrictions that gives a more secure solution than Digest for
use with HTTP.

I, personally, have no interest in working on such a thing.

But, I know there are many people who are very interested in seeing a better
authentication scheme developed.

So, how much pain does this represent? Enough to start a working group to
develop a better alternative to Digest?

If so, I am more than happy to work with interested parties to get a
birds-of-a-feather (BOF) meeting scheduled on this topic at the next IETF,
and to help you with the process of forming a new working group.

- Jim

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Mon, 22 Oct 2001 20:28:56 -0400

The policy makes very good sense. Sending passwords in the clear 
is one of the major causes of compromised passwords. If  password
is compromised it is likely that the effect will compromise applications
beyond just WebDav because many users share passwords across applications.

The excuses given for not supporting digest were unconvincing. You
have an application that is not HTTP 1.1 compliant, so fix the thing.

WebDav is not going to proceed to standards status in any standards
group I have influence in if BASIC is the only mandatory to implement
authentication scheme.

In the IETF it will be subject to Jeff Schiller's veto on the IESG. 

In the W3C I will point the director to the IESG policy and the reason
for which it was made. I don't think that you are going to persuade
the W3C director to second guess the IETF on the issue.

		Phill 

> Sent: Monday, October 22, 2001 9:28 AM
> To: Phillip Hallam-Baker; 'WebDAV'; 'Lisa Dusseault'

---

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 23 Oct 2001 09:34:57 -0400

> have an application that is not HTTP 1.1 compliant, so fix the thing.

Phillip - show me the arguments against - other than the fact that policy is
against it. For all I care, we can make NTLM authentication mandatory as
this does not have the drawbacks that Digest does. Or otherwise make SSL
mandatory. Digest authentication has ramifications for a server that are
UNACCEPTABLE in the real world. I am talking about 5 million users of our
product here - not one or two! I am talking about global 2000 companies! I
am talking about REAL objections that we face EVERY DAY at our customers!
This is not some academic discussion - this is the real world!

--Dylan

---

From: "Matt Timmermans" <[email-masked]>
Date: Tue, 23 Oct 2001 12:16:14 -0400

> From: Jim Whitehead [mailto:[email-masked]]
> Sent: Monday, October 22, 2001 7:59 PM
> [...]
> [...]

This is still quite unclear.  What are the testable properties of a server
that "Supports the digest authentication scheme"?

The way I read it, "MUST support the Digest authentication scheme" says that
the server must return Digest as an available scheme in its
"WWW-Authenticate" headers, and that it must allow access to clients that
generate appropriate Digest responses.  This is the way you _want_ me to
read your specs, because if I don't read them this way, we run in to the
kind of troubles we have below.

> Note, however, that RFC 2518 does NOT say that servers must
> USE Digest, merely that they "support" (i.e., "implement") it.
> RFC 2518 also does NOT say that you cannot implement or use other
> authentication technologies. IIS 5, for example, can be configured
> to use NTLM, and/or Digest, and/or Basic.

IIS can only be configured to present Digest in WWW-Authenticate if your
user database is in stored in Active Directory.  Does IIS still support
Digest, or does (IIS+Active directory) support Digest?  If I send IIS an
OPTIONS, does it have the right to claim DAV-compliance if Active directory
isn't installed?  If DoD gets a special version of IIS that disables the
Basic and Digest options, because DoD only allows their public-key scheme,
does that version support Digest?

> addition to Digest and Basic.

I trust you can see how it follows from my reading.  "The server requires
NTLM" means that NTLM is the only scheme presented in WWW-Authenticate.  If
Digest MUST be present in WWW-Authenticate, then the server cannot require
NTLM.

> answering is a different beast from *requiring* a specific

If a client will only answer NTLM authentication requests, then it requires
NTLM.   That means that if a server only allows Basic and Digest, then you
can't access it with that client.  In high-security environments, this is a
perfectly reasonable thing for the client to do, because the client might
have a responsibility to protect the user's password.

> Digest authentication, require connections only via SSL, and

So there is no way to determine from the client side whether or not a server
"supports the Digest authentication scheme"?  That is very odd.

You're saying that if I run my server in an environment that doesn't allow
me to present Digest in the WWW-Authenticate headers, then that's OK, as
long as there's a checkbox for Digest somewhere and I've unchecked it?  But
the server would become mysteriously non-compliant if I customized it for my
environment by removing the checkbox, and that Digest implementation that
isn't used?  It would become non-compliant, even though it's functionally
equivalent?!

Even if this was reasonable, it would be outside the scope of a protocol
specification.

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 23 Oct 2001 10:55:12 -0700

> that "Supports the digest authentication scheme"?

The testable property is this:

It must be possible to configure the server, without writing new code, such
that it will return a Digest authentication challenge for a GET on given
resource R.

It is possible to create a falsifiable test of this property.

> NTLM" means that NTLM is the only scheme presented in
> WWW-Authenticate.  If Digest MUST be present in WWW-Authenticate, then the
> server cannot require NTLM.

Again, RFC 2518 does not mandate that Digest MUST be present in every
WWW-Authenticate header, only that it must be possible to configure that
server to make this so.

> > I disagree. Following RFC 2518, someone deploying a DAV
> > server could disable Digest authentication, require connections
> > only via SSL, and only allow Basic authentication.
>
> So there is no way to determine from the client side whether or
> not a server "supports the Digest authentication scheme"?  That is
> very odd.

No, the client only has the ability to determine which authentication
schemes are currently active on a specific resource, by examining the
WWW-Authenticate header.

Even if the client could determine that Digest was supported, but not turned
on for a particular resource, what would it do with that information? Having
this information wouldn't lead to greater interoperability.

> long as there's a checkbox for Digest somewhere and I've unchecked it?

Correct. (Assuming you mean the checkbox is on the server).

> But the server would become mysteriously non-compliant if I
> customized it for my environment by removing the checkbox, and that
> Digest implementation that isn't used?  It would become non-compliant,
> even though it's functionally equivalent?!

My personal opinion is that if the checkbox controlled a process that
swapped in/out a code library implementing the server-side storage of
passwords (and possibly resulted in data conversion of a password database
to a new format), that would be acceptable. That is, you could have a
running server executable that was incapable of Digest, so long as there was
an easy process (i.e., one that does not involve writing code) for changing
that executable so that it could support Digest. In operational environments
where Digest was not acceptable, the Digest code would never be merged into
the server executable.

Alternately, it might even be OK to have to go back to the installation disk
to get Digest support added.

What is unacceptable is for a user of a server to have to write code to get
Digest support. The goal is to make it "relatively easy" for a server
operator to enable/disable Digest authentication support on their server.

> Even if this was reasonable, it would be outside the scope of a protocol

I have to agree with Phill here. The political reality of the IESG is such
that an application protocol specification will not be approved if the only
mechanism for sending passwords over the wire is in the clear. My techical
opinion is that the current "Basic over SSL" or Digest choices are the
weakest possible requirements that will allow the specification to be
accepted. This is why I was encouraging people to develop a new, more
acceptable form of HTTP authentication technology.

But, the IETF has a long history of pragmatism, and so they would be
amenable to arguments about the lack of suitability of Digest. However, I do
feel you have an uphill climb to convince people that the problems with
Digest are inherent to the protocol, and not merely a peculiarity of your
particular implementation. The path of argumentation usually runs:

Person A: For implementation architecture X, Digest has the following bad
properties.
Person B: Ah, but if you do your implementation this way (...), you don't
have that problem.
Person A: Well, that may be true, but it would be difficult/costly to do it
that way.
Person B: Well then, your objection isn't to the protocol, it's to the
expense of implementing the protocol. That is, it's not a technical
argument, it's an economic one.

Now, you could present evidence that enough people have enough problems with
the implementation that it does imply a problem with the protocol, but
that's a tough argument to make.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 23 Oct 2001 10:56:49 -0700

> the W3C director to second guess the IETF on the issue.

Now, Phill, we're just having a discussion to flesh out the cross product of
Digest X WebDAV. No need to whip out the big sticks yet.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 23 Oct 2001 11:04:08 -0700

> long as there's a checkbox for Digest somewhere and I've unchecked it?

Just thought of another example. The Apache server "supports" Digest
authentication, even though the process of enabling it involves installing a
new module (mod_auth_digest). In the case of Apache, it is possible to
create a  server that does not have any Digest authentication code in the
running server executable.

Thus, Apache is an existence proof of "supporting" Digest, while not
compromising security in environments where characteristics of the Digest
implementation are unacceptable.

- Jim

---

From: "Stefan Eissing" <[email-masked]>
Date: Tue, 23 Oct 2001 20:30:16 +0200

Now, are we having fun here or what?

I just scanned RFC 2617 for any MUST wording on digest authentication
and could not find any. The thing I found is in Ch. 4.1, 3rd paragraph:

  "Because Basic authentication involves the cleartext transmission
   of passwords it SHOULD NOT be used (without enhancements) to protect
   sensible or valuable information."

I think this is the way it should be stated for WebDAV as well, if it
must be stated at all.

//Stefan

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Tuesday, October 23, 2001 8:04 PM
> To: [email-masked]; 'WebDAV'

---

From: "Matt Timmermans" <[email-masked]>
Date: Tue, 23 Oct 2001 14:44:52 -0400

> From: Jim Whitehead

All right.  By this definition, our server already supports Digest, even
though it won't be available in most installations.  There are unattractive
ways of installing it that pass through Digest authentication in the Web
servers we bind to.

However, I _know_ that any customer who is expecting "Digest" in his
WWW-Authenticate headers will think me a weasel if I provide this
explanation -- even if I can demonstrate that Jim Says It's OK.

Is there an authoritative reference I can point to that details this
interpretation of "must support the Digest authentication scheme"?  If not,
can we have a public authoritative erratum that spells it out?

I'm pretty sure that anybody who just reads the spec is going to expect the
Digest scheme in WWW-Authenticate, and will expect clients to know how to
respond.

> mechanism for sending passwords over the wire is in the
> clear.

Agreed, but this can be addressed with the standard cop-out that says that
normal HTTP authentication methods are used, that choosing one is
out-of-scope, that security is important for WebDAV, and that, therefore,
Basic over the Web is inappropriate.

The Digest requirement still performs no useful function.  I suggested that
it set only _upper_ bounds on security, and you replied that even those
don't exist.

---

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 23 Oct 2001 16:29:03 -0400

Yes, we can configure the Livelink server to support Digest Authentication.

Just seems a bit silly to have a mandatory part of a spec, that will never
get used in practice because it is too insecure, but the only reason it is
mandatory is policy aimed at making specs more secure.

I suppose that we just have to resign ourselves to these types of realities
;-)

--Dylan

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 23 Oct 2001 15:20:28 -0700

Dylan, Matt, others: Out of curiosity, what authentication options do you
consider to be good enough to meet your requirements?

- Jim

---

From: "Matt Timmermans" <[email-masked]>
Date: Tue, 23 Oct 2001 19:05:19 -0400

I'm happy with Basic over SSL.  If you want security over the Web, you might
as well use SSL.

Most of our intranet customers would probably prefer NTLM.

For parts of the intranet that don't require security, Basic suffices.

I'm not sure that really secure authentication without SSL is even a
requirement, but if you want it, then there are several alternative public
key technologies that do just fine.  While any organization might choose one
of these, they are not without IP issues, as you've noted.

Without public key techniques, there is a limit on how secure authentication
can be.  Digest doesn't meet that limit, because it's possible to require
eavesdropping on an authentication session _and_ access to the server's
stored password information, before it's possible to impersonate a user.  I
don't know of any standard scheme like this, though, and I don't know if
there's a need for one.

> Sent: Tuesday, October 23, 2001 6:20 PM
> To: Dylan Barrell; [email-masked]; 'WebDAV'

---

From: Daniel Brotsky <[email-masked]>
Date: Tue, 23 Oct 2001 16:01:10 -0700

>implementation are unacceptable.

I'm sorry, but this response seems like it completely misses the 
point that Dylan is making about testability.  There is no principled 
way to distinguish between altering a configuration file and "writing 
code," and I very much doubt that you could come up with language 
that makes this distinction that this group is willing to put into 
the spec.  Without such language, there is no way to test server 
compliance with the requirement that a server "MUST support digest 
authentication without the server administrator writing code," which 
is apparently what you meant the spec to say (as opposed to what it 
actually says, which I would argue is more naturally interpreted as 
"no server configuration can be considered a compliant WebDAV server 
unless all challenges it issues against its WebDAV URLs contain a 
WWW-authentication header specifying digest authentication.")

I also believe that this discussion, so far, misses the larger point 
someone raise a while ago about "WebDAV has *nothing* to say about 
authentication."  I believe that:

1. WebDAV is intended to be a pure HTTP 1.1 extension (as explicitly 
defined and allowed for in the HTTP 1.1 spec).

2. Like all "good extensions" :^),  it should have absolutely nothing 
in it except specification of the semantics of its extension methods 
and the semantics of its extension headers.

3. The IETF concern about future protocol specs requiring stronger 
authentication than basic makes perfect sense for protocols that are 
not HTTP extensions but can't sensibly be taken as a mandate for HTTP 
extensions: such protocols ARE simply a form of HTTP 1.1.

To see point 3 clearly, consider that WebDAV servers needn't 
implement digest over the GET, HEAD, and POST methods, because those 
methods are HTTP 1.1 methods and so their semantics can't be 
redefined by the WebDAV spec.  Putting a requirement for digest 
authentication in the WebDAV spec is a no-op except for the extension 
methods, and thus does not promote security in any effective way.

I believe that if the IETF really wants servers that obey its 
protocols to enforce something stronger than basic, then the security 
group had better write a very short RFC that updates 2068 and says 
"HTTP 1.1 servers, including those that implement HTTP 1.1 
extensions, MUST implement either digest or a more secure 
authentication scheme whenever they require authentication for a 
request made over an insecure connection."  Then they should move as 
quickly as possible to promote that RFC along the standards track. 
Holding HTTP 1.1 extensions hostage to a policy that's not applied to 
HTTP 1.1 is a non-starter position: there will never be any HTTP 1.1 
extension that supports as much authenticated traffic as plain old 
HTTP 1.1 does.

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Dylan Barrell" <[email-masked]>
Date: Wed, 24 Oct 2001 10:49:57 -0400

I agree with Matt - in reality some transport layer security will be used.
The real problem with digest is that it makes our server LESS secure. Basic
over SSL is actually better.

--Dylan