[349] in WWW Security List Archive
Re: The Digest authentication scheme
daemon@ATHENA.MIT.EDU (Phillip M. Hallam-Baker)
Wed Jan 25 20:09:46 1995
To: www-security@ns2.rutgers.edu
cc: hallam@dxal18.cern.ch
In-reply-to: Your message of "Thu, 26 Jan 1995 00:49:52 +0900."
<9501251549.AA18552@hopf.math.nwu.edu>
Date: Thu, 26 Jan 1995 05:47:15 +0900
From: "Phillip M. Hallam-Baker" <hallam@dxal18.cern.ch>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
John Fanks says:
> <http://info.cern.ch/hypertext/WWW/Protocols/HTTP/digest_specification.html>
>
> "Efficiency of signature digest generation
> The simplest method of digest generation would simply place the
> message digest in the message header. This has the disadvantage that a
> signature must be calculated before a message is sent which is
> unsatisfactory for large documents stored as files since the file
> would have to be read twice [Option Reply-G-1]. Alternatively the
> digest could be placed at the very end of the message which would
> require only the length of the message to be known in advance, since
> this is already calculated this is not a significant
> problem. Nevertheless this significantly deviates from the HTTP model
> of having all the access data in the header [OptionReply-G-2]."
>This is a specification with options for discussion neither of which I
>find very palatable. I think this proposal (with some choice of
>options) may be very appropriate as a part of S-HTTP, but it goes way
>beyond a simple replacement for Basic authentication.
The "simple replacement" part is as fas as environment goes. Ie there should
be no facilities Basic allows which are not possible with the Digest
scheme.
Also by `simple' I mean
1) NO ASN.1 - ie RFC822 style ASCII headers all the way
2) No ITAR problems :-)
3) No incredibly hacky code :-)
4) I can understand it.
Now the MD5 of the message body I agree is a pain in the nether regions. For
the client side (eg PUT and POST) there is already the problem that the
content length has to be calculated.
What we could do is :-
1) Punt entirely
2) Allow the option of Punting, authenticating JUST the head
is sufficient in many cases.
3) We could put the digest of the body at the end of the body somehow
[clients/servers need not check it!]
4) A combination of 2 and 3.
I don't agree that if we punt on the body we have to punt on the
authenticating the head though.
>Again a quote from the specification:
>
> "Note that there are in effect two headers, both terminated by two
> consecutive CRLF pairs."
This sounds major except
1) It is very easy to add in CRLF pairs with printf:-)
2) In this case there are NO backwards compatibility problems since
if the client/servers don't support it, well you are not
authorized!
3) By the time HTTP/1.1 is out there will be several browsers
doing MIME - so multiple header sections will be old hat.
4) It does allow compatibility with S-HTTP in a smooth fashion.
5) The PEM and PGP schemes both do this
In fact the main difficulty is that the whole head must be assembled before
it is sent :-( However this should not be that much of a problem because :-
1) Sending out the head as a unit is a good thing anyway for
performance reasons.
2) The head should not be more than a few K - if it gets to 1K
we have problems!
3) If you really MUST generate the header on the fly it is always
possible to do it twice, first feeding the headers into
the MD5 as they are generated, then for real.
4) If you really really do have problems you can always steal
the code from libwww.
>The bottom line is that the complexity of implementing this proposal
>is such that I fear implementors will opt to wait for a full security
>standard to emerge and, as a consequence, the seriously flawed Basic
>authentication will continue in widespread use.
Equally, if the new scheme does not offer sufficient protection people
may decide to wait for full S-HTTP.
On the other hand for the cost of some marginal code changes we can have a
system that would make use of the Digest scheme as a bridge to the full S-HTTP
scheme possible. That would mean that I could use the Spyglass browser [say] in
conjunction with the S-HTTP enhancement proxy I'm in the middle of to play
full S-HTTP.
This may not sound much until you realise that if spyglass try to sell an
S-HTTP version of their browser to me, Jeff, Eric and co will be listening
to one of those cute speeches by Marcia Clarke :-)
The Digest scheme has to be robust because it is ALL we can provide in the
basic code library. If I didn't have dimplomatic imunity it would be illegal for
me to use S-HTTP in France for example. I want to run a nuclear physics
experiment with this security scheme... some of the workers ARE in France.
The NSA is very happy for us to have a secure digest scheme for authentication.
In fact the UK lot were major pissed at the Basic scheme. I know that what I am
suggesting is a teensy-weensy bit more complex than SimpleMD5 but I don't think
that is much of a problem. For the S-HTTP scheme we sent Alan off to the NSA
(yes we checked it was the same one they returned to us). Now who wants to
volunteer to do the same thing with a less than secure digest mechanism hmm?
As a certain well known cryptographer said to me "you guys have an opportunity
to be as well known and regarded as the author of sendmail". I for one do not
want to spend the rest of my life explaining the the "web security bug" was not
my fault!
Phill H-B
