Different Services, Different Realms, but One Host

[ms419@freezone.co.uk]

Thanks everyone!

I agree, Tim: Being able to store one host's keys in different realms 
would be nice - in my simple opinion.

I think you understand my question exactly - your example is just what 
I'm trying to do. Unfortunately, I still don't know how to do it. 
Truly, the confusing part is how the kerberos client obtains a cross 
realm TGT for the correct realm.

Since your example is precisely what I'm trying to do, suppose I'm 
connecting to service2 on server1.domain.com - my principle resides in 
REALM0, say. How does my kerberos client know whether to request a 
cross realm TGT for REALM1, 2, or 3? It seems domain_realm will only 
map server1.domain.com - and all of its instances - to one realm ...

I'd be very happy to find a way around this!

Jack

On Mar 9, 2004, at 9:36 AM, Tim Alsop wrote:

> Hi,
>
> Perhaps I missunderstand the question, but it is possible to use 
> multiple realms on a specific host. The naming of the service 
> principals (keys for which would be stored in a key table) would look 
> something like :
>
> host/server1.domain.com at REALM1
> service1/server1.domain.com at REALM1
> service2/server1.domain.com at REALM2
> service3/server1.domain.com at REALM3
>
> Essentially, the key in the key table which would be acquired by a 
> specific application (a Kerberos service) maintains the shared-secret 
> between the service and the realm.
>
> A user can be in one realm with one password. The services can be in 
> multiple realms. When an application is run by a user and requests a 
> service ticket it will get the ticket from the appropriate KDC for the 
> realm.
>
>  The part which is perhaps a little confusing is the approach used by 
> a kerberos client to determine the KDC that issues the service ticket. 
> Normally, the service ticket request is sent to the realm where the 
> initial user's ticket (tgt) was issued, and then a cross realm tgt is 
> returned for the service realm so that a service ticket can then be 
> requested from the correct realm. The service ticket is then sent to 
> the service and decrypted with the key in the key table in order to 
> determine the principal name of the user.
>
> So, in summary - having multiple realms works well, but is more 
> complex. The simplest approach is to use one realm for everthing, but 
> this does not have the granularity that some implementations require. 
> It is nice to have the option to use either approach to protect 
> multiple applications on a specific host !!
>
> Regards, Tim.
>
> -----Original Message-----
> From: Sam Hartman [mailto:hartmans at MIT.EDU]
> Sent: 09 March 2004 17:09
> To: ms419 at freezone.co.uk
> Cc: kerberos at MIT.EDU
> Subject: Re: Different Services, Different Realms, but One Host
>
> >>>>> "ms419" == ms419  <ms419 at freezone.co.uk> writes:
>
>     ms419> Pardon this newbish question, but here's the setup: I want
>     ms419> to distribute the keys for one host among two
>     ms419> realms. Basically, I've got a sensitive service running on
>     ms419> a couple of hosts, and a less secure service running on the
>     ms419> same hosts. I want to store the keys for the sensitive
>     ms419> service in one realm, and the keys for the others in
>     ms419> another. Any problems with these premises?
>
> Yes.  Current Kerberos implementations assume a host belongs to one 
> realm.  You'll find it difficult to actually do this.
>
> Also, users will end up having multiple passwords which will be 
> annoying.
>
> I recommend having one KDC which is more secure than your most 
> sensitive service.
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos