Subject: Re: PaceSecurityServices & Digest auth

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 01 Jul 2004 17:03:07 +0200

* Ezra Cooper wrote:
>I see three issues to be addressed with Digest:
>
>   (1) Some web-servers remove the WWW-Authenticate header before 
>passing it to a CGI program.

The relevant header is the "Authorization" request header,
WWW-Authenticate is a response header which a CGI program
would normally not see but rather emit.

>========
>An Atom client MAY authenticate itself to an Atom server by sending an 
>X-Atom-Authenticate HTTP header, in the same form as for the 
>WWW-Authenticate header [RFC2617]. If an Atom client sends a 
>WWW-Authenticate header, it SHOULD have the same value as the 
>X-Atom-Authenticate header.
>========

So this does not really make sense to me. It seems the server would
send an Atom-Authenticate header, but then I ask why it is not e.g.
'WWW-Authenticate: Atom' since clients should not have a problem
generating such a header. So, do you mean clients should send an
Atom-Authorization header that would replicate an Authorization
header that the client would send, too, to bypass the security
mechanism that some web servers employ to hide the Authorization
header? An example communication transcript would we useful.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 01 Jul 2004 21:43:12 +0200

On Wed, 30 Jun 2004 18:44:40 -0700, Ezra Cooper <[email-masked]> wrote:

> I'd like to express support for specifying some authentication method(s)  
> for use with Atom

As a matter of fact, I think Atom not only should, but must provide some  
sort of security guidelines, including authentication (but maybe stuff  
including encryption of sensitive information etc as well). Why? As RFC  
3470 says:

   Given the lack of security services in XML, it is imperative that
   protocol specifications mandate additional security services to
   counter common threats and attacks; the specific required services
   will depend on the protocol's threat model.

So, Atom SHOULD define some sort of authentication method in the  
specification, or at least give some references.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Ezra Cooper <[email-masked]>
Date: Thu, 1 Jul 2004 13:18:27 -0700

> would normally not see but rather emit.

Right, sorry, I got this backwards. The text should read:

========
An Atom client MAY authenticate itself to an Atom server by sending an 
X-Atom-Authorization HTTP header, in the same form as for the 
Authorization header [RFC2617]. If an Atom client sends an 
Authorization header, it SHOULD have the same value as the 
X-Atom-Authorization header.
========

An (abbreviated) example communication would be something like the 
following. Messages sent by the server are prefixed by S: and those 
sent by the client are prefixed by C:

================= first request =================
C: POST /some/atom/resource HTTP/1.1
C: Host: some-atom-server.com
C: Content-length: [length of message-body]
C:
C: [some XML]
S: 401 Unauthorized
S: WWW-Authenticate: Digest realm=[email-masked], 
nonce=6Fg8k+ah4t1p/A86az=, algorithm=MD5
================ second request ================
C: POST /some/atom/resource HTTP/1.1
C: X-Atom-Authorization: Digest username=ezra, 
realm=[email-masked], nonce=6Fg8k+ah4t1p/A86az=, 
uri=http://some-atom-server.com/some/atom/resource, 
response=deadbeefdeadbeefdeadbeefdeadbeef, algorithm=MD5
C:
C: [some XML]
S: 201 Created
S: [further headers, response message-body]
============================================

It should be clear that the syntax and semantics of this header 
(X-Atom-Authorization) would be exactly those of the usual 
Authorization header, simply renamed in order to get past certain 
troublesome web servers.

Ezra

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 1 Jul 2004 23:12:44 -0400

On Wed, 30 Jun 2004 18:44:40 -0700, Ezra Cooper <[email-masked]> wrote:
> To address the third issue, I'd like to propose some alternative
> "algorithms" (in the sense of RFC 2617) for Digest auth. In particular
> I'd like to offer new functions to take the role of the H and KD
> functions used in RFC 2617, sections 3.2.2.1 and 3.2.2.2. I'm happy to
> propose these in a separate RFC, or help work them into the Atom spec.
> I do believe that they would have usefulness outside of Atom, and yet
> my immediate goal is to achieve interoperable Atom implementations.

Agreed. I believe the digest mechanism Mark and I  outlined does have the 
capability to handle the problems you have outlined. The initial
challenge from the server could indicate the desired hashing 
mechanism via 'algorithm'. I believe settling on just 3 (MD5, SHA1, and 
crypt with a given salt) would probably cover the vast majority of all cases.
The ability to handle different hashing schemes in Digest is present in the
spec but not implemented.

One thing I would like to stress is that the authentication
outlined in [1] is nothing more that RFC 2617 Digest with
some headers renamed to get around Apache's handling 
of authentication based headers and CGIs.  

In addition I would like to see implementations that 
used 'auth-int', yet another nice
feature of digest to prevent man in the middle
attacks that is currently under implemented
in digest (read: not at all).

    Thanks,

[1]  http://bitworking.org/news/New_AtomAPI_Implementation_Release2

> 
> Thanks,
> Ezra
> 
> References
> [1] http://bitworking.org/news/New_AtomAPI_Implementation_Release2
> 
>

---

From: Greg Stein <[email-masked]>
Date: Mon, 5 Jul 2004 04:54:49 -0700

On Wed, Jun 30, 2004 at 06:44:40PM -0700, Ezra Cooper wrote:
>...

This is on purpose. Very, very much so.

