Password change protocol rework, round 2

Nicolas Williams 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
happen.

> >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.

Nico
-- 


More information about the krbdev mailing list