Integration of k5start/krenew functionality

[Ken Raeburn]

On Aug 1, 2009, at 15:44, Greg Hudson wrote:
> I thought about this as well.  There's a certain elegance in having a
> credentials cache which is actually a cache, backed by a key in a  
> keytab
> which can be used for AS requests, but I think the full design would  
> run
> into some uncomfortable questions which are better answered outside of
> libkrb5.

Yeah, there are issue to be settled.

>  For instance, when the caller asks for a service ticket, how
> long should the TGT have left in it for us to use the existing TGT
> instead of requesting a new one?

I'd say either 0 or $clockskew.  For anything more, in "normal" cases  
we'd ... uh, well, maybe we'd use "klist" enhanced with the "-H"  
option from Russ's tools, and if it fails, run "kinit" to forcibly  
renew the credentials *now*.  That could still be done, though I'm not  
sure how we'd work the UI if the keytab+ccache thing were done with  
just a new ccache type.  If it's a new datum in an existing ccache  
type, we could just have kinit look for that datum and bypass the  
whole password-asking step.

I don't recall if minimum remaining lifetime (or in absolute terms,  
earliest expiration time) is one of the attributes that can be  
specified for fetching credentials.  If it is, or it can be supported,  
that would be a way for an application to specify that it wants  
credentials valid for at least X time.

>  When doing an AS request, what
> parameters do we use, and do we want to use FAST or PKINIT or any  
> other
> preauth?

That's probably an argument for attaching some (extensible) datum in  
the ccache, instead of just pairing a keytab and a ccache.

Ken