Password change protocol rework, round 2
kenh at cmf.nrl.navy.mil
Tue Mar 9 18:43:15 EST 2004
>> Well ... I don't think so. "replay" really is more appropriate here.
>No, the kpasswd protocol MUST be replay protected, otherwise bad things
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
More information about the krbdev