Different Services, Different Realms, but One Host

Sun Mar 14 04:05:00 EST 2004

Jack,

I am not aware of any such product that uses a directory for this purpose. The main reason for this is because multi-realm deployments are not as common as single-realm deployments. Most products are created to meet the needs of the majority.

If you contact me offlist I would like to suggest a few options to you if you are interested to explore this further.

Thanks, Tim. 

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

Alright! Thank you sincerely for all the helpful and precise information! That's one problem with an answer ...

PS. Are you aware of any products - ssh or otherwise - which use a directory service to resolve the realms of SPNs - based on both the service name and the FQDN?

Jack

On Mar 13, 2004, at 6:18 AM, Tim Alsop wrote:

> Ok,
>
> The service address lookup is dependant on the actual ssh product you 
> are using. The product I am familiar with guesses the name of the 
> service principal by prefixing it with "host/" and then adding the 
> target hostname. The realm is based on the default realm of the local 
> system. This is not a very flexible approach since it will not work in 
> multi-realm architecture like yours. You therefore need to talk to the 
> supplier of your ssh product and see if they have a way to configure 
> the SPN (service principal name) for a target system so that you can 
> tell the ssh client which realm to use in the request.
>
> Thanks, Tim.
>
>  -----Original Message-----
> From: ms419 at freezone.co.uk [mailto:ms419 at freezone.co.uk]
> Sent: 13 March 2004 12:15
> To: Tim Alsop
> Cc: kerberos at mit.edu
> Subject: Re: Different Services, Different Realms, but One Host
>
> Ahh ... I'm getting the picture ...
>
> How about ssh, for starters? Most of host.blue's keys are in BLUE, 
> though host/host.blue is in RED. So ssh need's to get 
> host/host.blue at RED ...
>
> Thanks again for all the help!
>
> Jack
>
> On Mar 11, 2004, at 2:59 AM, Tim Alsop wrote:
>
> > 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 10:48
> > To: Tim Alsop
> > 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