Password change protocol rework, round 2

[Nicolas Williams]

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

Nico
--