RECOMMENDATIONS
---------------
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 - [email protected] FAX: (512)338-3897
-- Salut, Ari --