[6] in WWW Security List Archive
[rosenthl@mcc.com: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD]
daemon@ATHENA.MIT.EDU (yandros@MIT.EDU)
Fri Aug 12 14:44:06 1994
From: yandros@MIT.EDU
Date: Fri, 12 Aug 1994 14:44:03 +0500
To: www-security.discuss@charon.LOCAL
Date: Fri, 12 Aug 94 11:06:00 CDT
From: rosenthl@mcc.com (Doug Rosenthal)
To: Lei_Tang@GS59.SP.CS.CMU.EDU
Cc: www-security@ns1.rutgers.edu
In-Reply-To: Lei_Tang@gs59.sp.cs.cmu.edu's message of Fri, 12 Aug 94 11:55:59 -0400 <2908.776706959@GS59.SP.CS.CMU.EDU>
Subject: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD
If the server and the client are in the same realm(kerberos name),
it is OK since the TGS knows the secret key of the server. But if the
client and the server are not in the same realm(that is the most often
case in Internet), the server must share some secret with TGS to
gurantee privacy and integrity.
Actually, the two *realms* must share a key (in v4, or have
hierarchical realms with v5), to enable cross-realm authentication.
Personally, I do not think the on-line service is good because the
on-line certifcate server is a bottleneck and hence affect the scalability of
the system since the system is indended for Internet community.
Also on-line certificate increasing the cost of charging.
(for example, credit card company uses on-line certificate server.
guess what is the cost for using VISA card: $3/per transaction, this number
was from some guy working for VISA, while the cost for check transaction
is 50-60 cents /per transaction.) But the main problem is scalability.
Also you have to think about fault tolerance, what happens if the
on-line service crash? ......
--ltang
The certificate service technology would need to support distributed,
replicated servers, time-to-live on certificate validation, etc. to
deal with scalability, efficiency, etc. There are known solutions to
these problems, i.e. scaling in large distributed systems. For
example, hierarchical Kerberos realms, the DNS, X.500 directory.
- Doug
