Password change protocol rework, round 2

[Ken Hornstein]

>> Specifically, what do we do about retries on the server?  We could simply not
>> have a reply cache (like the KDC by default).  I don't see any dangers in
>> not having a replay cache on the password changing server at first glance ..
>	       ^^^^^^
>	       I assume you meant "reply."

Well ... I don't think so.  "replay" really is more appropriate here.

>Add an option to krb5int_sendto() to turn off retransmits, or, even
>better, to specify how many restransmits it can do.
>
>If clients don't retransmit then don't cache replies -- just do replay
>caching and ignore replays.  That's what kadmind does today, no?

Yes ... but I'm trying to fix that.

>Kpasswd clients should not retransmit :)

They shouldn't?  Help me out here ... what happens if the request is
dropped?  The client times out, without sending another request?  Or
what happens if the reply is dropped?  Not having some sort of retry in
a UDP-based protocol seems wrong (not to mention extrememly fragile).

--Ken