Different Services, Different Realms, but One Host

[Tim Alsop]

Jack,

The process works something like :

1. User enters logon details at workstation
2. Workstation kerberos client requests initial tgt from REALM0 (krbtgt/REALM0 at REALM0)
3. User has now authenticated against REALM0
4. You run a client application which needs to send your principal name to service2 on server1.domain.com. This service is using REALM2.
5. The client application needs to request a service ticket called service1/server1.domain.com at REALM2 from the KDC it knows about (i.e. REALM0). 
6. The KDC for REALM0 recognises that the service ticket request is for REALM2 so it uses its trust relationship to send back to workstation a new cross realm tgt (krbtgt/REALM2 at REALM0)
7. The workstation sends a fresh service ticket request to REALM2 using the cross realm tgt issued by REALM0 KDC.
8. The KDC for REALM2 responds with a service ticket
9. The service ticket can be sent to the server by the client application.
10. The service on the server decrypts the service ticket to determine the principal name of the user who authenticated at the workstation.

The bit that may be causing you an issue is step 5. It is necessary for the client application to be aware of the full service principal name of the service it is trying to communicate with.

Perhaps, if you can advise what the application is I can let you know how to make it request the correct service ticket ?

Thanks, Tim. 

-----Original Message-----
From: ms419 at freezone.co.uk [mailto:ms419 at freezone.co.uk] 
Sent: 11 March 2004 20:15
To: kerberos at mit.edu
Subject: Re: Different Services, Different Realms, but One Host

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


________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos