Password change protocol rework, round 2
Nicolas.Williams at sun.com
Tue Mar 9 18:27:02 EST 2004
On Tue, Mar 09, 2004 at 06:04:41PM -0500, Ken Hornstein wrote:
> >> 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.
No, the kpasswd protocol MUST be replay protected, otherwise bad things
> >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).
Well, ok, I see your point. The client could make a new request, but
retransmission is probably better.
In any case, this is what we have today. Retransmission for kpasswd is
not something anyone's asked for before, to my knowledge.
More information about the krbdev