[ZODB-Dev] CHAP with ZEO

[Michel Pelletier]

On Mon, 21 May 2001, Jeremy Hylton wrote:

> I do not think that CHAP is a good scheme to use.  It is weaker than
> even HTTP digest authentication.  The disadvantages section of the
> CHAP RFC is short, but has one pretty significant limitation:
> 
>     CHAP requires that the secret be available in plaintext
>     form. Irreversably encrypted password databases commonly available
>     cannot be used.

I don't see how digest auth beats this limitation.  The digest server
needs to hash the same credentials the client used, and if the server
can't unencrypt the encrypted password that it knows, then it cannot
authenticate using CHAP or digest (unless the client can do the same
encryption to the data before hashing the response).

In this case, the above limitation to CHAP is poorly worded, you *can* use
encrypted passwords, if the client can reproduce the encrypted value used
by the server (for example, crypt() with a known seed value).

This worded differently in rfc 2069:

   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.

Isn't this the same for CHAP?  It seems that way to me.

> The HTTP digest authentication mechanism (RFC 2069) is a variation on
> the same theme, but seems to be designed more carefully.  Certainly,
> the operational environment for PPP servers is different than it is
> for HTTP servers.  A ZEO environment is more like HTTP than PPP.

Really?  I don't agree.

There isn't really anything PPP specific about CHAP, I imagine it could be
implemented over any protocol, simple, well-defined shared-secret
challenges and responses.  

There seem to be a lot of HTTP specific things about digest auth however.
Behavior specification for proxies, lots of headers and options, the need
to hash in a 'request method' and 'URI' which are meaningless to the ZEO
protocol.  Digest seems designed to work in a 'stateless' environment like
HTTP where transactions between clients and servers are done in seperate
requests, not one long running session like ZEO or PPP (although certainly
digest could be used in a long running session).

The one thing I see digest auth doing that CHAP doesn't is provide a
'digest' to verify that contents did not change in route and 'nextnonce'
to make subsequent digest authentication challenges faster.  'digest' is
only applicable to ZEO by adding per-rpc call packet overhead to verify
each pickle, and 'nextnonce' would only be useful if we made lots of
challenges to the same client in an HTTP-like 'stateless' environment
which would require authentication for each request, something ZEO doesn't
do.

> RFC 2069 has a nice security considerations section that is relevant
> to the question of a ZEO authentication mechanism.  Here's the intro:
> 
>     Digest Authentication does not provide a strong authentication
>     mechanism. That is not its intent. It is intended solely to
>     replace a much weaker and even more dangerous authentication
>     mechanism: Basic Authentication. An important design constraint is
>     that the new authentication scheme be free of patent and export
>     restrictions.
> 
>     Most needs for secure HTTP transactions cannot be met by Digest
>     Authentication. For those needs SSL or SHTTP are more appropriate
>     protocols. In particular digest authentication cannot be used for
>     any transaction requiring encrypted content. Nevertheless many
>     functions remain for which digest authentication is both useful
>     and appropriate.

When I read this, I can see the idea being carried over to ZEO:

    CHAP does not provide a strong authentication mechanism for ZEO, that
    is not its intent.  It is intended solely to replace a much weaker and
    even more dangerous authentication mechanism: absolutely nothing.

Of course, the paragraph could be rewritten again saying 'digest auth'. ;)

> As Andrew said in an earlier message, we do a disservice to the
> community if we promote a system with a security infrastructure that
> we know is substandard.

CHAP is sub-standard weak authentication?  To me the standard is 'Basic
Auth-like'.  Almost all internet authentication that I do other than ssh
(through the web, IMAP) is done in the clear.  CHAP is certainly superior
to that.  I think that providing *no* authentication, even basic-style, is
sub-standard.

Digest may be better, stronger, and in fact actually easier to implement, 
but it really just seems like a different implemenation of the same class 
of weak authentication that digest auth fits into.  

I'll have to read the RFC more closely.  Do you know of any pre-existing
digest auth python modules, perhaps from the work done on Grail?

-Michel