Thus wrote:
>Steve Heaney writes:
>> I havn't followed the discussion in great detail and I know nothing about
>> the issues of authorization. However, I know I would definitely feel better
>
>> about any solution that used schemes (like Kerberos) that were already in
>> (wide) use. The advantages should be obvious.
>
>Is Kerberos really in wide use? If so, where? (I have no idea...)
>
>Marc
>
Kerberos V4 is certainly in wide use in lots of places, even here.
Kerberos V5, however, is needed to be even marginally tolerable for
WWW applications (V4 requires n^2 secret keys where n is the number of
administrative domains, and is thus not scalable.) Kerberos in
general is, IMHO, not sufficiently scalable for WWW purposes for
reasons I think I've blathered about before enough.
- Marc
--
Marc VanHeyningen [email protected] MIME, RIPEM & HTTP spoken here
What I beleive Marc means here is that, for V4, if one has 100
Kerberos realms which inter-authenticate, then each realm must have 99
database entries, one for each of the other realms. V5 changes this so
that the inter-authentication relationships are hierarchical. For
reasons I'll get into later, I don't think the difference is that
important. Some experts feel that the V5 setup is *not* a good idea,
as it places more dependency links in the security chain. A weak link
in the chain places parties on either side at risk.
A "weak link" can be a realm which has shoddy procedures for obtaining
Kerberos identities, or poor security on the host computer where the
Kerberos database resides. For example, in a university setting, an
academic department might simply send a list of people to the
computing center via campus mail to obtain kerberos identities for
their students. It might be fairly easy for someone close to the
process to obtain an "extra" identity with which to illegally access
data.
At the other end of the spectrum, EINet requires a sequence of events
and verifications to occur before an identity is issued and later,
activated. For example, a corporate user's identity must be vouched
for and counter-signed in writing by an appointed corporate contact.
The application and returned identity are sent by receipt mail or
bonded courier, and contractual instruments make the corporation
liable for damages tracable to a corporate identity. The EINet
Kerberos databases themselves are on secure (C2) computers on secure
sub-nets, within *very* secure facilities. The point here is that the
nature of a Kerberos-authenticated identity in the EINet realm may be
quite different from identities in other realms.
In order for EINet to inter-authenticate with another realm, we would
not only have to be satisfied as to the other realm's policies,
procedures and physical security measures, we would also require a
contractual relationship to protect EINet customers, as well as periodic,
bilateral inspections to insure compliance.
All this is leading to a point about the supposed need for an
authentication mechanism to scale to the entire Web user community. In
terms of inter-authenticating Kerberos realms, this is simply not
necessary. As to the notion of having hundreds or even thousands of
inter-authenticating realms, well, "that dog don't hunt" (as our
President might put it :-). In most scenarios involving access
control, there are relatively limited audiences for secure
information. There are, in fact, natural limits to how large an
audience can be before the data can no longer be considered secure.
Just look at how good our government is at leaking information to the
press. The same effect is true in authentication - an identity is
meaningless if there are too many inter-authenticating realms. There's
just too many links in the chain.
I think actual scenarios of access control on a large scale would be
interesting to discuss. Perhaps the issues would clarify in a more
concrete context.
Cheers, and have a good weekend (er, um, well, by the time you
read this, I hope you *had* a good weekend :-).
--
wa | Wayne Allen, EINet - [email protected] FAX: (512)338-3897
| MCC/ISD, 3500 West Balcones Center Dr, Austin, Tx 78759 (512)338-3754