[660] in WWW Security List Archive
notes from Darmstadt Security BOF
daemon@ATHENA.MIT.EDU (Mary Ellen Zurko)
Mon May 1 19:08:48 1995
From: zurko@osf.org (Mary Ellen Zurko)
To: www-security@ns2.rutgers.edu
Date: Mon, 1 May 95 13:58:39 EDT
Cc: zurko@osf.org (Me)
Errors-To: owner-www-security@ns2.rutgers.edu
These are my notes from the Security BOF at the 3rd International WWW
conference in Darmstadt. Apologies to all the "someones" whose name I
didn't catch or know.
Dave R. and Tim B-L gave an update on IETF activities. There will be
an IETF security WG in the very near future, chaired by Charlie
Kaufman. Greg Bossert [sp?] of Rutgers is responsible for putting
together a charter, which is the gating factor. The Digest Access
Authentication method was discussed by Jeff H (I won't recap all the
great features of this proposal here); it's in
ftp://ds.internic.net/internet-drafts/draft-ietf-http-disgest-aa-01.txt
He pointed out it took him less than 100 lines of code to
implement. Someone asked if the hash needed to be recalculated on
redirection; the answer was it depends on who's doing the
authentication. The nonce value definition is a server policy
issue. Concerns were raised about MD5; the proposal allows for other
digest algorithms to be chosen in the future. There was a concern that
this does nothing about the password guessing attack, since all the
data to guess about passwords is freely available, and humans continue
to chose passwords poorly.
Dave pointed folks at his Mediated Digest Authentication proposal,
which is Kerberos-like in its approach of trusted authentication
servers to cut down on the number of keys. It also provides mutual
authentication. It relies on the Digest method.
There was a discussion of firewalls and proxies. The CERN server is
large and complicated for a firewall proxy. Lorrayne Schaefer of MITRE
is doing work in the firewall area. She's looking for ways to filter
URLs and restrict protocols. The TIS firewall will search URLs for
"dirty words", is less than 6,000 lines of code, speaks HTTP (though
is not an HTTP server), and does not support SHTTP or SSL. They're
working on strong challenge/response support in proxies with
TIS. They're using SKEY now, but it's not appropriate for their
needs.
Someone from Netscape pointed out that the lack of a CA is gating
their client authentication support. There was a variety of go-rounds
where folks extolled the (comparable) virtues of products using SSL
and products using SHTTP, and products supporting financial
transactions. Participants included Spyglass, Netscape, and Spry. Jeff
discussed Spyglass's protocol, which included support for pay-per-view
or hard goods, and an HTML receipt. Netscape supports forms using
credit card numbers and encryption. Sprty supports on-line purchasing
of AIRMosaic.
Owen Rees pointed out the need for a delegation model and protocols
that go beyond identity. Phill H-B suggested an anonymous Web server
as a service.
Someone working on Java offered
http://java.sun.com/1.0alpha2/doc/security/security.html as an
excellent place to come up to speed on Java security issues. He
discussed some of the details of Java's security policy, such as not
opening a network stream to a server if there are any open files.
There was the standard amount of discussion about the bogosity of US
export policy on encryption. The EFF is supporting Phill Zimmerman,
who is under indictment. Some people want to make his case the test
case.
This segued [sp?] into discussions of trust and finance. Phill H-B
said everyone should be their own CA. The guy from Netscape pointed
out that we would clearly want multiple CAs (banks, companies,
etc.). Owen said you want enough trust to do the business you want to
do. Phill said some CAs can do different levels of trust. He went on
to discuss the kind of credentials you'd want enabled for
automatically signing things (credentials that did not give much money
away, and accepted no liability). He said a URN or URL should be the
pointer to the certificate revocation list for credentials, and
referred us all to his RFC (when it becomes available). Applications
should be able to use each other's credentials; Web browsers should be
able to use PGP certificates.
The Terisa announcment supporting SSL as well as SHTTP was discussed,
but no technical details were available.
Mez
