Improved support for password/principal expiration

[Ken Hornstein]

>Hmmm...the only "application" that can really interpret it is the kgicp()
>code, isn't it?

Depends on the API you're using.  With krb5_get_init_creds_*(), yes.
With the old krb5_get_in_tkt() API you get the krb5_kdc_rep back as one
of the arguments, so you can peek at last_req fields or key-exp yourself
(which is what I used to do).  And when I say "application", I really
mean any client code.

>I don't really understand how the client is supposed to interpret what
>the KDC means...

Heh, well, therein lies the problem :-)

>> Ah-ha, I had forgotten ... there is already a last-req entry allocated
>> for account expiration!  Password expiration has a lr-value of 6, and
>> account expiration has a lr-value of 7.  So there you go; you've
>> already got a spot in the protocol.
>
>Shall I code it up, or do you want to? :->

Unfortunately, I'm waaay too busy right now, so it would probably be better
coming from you.

>At this point, then, I don't know what to do with the key_exp field, except
>ignore it I suppose.

I think that's safest, personally.

>I believe I can patch it myself if necessary...any thoughts on running 
>the 1.3 code in production :-> ?

I think it's a little early myself, since it is only in alpha.

>Ok -- does anyone on the list want me to take this over to krb5dev , or is this
>discussion enough?

I think maybe proposing the change on krbdev can't hurt.

--Ken