W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Digest mess

From: Randy Turner <rturner@sharplabs.com>
Date: Wed, 17 Dec 1997 00:08:52 -0800
Message-Id: <34978894.EB610019@sharplabs.com>
To: "Phillip M. Hallam-Baker" <hallam@ai.mit.edu>
Cc: rlgray@us.ibm.com, HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4985
Speaking as someone who is using HTTP
for Internet Printing, I would like to
see security mechanisms removed from the
core HTTP specification. "Basic" could
be included to support legacy environments,
but I do not think that HTTP digest provides
adequate security for payloads being
carried by HTTP (HTML, IPP, Webdav, etc..)

If we're going to adequately address security,
I would like to see it solved more
robustly. Transport Layer Security (TLS)
seems to address most, if not all, security
requirements of most applications using HTTP.

There seem to be two problems to solve for
HTTP using TLS; 1) We need an in-band 
signaling mechanism so that clients and
servers can negotiate whether or not the
overhead of a security encapsulation is
required, and 2) We need a TLS profile
that specifies unencumbered cipher suites
to be used. 

I think a SASL profile for HTTP would solve
the first point, and some combination of
Diffie-Hellman, Triple-DES, and MD5/SHA
mechanisms would solve the 2nd point.

Legacy environments could be supported by
running TLS-enabled services on port 443
(HTTPS), but this would be up to a site
administrator, and not necessarily be 
addressed by normative text in the 
standard document.

I and other groups have had a difficult
time with the compound support for
security over HTTP. "Compound" in this
context means negotiating TLS/SSL3
security mechanisms at the beginning of
an HTTP session, and then later on hitting
HTTP security (both basic and potentially
digest). Its difficult to administer and
potentially difficult for end users.

It appears that TLS would be a good 
candidate for handling security for most
types of application protocols being
developed by the IETF. Also, SASL, or some
equivalent, could be used to negotiate
whether security is required. With
these mechanisms, working groups developing
application protocols (or higher layer
transport protocols) would have a common
base to work from and it would ease the
burden of authoring the "security 
considerations" sections of their respective
documents. All working groups could rely
on the expertise of others who developed
TLS, and NOT have to become security experts.
Basically, the working group members could
concentrate on the "applications", without
having to worry about "other issues".


Randy Turner
Sharp Labs of America

Phillip M. Hallam-Baker wrote:
> As the person who orginially proposed digest I have a few comments:
> 1) The spec has been arround for three years, people who have built
> up large databases of non system passwords hardly deserve much
> consideration. In any case passwords should be changed regularly,
> shaddow the damn database.
> 1a) If you are using Kerberos the last thing you want is BASIC
> authentication...
> 2) The purpose was to prevent the need to EVER send passwords
> over the net in the clear, not to provide cast iron security.
> The problem with BASIC is that pinheads chose the same password
> for their Financial times subscription as their office computer account.
> If I can snoop a companies external traffic for BASIC passwords I can
> probably use this for an attack.
> 3) It is astonishing how people will tolerate the incredibly broken (BASIC)
> and simultaneously spend their time inventing new hoops for attempts to
> provide a fix. I stopped adding whistles and bells when people told me
> they were concerned about the difficulty of implementing it.
> 4) The idea of password based authentication is inherently flawed. If
> one is going to use public key, certificates are the means to establish
> identity. Sending passwords to an untrustworthy server does not solve
> the 'pinhead' problem.
>             Phill
Received on Wednesday, 17 December 1997 00:16:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC