Date: Tue, 14 Sep 93 17:33:51 +0200
From: [email protected] (Ari Luotonen)
I quote a previous message in this mailing list
by Marc VanHeyningen with whom I agree about this:
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
Marc is partially correct here. There is a common confusion about
Kerberos that arises from the fact that Kerberos *only* authenticates.
It does not control access to data. (I'm *not* accusing anyone in
particular of being confused, merely pointing out that I've
encountered confusion before ;-)
Authentication is the establishment of the identity of interacting
parties. This is what Kerberos does. Once an identity has been
established, one can ascertain that party's access rights to specific
data (authorization). The security of data is only as good as the
authentication of the parties involved.
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.
It would indeed be silly to have 100,000 administrative realms. EINet
provides authentication services (ie, administers kerberos realms) so
that others need not do so. As to scaling, there are several ways to
scale Kerberos into the 10's of millions. We provide additional
software for access control using the authenticated Kerberos
identities. We have integrated this authentication/access-control
software with a number of client/ server applications like WAIS, ftp,
telnet, news, and soon, WWW.
In regards to the proposed "basic" scheme, I certainly wouldn't protect
important documents that way. Authentication by public key is
fine, but the infrastructure necessary for wide-spread use of such
a system is not yet in place. EINet will eventually support this form
of authentication, as well.
> 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.
Hmmm, our server forks... In any case, I suggested this way of doing
things precisely because of performance. Let me explain.
As the Kerberos mutual-authentication protocol stands now (v4 at
least), an HTTP client cannot blithly send a GET message with a
Kerberos authentication field and then proceed to authenticate on the
connected socket. If the server doesn't grok Kerberos, the data
exchange will be bungled. That means the client has to know
beforehand whether the server can authenticate with Kerberos protocol.
How does the client find this out?
Well, the client can make a request without the authentication field
and the server will tell it which schemes it supports. So, the client
re-submits the request with authentication field, they do the Kerberos
two-step together, and the server sends back the data (or not).
Doing this for every document retrieval seems pretty inefficient, so
I proposed a negotiation phase in the retrieval protocol.
I like Tony Sanders's proposal, although it still requires the client
to ask or know beforehand whether a server uses Kerberos. I would
modify it slightly, since there aren't really as many exchanges of
Kerberos bits as he shows.
client:
GET /document HTTP/1.0\r\n
\r\n
server:
HTTP/1.0 401 Unauthorized
Authenticate: External-KerberosIV, realm="bsdi.com",priciple="foo"
Authenticate: PK-reverse, principle="joe's-computers"
Authenticate: basic; kerberos
Example of OUT-OF-BAND Authentication
=====================================
client:
GET /document HTTP/1.0\r\n
...
Authorization: External-KerberosIV\r\n
\r\n
[kerberos bits]
server:
[kerberos bits]
HTTP/1.0 200 Document follows
...
Content-type: text/html
\r\n
<HEAD>...</HEAD><BODY>...</BODY>
Example of IN-BAND Authentication
=================================
client:
GET /document HTTP/1.0\r\n
...
Authorization: PK-reverse key="987f98e987a987b987c98"
\r\n
server:
HTTP/1.0 200 Document follows
...
Content-type: text/html
\r\n
<HEAD>...</HEAD><BODY>...</BODY>
Cheers!
--
wa | Wayne Allen, EINet - [email protected] FAX: (512)338-3897
| MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759 (512)338-3754