Password change protocol rework, round 2

[Ken Hornstein]

>> Well ... I don't think so.  "replay" really is more appropriate here.
>
>No, the kpasswd protocol MUST be replay protected, otherwise bad things
>happen.

Really?  I guess it's not obvious to me what the dangers are of a
replayed password change attempt (since presumably an attacker doesn't
know the session key to put a new password in the KRB-PRIV).  But I
just realized one thing ... if you have a password history, a
retransmitted password change request will fail, so clearly the only
option is a lookaside cache.

>In any case, this is what we have today.  Retransmission for kpasswd is
>not something anyone's asked for before, to my knowledge.

Well, I suspect the person who implemented that code didn't actually
have a large user base that had password expiration set ... otherwise
they'd realize that it doesn't work so well :-/  I'm not sure why
a retry loop wasn't implemented ... but I do know that not having one
is wrong.

--Ken