Improved support for password/principal expiration

[Ken Hornstein]

>Very cool -- so then I assume that if this is the standard way to do this,
>the prompts sent back when checking key_exp should be changed to something
>like 
>
>	"This account will expire in %d <whatever>s"
>
>right?

If only it was that simple.  RFC 1510 says:

key-expiration

	The key-expiration field is part of the response from the KDC
	and specifies the time that the client's secret key is due to
	expire.  The expiration might be the result of password aging
	or an account expiration.  This field will usually be left out
	of the TGS reply since the response to the TGS request is
	encrypted in a session key and no client information need be
	retrieved from the KDC database.  It is up to the application
	client (usually the login program) to take appropriate action
	(such as notifying the user) if the expiration time is
	imminent.

The second sentence is the killer here.  It means that key-expiration
has double duty; it can be EITHER account expiration or password
aging.  Different implementations interpret this different ways.  The
RFC 1510 revision has similar wording.  I don't really have a good idea
what would make sense for determining account expiration, other than to
suggest another last-req field maybe isn't a bad idea.

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.

>Are you saying this change won't go into the 1.3 code release, or that
>it's just not in the alpha currently?

If you're talking about the client code, it's in 1.3 and the alpha today.
If you mean the KDC code, it won't be in either, because 1.3 has passed
the feature freeze.  Maybe for 1.3.1, but we'll have to see.  However,
the code hooks quite nicely into kdc/kdc_util.c:fetch_last_req_info().

>> varies by site).  The code I wrote lets you set a KDC-specific variable
>> that controls the threshold for password expiration notification.
>> Since the last-req field is optional, not sending means "don't display
>> the password expriation warning".
>
>Ok, would this be set in kdc.conf or through kadmin?

In my implementation, kdc.conf.

>Hmmm...I meant customization of the banner sent to the GIC prompter, so
>it would be client side -- the KDC interaction would stay relatively
>unchanged...something in krb5.conf?
>
>[libdefaults]
>   gic_princ_exp_msg = /usr/local/etc/krb5/princ_exp_msg
>   gic_pass_exp_msg  = /usr/local/etc/krb5/pass_exp_msg
>
>Contents of /usr/local/etc/krb5/princ_exp_msg :
>
>	Information on renewing accounts can be found at
>	http://www.my.domain.com/accounts/renewals .
>
>Contents of /usr/local/etc/krb5/pass_exp_msg :
>	
>	Information on changing your password can be found at
>	http://www.my.domain.com/accounts/passchange .

Seems reasonable to me.

>Sure, and this would mean str*cat'ing one message onto the banner containing
>the other if both messages were to be displayed. I don't think it's hugely
>more complicated -- what do you think?
>
>I could try to code some of this up if you'd like.

I think it sounds fine, but I'm not the one you have to convince, since I'm
not part of the MIT Kerberos development team.  You might want to chat
with them (I know they're on this list, I just don't know how busy they
are).

--Ken