Password change protocol rework, round 2
Nicolas.Williams at sun.com
Tue Mar 9 17:57:31 EST 2004
On Tue, Mar 09, 2004 at 05:44:02PM -0500, Ken Hornstein wrote:
> As previously discussed, I've worked up what I think is a reasonable
> implementation of directional address types, based on Sam's outline. So
> far, no problems.
> As some people may remember, the whole purpose of this exercise is to get
> IPv6 support in the password changing protocol (and clean up everything
> associated with the implementation).
> While I was doing that, I realized that it would be much simpler and easier
> to simply use krb5int_sendto() instead of the code that handles this
> explicitly in changepw.c. But then this brings up another sticky problem ...
> 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."
> but the idea of it makes me uncomfortable. Another alternative is to use
> a lookaside cache, like the one found in the KDC, but that's a significant
> amount of code. But it's clear to me that we need to improve over the
> current situation (one UDP request, no retries).
> Comments? Other ideas?
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?
Kpasswd clients should not retransmit :)
More information about the krbdev