password change protocol implementation

Ken Hornstein kenh at cmf.nrl.navy.mil
Fri Feb 13 14:29:36 EST 2004


I'm in the process of finishing IPv6-ifying the remaining few Kerberos/app
protocols that don't have IPv6 support in MIT Kerberos 1.3.1.  Other
than the admin RPC protocol (which I think I'm going to punt on), the
last one left is the password change protocol.

I started looking at this again, and I realize that, frankly, the
implementation is a mess.  Specifically, it does the exact opposite of
what every sane UDP-based protocol implementation does, and instead of
the server binding to each interface address, it binds to INADDR_ANY
and expects the client to use an unconnected socket to receive replies.

I would like to clean this mess up, make the chpw server bind to each
interface, and simplify the client code to simply use one socket
instead of the two it uses now.  In terms of backwards compatibility,
it seems to me the only problem is a "new" (connected chpw client
talking to an "old" multihomed server, and I'm not convinced that's
really enough of a corner case to care.  Obviously, I'd do IPv6 support
at the same time, and directional addresses (but it seems to me that
all you need for directional address support is the approrpriate #ifdef
in krb5.h - it looks like everything else is generic enough to support
it). 

Would MIT accept such a rewritten chpw client and server?

Hm, I can think of one "interesting" problem.  How does one migrate to
directional address support for protocols that use KRB_PRIV or
KRB_SAFE?  For IPv6, it's easy, but I'm not sure how the chpw client
can discover whether or not a server can support a directional address
bit for IPv4.  I suppose the implementation could only use the
directional address type for IPv6, but that seems sub-optimal.

--Ken


More information about the krbdev mailing list