WWW Security Recommendations

Marc VanHeyningen <mvanheyn@cs.indiana.edu>
From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
To: www-talk@nxoc01.cern.ch
Subject: WWW Security Recommendations
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Date: Mon, 26 Jul 1993 12:26:14 -0500
Sender: mvanheyn@cs.indiana.edu
Content-Length: 13718
Status: RO


An appropriate interoperation standard for Kerberos (certainly KRB-4,
probably also KRB-5) and HTTP should be created.  However, by itself,
Kerberos does not seem sufficient to meet the security needs of HTTP
over a large and growing network.  Adding Kerberos to a site not
already so equipped is nontrivial; Kerberos needs central servers and
probably could not scale to a system with 100,000 different
administrative realms and 10,000,000 users.

Allowing interoperation of PEM and HTTP should not be inordinately
difficult, since HTTP/1.0 is essentially MIME and the PEM-MIME
interaction is already defined (though still in an Internet draft.)  I
have proposed a mechanism for this involving creating MIME types
message/http-request and message/http-response; I'm sure it will need
some refinement but I believe some approach like this can be viable.
Some additional features may need to be defined; for example, PEM has
no explicit mechanism for handling replay attacks, so a timestamp
within the http-request would be desirable.


You should note that my "pubkey" scheme is in fact as close to PEM
as I could make it without changing the current protocol, and bearing
in mind that not everyone wants to carry around a public key
(which is not necessary in case of http, because the server never
actively contacts the client, it's always the other way around -- so
we don't need to have a completely symmetrical system).

> Leaving out the message termination stuff (I wish we *could* ;-), the request
> message might look something like: 

Sorry, what do you mean by termination stuff??

> If the server *does* support this form of authentication, it returns a
> "please continue" status, and *holds the connection*. The client and

No! The no-sessions and no-state requirements have been there from the
start and are well justified.  If a stand-alone server holds the
connection it *will* slow things down considerably by reserving the
server from taking the next request.

>  wa | Wayne Allen, EINet - wa@mcc.com		 	 FAX: (512)338-3897

-- Salut, Ari --