[3881] in Kerberos
Re: hierarchical realms
daemon@ATHENA.MIT.EDU (Joe Ramus)
Wed Sep 21 01:16:55 1994
Date: Tue, 20 Sep 94 18:00:36 PDT
From: ramus@nersc.gov (Joe Ramus)
To: kerberos@MIT.EDU, orion@iastate.edu
>> To: kerberos@MIT.EDU
>> Date: 20 Sep 1994 13:24:13 GMT
>> From: orion@iastate.edu (Phi H Truong)
>> Organization: Iowa State University, Ames, Iowa (USA)
>> Sender: usenet@cam.ov.com
>>
>> Not everything works well with cross-realm authentication. It's kind of
>> messy to have a kerberos server for each sub-realm not to mention
>> ridiculous. Don't know about Kerberos V but we have tried K4's
>> cross-realm and we hated it. Our master kerberos known only one realm:
>> IASTATE.EDU. Everything else got map into that through krb.realms, for
>> example:
>>
>> .vincent.iastate.edu IASTATE.EDU
>> .cc.iastate.edu IASTATE.EDU
>> .iastate.edu IASTATE.EDU
>> .admin.iastate.edu IASTATE.EDU
>> .adp.iastate.edu IASTATE.EDU
>> .aeem.iastate.edu IASTATE.EDU
>> .aero.iastate.edu IASTATE.EDU
>> .agron.iastate.edu IASTATE.EDU
>> .al.iastate.edu IASTATE.EDU
Kerberos 5 works well with cross-realm authentication.
We have submitted patches to MIT to fix some bugs.
The sub-realm case shown above is only the tip of the iceberg.
What about a case where you have different organizations that
each manage a Kerberos server? You cannot map that to just one KDC.
With Kerberos 5, the realm names do not need to be hierarchical
(but they can be). And each KDC only needs a cross-realm key for
the immediate neighbors (it scales by n). With Kerberos 4, each
KDC needed a key for every other KDC (scales by n squared).
For example, several National Labs each operate their own Kerberos
server. With cross realm authentication, the Livermore Lab (LLNL.GOV)
can accept an authenticated request from the Argonne Lab (ANL.GOV).
----------------------------------------------------------------
| Joe Ramus NERSC Livermore (510) 423-8917 ramus@nersc.gov |
----------------------------------------------------------------
