Improved support for password/principal expiration

[Ken Hornstein]

>Currently, Kerberos cannot notify users of both impending principal 
>expiration and impending password expiration due to the fact that 
>there is only one field (key_exp) in struct _krb5_enc_kdc_rep_part {}.

I'm ahead of you there, James :-)

I noted this problem years ago, and I convinced the good folks in the
IETF Kerberos WG to utilize an already-existing field in the AS_REP to
unambigiously indicate password expiration.  The field in this case is
one of the "last-req" fields.  This is actually already been implemented
_on the client side only_ in the 1.3 alpha code (look at gic_pwd.c:327).
This gives the KDC the ability to _unambigiously_ indicate password
expiration to clients.  Because of time issues I wasn't able to get
the KDC-side support in there, but it's a small change.

>Looking through the code, it seems that it may be possible to add
>another field to struct _krb5_enc_kdc_rep_part (e.g. princ_exp) at 
>the end and to the asn1_encode/asn1_decode routines (as each field takes 
>a field number) without causing problems with implementations that don't 
>have this functionality. However, before I start doing anything, I'd love 
>to know from the experts if this will break existing implementations when 
>talking to a KDC modified in this way.

Unfortunately, a protocol extension like this really should be run
through the IETF Kerberos working group.  And given my participation in
this group, I can tell you that existing Kerberos implementations can
behave very badly if they get ASN.1 fields that they're not expecting.
That's why at the time I choose to utilize an already-existing field
rather than add my own.  I cannot speak for MIT, but I would doubt
very much that they would accept code that created a new ASN.1 element
in an AS_REP without it going through the IETF process and everyone
thoroughly understood the backwards compatibility issues.

>	- ability to configure when warning messages are sent back. Currently,
>	  it's seven days, but with the enhanced notification ability, I may
>	  want to set password expiration notification to occur within a month 
>	  of expiration, while I may set principal expiration notification to
>	  occur a semester before the account expires to give people fair
>	  enough warning.

As implemented, the GIC prompter will always display the password
expiration warning if the KDC elects to send it.  The idea here is that
you can easily customize the warning interval on the KDC (I have it at
a week here on our KDC, but obviously the amount of time you want
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".

>	- ability to customize the messages sent back, say, including a web
>	  page for instructions on how to renew an account to prevent the 
>	  principal expiration at the end of the semester.

Sigh.  Unfortunately, this ends up being very complex in practice, since
sending back a display string opens up the whole internationalization
mess.  I personally think your best bet here is to work on a client-side
configuration (as much as I loath client-side configuration, I don't see
a reasonable alternative here).

>Currently, accounts stay open by default until I expire them (3 times a
>year), but I would rather the default be than an account will expire unless 
>the user renews it. This way, old accounts don't stay open if I miss one
>:-> However, this functionality really requires that the user be well 
>informed of when the account will expire, along with the means to prevent
>the expiration. Since I plan on using password expiration as well, the 
>above modifications would probably be necessary to make such a scheme
>work well.

Right, and here is a case where there really is a difference between
client expiration and password expiration, so that makes everything more
complicated (since most people are only interested in password expiration).

--Ken