Improved support for password/principal expiration

James F.Hranicky jfh at cise.ufl.edu
Fri May 2 16:36:07 EDT 2003


On Fri, 02 May 2003 16:04:42 -0400
Ken Hornstein <kenh at cmf.nrl.navy.mil> wrote:

> 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.

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

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

> 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? :->

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

> 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().

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

> >Ok, would this be set in kdc.conf or through kadmin?
> 
> In my implementation, kdc.conf.

Ok, that's fine.
 
[customization of prompter]

> Seems reasonable to me.

Great.

> >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).

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

Jim


More information about the Kerberos mailing list