Different Services, Different Realms, but One Host

[ms419@freezone.co.uk]

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