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