multiple realm membership

[Douglas E. Engert]

Randy Turner wrote:

> Hi,
> 
> Thanks for the reply.
> 
> In my original email, it might sound like I'm confusing hosts with  
> users, but I'm not. In my use case scenarios, the device itself has  
> credentials in multiple types of security realms(domains) [Krb5, PKI,  
> legacy username/password, etc.] so when I mix these two metaphors  
> together it's because I'm using devices and end-users in exactly the  
> same way. A device (host) is a user.
> 
> This device/host product is also an embedded product - running Linux  
> or VxWorks, depending on the product SKU. We have ported MIT- 
> Kerberos, Cyrus-SASL, and OpenSSL, among other things, so that it  
> runs on VxWorks as well as Unix/Linux variants.

Cool.

> I'm not sure I can  
> use "rlogind" (as is) in my vxworks build, as you proposed in your  
> email below.

I was not suggesting to use rlogin, only that the MIT rlogind had
the server side behavior you were looking for, but the gssapi
implimentation did not yet have it but could.

> 
> Also, I understand I can parse out the realm name from the overall  
> principal spec in the ticket, but I thought I had to know what keytab  
> entry to use to decrypt the ticket in order to get the principal name  
> (chicken and egg thing). I couldn't remember if the entire principal  
> string was available to me in unencrypted form.

The libraries take care of all of this for you. If you really want to
see what is going on, look at an Ethereal network trace and you can see the
parts of the AP_REQ.

> 
> Thanks,
> Randy
> 
> 
> On Feb 16, 2006, at 9:43 AM, Douglas E. Engert wrote:
> 
> 
>>
>>Randy Turner wrote:
>>
>>
>>>Hello,
>>>I was wondering if the following use-case for Kerberos is valid:
>>>I have a host that wants to be a member of multiple realms   
>>>simultaneously.
>>>When a host boots, it will obtain TG tickets from all ticket- 
>>>granting  servers that it is configured to know about. Essentially  
>>>logging into  to all realms for which the host has valid credentials
>>
>>Basic Kerberos does not work that way. The host does not get TGTs.
>>It does not login.  Users get TGTs when they login or do a kinit.
>>
>>
>>>This is all that has to be done if the host has no kerberized   
>>>services that it wants to offer. At this point, if there is a  
>>>client  application on the host that wants to connect to a remote  
>>>service in  one of the realms, it selects the right TGT to use and  
>>>obtains a
>>
>>It selects the user's TGT  from the ticket cache, Normally a usee
>>has only one, and it is pointed at but the KRB5CCNAME env variable.
>>SO you could juggle these if needed.
>>
>>
>>>ticket from the KDC/TGS that is associated with the target realm.
>>>If a host wants to offer kerberized services to potential  
>>>clients,  these clients could be attempt to access the services  
>>>from any of the  realms for which the host is a member. I'm  
>>>assuming this means the  host would have to keep <n> keytabs that  
>>>are sync'd with the KDC from  each realm.
>>
>>The host's keytab entries from different realms can all be in the same
>>keytab if you want.
>>
>>
>>
>>>Also, if a remote client sends a service ticket  requesting access  
>>>to a service, the host needs to know from what  realm the request  
>>>is coming from in order to select the right keytab  to decrypt the  
>>>ticket.
>>
>>It knows what realm it is from as that is part of the principal:
>> <service>/<hostname>@<realm>
>>
>>Is there unencrypted portions of the ticket
>>
>>>that can be used to find out from what realm the request is  
>>>coming  from ?
>>
>>Yes, see http://www.ietf.org/rfc/rfc4120.txt
>>
>>
>>>I guess I'm curious if there are precedents for having a host   
>>>maintaining simultaneous connectivity to multiple realms and have  
>>>a  set of username/password credentials for each of these realms?
>>
>>
>>Host's don't normmaly have username/passwords. They have service
>>principals and keys.
>>
>>But if I think I know what you are asking, yes a host can have  
>>multiple
>>keytab entries from different realms, which is handy while moving a  
>>host
>>from one realm to another.
>>
>>
>>>I'm curious if MIT-Kerberos even supports this type of scenario?
>>
>>Yes, the rlogind will do this using any host/<hostname>@* entry
>>found in the keytab. but the gssapi may or may not depending on
>>how the gss_accept_sec_contect was called. It my only
>>accept for the default realm. There are mods to get around this.
>>
>>
>>>Thanks in advance for any insight into this use case?
>>>Randy
>>>________________________________________________
>>>Kerberos mailing list           Kerberos at mit.edu
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>-- 
>>
>> Douglas E. Engert  <DEEngert at anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois  60439
>> (630) 252-5444
>>
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444