Password change protocol rework, round 2

[Nicolas Williams]

On Wed, Mar 10, 2004 at 11:20:10AM -0500, Ken Hornstein wrote:
> >I tend to agree with Nico: in this instance retransmit a new request.
> 
> Hm, well, I thought Nico said in his email, "The client could make a
> new request, but retransmission is probably better."

Sam and I are in agreement about the replay (not reply) cache I think.

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

See below though.

> Aside from library abstraction-violation and common codepath issues,
> I've realized it won't really work.  If you have a password history
> (and almost everyone I know that actually expires passwords does), and
> the reply packet is dropped, the server will see a reused password and
> return a "password reused" error.  So the user would get an error back
> saying "Password is in the password history", but the password would
> actually get changed.  That seems rather suboptimal.

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.

So the only heuristic the client has is KRB5_KPASSWD_SOFTERROR -> maybe
the previous request got processed.

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

> but the server doesn't implement a lookaside cache.  I wonder what
> MS does.
> 
> I guess what to do in case of retransmission should be in the
> specification, eh, Nico? :-)

The new protocol should not use UDP -- you've convinced me of it!

Actually, we can have a similar problem with TCP, so I should not bash
UDP too much.

Nico
--