[OpenAFS-devel] token passing in modern ssh?

[Jeffrey Hutzelman]

On Monday, December 13, 2004 13:15:16 -0500 Jim Rees <rees@umich.edu> wrote:

>   I am very confused by this statement.  In what way does MIT prevent you
>   from obtaining TGTs in multiple realms?
>
> Of course it's possible.  What I said was that MIT didn't think it would
> be useful.  If they had, they would have provided an api, or allowed
> multiple tgts in a single cache.

You can have multiple TGT's in a single ccache.  What you can't have is 
multiple tickets, and especially multiple TGT's, belonging to different 
principals.  This is not because "MIT didn't think it would be useful", but 
because allowing that would require solving difficult problems related to 
defining what the behaviour is when you request a service ticket that is 
not already in the ccache.  Particularly, it would require defining which 
TGT is used to request the service ticket, when there may be multiple TGT's 
in the ccache or obtainable via cross-realm from different initial tickets 
or, on some platforms, by prompting the user to obtain new tickets for a 
realm for which there is not currently an initial TGT in the ccache.

It is not at all clear what the correct behaviour would be in these cases, 
and it matters because the answer affects what client principal name will 
appear on the resulting tickets, and because it may affect whether and when 
the user is prompted to enter a principal name and password in order to 
obtain initial tickets for an additional realm.

The use of multiple credential caches, each potentially containing tickets 
belonging to a different principal, is supported on all platforms.  On 
those platforms where a GUI is provided, there is an interface allowing the 
user to select from among several ccaches or establish a new one.  The 
effect is that the user can control which initial ticket, and therefore 
which identity, is used for each operation.


At this point, I think this discussion has gone rather beyond the scope of 
openafs-devel.  If we're going to continue, it might be appropriate to move 
to the kerberos or krbdev mailing lists.

-- Jeff