password change protocol implementation

[Ken Raeburn]

Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:
> 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.

Cool.  Yeah, RPC is probably best left alone until we can just replace
the implementation.

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

Sounds good.  I've got a suggestion, though, and I apologize for
taking so long to send this out.

The KDC code already has code for binding to each interface, managing
the select loop, calling out to a processing routine, and sending the
response back to the client, and it supports IPv6.  If that could be
adapted to work in the chpw server, that gives us one piece of code to
maintain instead of two.  It also gives us one place instead of two to
implement enhancements, like Mark Eichin's request for a means of
specifying the addresses to be used instead of using all available
addresses (ticket #987, actually for krb524d, which could also stand
to use the same socket management code), or support for socket option
IPV6_PKTINFO (RFC 3542).

Ken