[23754] in Kerberos
Re: Cross-Realm Authentication
daemon@ATHENA.MIT.EDU (Saber Zrelli)
Fri Apr 22 04:08:08 2005
Date: Fri, 22 Apr 2005 17:06:49 +0900
From: Saber Zrelli <zrelli@jaist.ac.jp>
In-reply-to: <5176d82c28c136ed148b4598ff1ab6cc@mit.edu>
To: Ken Raeburn <raeburn@mit.edu>
Message-id: <20050422080649.GA11901@mlserv.jaist.ac.jp>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
Content-Transfer-Encoding: 8bit
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
Hi ,
I would like to thank you, Ken, for these explanations ,
and sorry to be a third man, I have some questions and comments about
cross-realm authentication.
* Ken Raeburn (raeburn@MIT.EDU) wrote:
>
> The telnet is to a host named foo.example1.com, in Kerberos realm
> EXAMPLE1.COM (which is what one would expect from the names, but that
> isn't *always* the way it's set up).
> "host/foo.example1.com@EXAMPLE1.COM" is the name of the service
> principal used by the telnet server.
How does the telnet client knows the service name that corresponds
to the telnet server in the host foo.example1.com
foo.example1.com <--> host/foo.example1.com@EXAMPLE1.COM
>
> "krbtgt/EXAMPLE.COM@EXAMPLE1.COM" is created in both databases (that on
> the EXAMPLE KDC and that on the EXAMPLE1 KDC), and must have the same
> key in both.
Why does the krbtgt principals have to use same key,
is it design choice for the cross-realm operations ?
> The telnet program run by the user on bar.example.com (no
> "host/bar.example.com" principal needs to exist anywhere, in this
> example) contacts the EXAMPLE.COM KDC, sending the user's
> ticket-granting ticket and requesting a ticket for the service
> krbtgt/EXAMPLE1.COM@EXAMPLE.COM (not host/kdc.example1.com), which that
> KDC issues.
The kerberized telnet program knows that the host foo.exemple1.com is
in the domain EXEMPLE1.COM according to the configuration file on the client's
krb5.conf file ? or is it translated automatically from the domain name example1.com
>
> Another way to think about it is: The ticket is essentially a message a
> KDC gives to the client to give to a server, which tells the server who
> the KDC thinks the client is. (With a bunch of encryption stuff
> happening to prevent forgery of the messages.) So, by way of the
> telnet (or ftp) client, the KDC for EXAMPLE.COM tells the KDC for
> EXAMPLE1.COM "this guy is darren@EXAMPLE.COM", so that second KDC
> produces another message telling the telnet server, "the KDC for
> EXAMPLE.COM says that this is darren@EXAMPLE.COM".
>
> The messages always
> go by way of the client program; the KDCs don't talk to each other or
> to the telnet service.
from now , it's just comments about kerberos cross-realm operations ,
About kerberos corss-realm operations, I think that the fact that clients
communicate directly with foreign KDCs is not safe, IMHO the cross-realm
operations would be better if only the KDCs are involved to obtain service
ticket for the clients.
>
> (By the way, this process can be repeated through KDCs for multiple
> realms, but don't think too much about that until you understand the
> two-realm case well.)
In the case where the KDCs involved in the cross-realm authentication does
not share keys, the protocol seems to be non optimal and the client is
involved whereas the KDCs could just communicate with each other in a
recursive manner and provide just the final result to the client.
About roaming situations ,
If a client principal in realm R-A visits a foreign realm R-B , to be able
to access resources in R-A, the kerberos protocol have to proceed as if the
client was located in his home realm. This will involve several problems I
think. That is why maybe kerberos may not be adapted to roaming situations
and in access networks.
I would appreciate very much your comments.
Best Regards.
--
Saber ZRELLI <zrelli@jaist.ac.jp>
Japan Advanced Institute of Science and Technology
Center of Information Science
Shinoda Laboratory
url : http://www.jaist.ac.jp/~zrelli
gpg-id : 0x7119EA78
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
