Password change protocol rework, round 2

Nicolas Williams Nicolas.Williams at
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 ...
> retries.
> 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 mailing list