Password change protocol rework, round 2

[Ken Hornstein]

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

The password change protocol in the MIT implementation is clearly not
used in production by many of the MIT developers.  For example, the
current implementation does not work from behind a NAT, yet there has
been no fixes applied to the MIT tree to address this problem (unlike
the application programs and credential forwarding code).  You're going
to have a hard time convincing me that not having password changes
working from behind a NAT is not necessary.

I even understand this, because MIT doesn't require password expiration
in their environment.  But unfortunately we _do_, and believe me, this
code isn't that robust; we get plenty of support calls when the
password change cycle comes around.  Part of the problem in the past
was we had three different password changing protocols, and the only
one that worked reliably was the RPC-based one.  I was hoping when we
went to a unified password changing protocol, everything would stabilize,
but that hasn't been the case ... and it wasn't until I started digging
in the code that I realized why.

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

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

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

--Ken