The mechanism for passing information from the web server to the CGI
program is via the environment. The particular scenario that you're trying
to solve is "my ISP let's me write a CGI, and I can't enable authn within
the web server itself [so I must do authn in the CGI script]".

Now carry this forward a couple steps. In some environments, suExec is
being used so the script runs as the user who wrote the thing. But in some
environments, the CGI runs as the same user as the httpd process. Or, in
other words, *all* CGI scripts run that way.

Now you've got a bunch of CGI scripts all running as the same uid, and
you've got some authn information sitting in the environment of some. Now
some cracker comes along and simply dumps out /proc/*/environ from his own
CGI. Sure, many can't be read, but some *can*. And now he has your
password.

Apache does not pass the Authorization header to CGIs because it is a
security hole. A big one. You can enable it if you want, but you're going
to have to pass -DSECURITY_HOLD_PASS_AUTHORIZATION to the Apache build.
That symbol isn't a joke. It really is a hole if that goes into the env.

>   (2) We need an equivalent method for use within a SOAP message.
>   (3) The default HTTP Digest auth algorithm is based on MD5, and 
> requires the server to be able to form an MD5 hash based on the triple 
> (username, realm, password). If you don't store either the cleartext 
> password or that specific hash, you're out of luck.

"or that specific hash" seems to solve the problem just fine. What's the
issue here?

> To address (1), I propose this addition to the end of section K,kk. in 
> PaceSecurityServices:
> 
> ========

This simply introduces a security hole, which is not something we should
be advocating or encouraging. I'll -1 this right now. And if I'm feeling
particularly evil, I'll go update the httpd server to filter this header,
too (big <wink>!)

>...
> As to (2), I suggest that we simply tunnel the header fields of HTTP 
> Digest Auth within XML elements (the same way we've done with WSSE). 
> Using WSSE UsernameToken is attractive, except for requiring the server 
> to store the password in the clear. I'll be interested what others 
> think about this.

Why not just use WSSE? Above, you take issue with storing cleartext digest
passwords. Can't you just use WSSE and demand that the hashed-form of that
authn mechanism be used?

> "algorithms" (in the sense of RFC 2617) for Digest auth. In particular

The server should just store the hashed forms. I don't see a big problem
here.

I can't see that introducing alternate algorithms will fix it, either.
Digest authn has a basic structural weakness (to exposure of the
server-side cleartext passwords or hashes) because of how (and what)
information is traded between server and client. You aren't going to get
around that unless you move to something more akin to SSL (and hashing
arbitrary values, rather than just coughing up a particular hash result).

IMO, use SSL. Failing that, use Digest. Failing that, use WSSE with a
hashed secret (no plaintext!). I don't know that Yet Another
Authentication Mechanism needs to be defined.

Cheers,
-g

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 6 Jul 2004 07:59:16 -0400

> CGI. Sure, many can't be read, but some *can*. And now he has your
 
Not true in the case of Digest. In the case of Basic where the 
password is passed in plain text this is a problem but there 
is no reason at all for Apache to strip the headers for Digest. 

> particularly evil, I'll go update the httpd server to filter this header,

Apache needlessly strips the headers when Digest authentication
is used thus locking out CGIs from handling the authentication
themselves. If Apache didn't have that behaviour than the creation
of  this variant of Digest wouldn't have been necessary.

Please understand that *you* are the damage we are trying to route around.

   Thanks,
   -joe

---

From: Tim Bray <[email-masked]>
Date: Tue, 06 Jul 2004 07:47:41 -0700

On Jul 6, 2004, at 4:59 AM, Joe Gregorio wrote:

... a bunch of reasonable arguments about Apache headers, then...

> Please understand that *you* are the damage we are trying to route 

Joe, *please* don't do this.  You can't be an editor and a leader of 
the community and a flamer at the same time.  I think an apology to 
Greg would be in order.

- Tim Bray, Director of Web Technologies, Sun Microsystems
   +1-877-305-0889 http://www.tbray.org/ongoing/
   AIM: MarkupPedant

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 6 Jul 2004 11:15:05 -0400

> Please understand that *you* are the damage we are trying to route around.

It has been pointed out to me off-list that this 
was unduly harsh. Please accepy my apologies.

    -joe

---

From: Ezra Cooper <[email-masked]>
Date: Mon, 5 Jul 2004 22:55:31 -0700

> CGI. Sure, many can't be read, but some *can*. And now he has your

I see how that's a risk for Basic auth, but not for Digest. That's why 
we hash the nonce in there, so that the exact header value is only 
useful once. Sure, I guess there's a race condition if this cracker can 
make use of the token before the original process has a chance to 
cancel the nonce; but it seems like it would be tricky to arrange.

I would expect clients to be conscientious and not to pass re-usable 
authentication information in this alternate HTTP header. Maybe the 
proposed spec text should be explicit about that:

===============
An Atom client MAY authenticate itself to an Atom server by sending an 
X-Atom-Authorization HTTP header, in the same form as for the 
Authorization header [RFC2617]. If an Atom client sends an 
Authorization header, it SHOULD have the same value as the 
X-Atom-Authorization header. An Atom client MUST NOT use the 
X-Atom-Authorization header to send the user's password or any token 
that could be replayed by an eavesdropper to authenticate itself to the 
server.
===============

Is that OK? Any other holes?

Thanks,
Ezra