Password change protocol rework, round 2

Nicolas Williams Nicolas.Williams at
Wed Mar 10 12:42:37 EST 2004

On Wed, Mar 10, 2004 at 12:19:05PM -0500, Ken Hornstein wrote:
> >I'm happy leaving the client as it is now, but I wouldn't oppose/mind
> >a retransmission strategy and a reply cache on the server.  But
> >evidently we don't really need this, else it'd long ago have been added
> >:)
> I'm sorry, you're wrong.

Yes, I was wrong.  Thanks, this is good stuff.

> >Ah, the error reply should give the client something it can use to
> >conclude that its previously unanswered request was actually processed.
> >Barring simultaneous password change attempts by the same principal this
> >can be done.
> >
> >Both, "password reused" and "pw change came too soon" do that.  Except
> >that these errors are represented as implementation-specific strings in
> >the error reply.  Sigh.
> And even that isn't quite good enough ... because I can't see how to
> distinguish on the client between these two cases:
> - Reply packet got dropped, request is processed twice on the server,
>   "password reused" is sent the second time, password is changed.
> - Request packet got dropped, request is sent the second time, but the
>   password is rejected because the one the user entered really was
>   in the password history.

Not much we can do here other than do reply caching.

We should make sure that the new protocol does address this problem, one
way or another (preferably without reply caching).

> >> I see that Heimdal actually retransmits a new request every time ...
> >
> >A new request is not a retransmission -- the new request won't hit a
> >request-reply cache.
> Right, so arguably, that's not completely correct.

Right.  So, a reply cache would be a good thing then.

> >The new protocol should not use UDP -- you've convinced me of it!
> Hey, you've got no argument from me!  I've never understood why the
> original protocol used UDP anyway.  And if I use krb5int_sendto(), then
> TCP support comes for free.
> So, is everyone happy with:
> - "Standard" retransmission on the client.
> - Replay and reply (lookaside) cache on the server.

I am.


More information about the krbdev mailing list