password change protocol implementation

[Ken Hornstein]

>> 	krb5_auth_con_init(ctx, &actx);
>
>> 	krb5_auth_con_setflags(ctx, actx, KRB5_AUTH_CON_DO_SEQUENCE);
>                [optional]

Actually ... that's not true, depending on the current flags in your
auth context.  Specifically, if you're on a server, you likely have
a replay cache set (CONTEXT_DO_TIME), and you need to clear it.  And
if you're not using sequence numbers, I'm wondering what gain you
get from using mk_priv() at all, actually ...

>> 	krb5_auth_con_setaddrs(ctx, actx, ...);
>> 	And then there's the whole lossage that you really only want
>> 	the "local" address on the mk_priv side, and you want the
>> 	"remote" address on the rd_priv side.
>
>          Ick.  Try just:
>            krb5_auth_con_genaddrs(ctx, actx, fd, flags);

How do you do that with a connectionless protocol?  That's also assuming
you even _get_ a fd if you're trying to add Kerberos to an existing
application (most applications I've added Kerberos support to didn't
expose the file descriptor in a reasonable way).

>> So, now ... let's throw in a multihomed server.  Let's also throw in
>> a connectionless protocol.  And if you're behind a NAT ...
>
>          I don't see how multihoming makes it harder,
>          and yes, you'd have to recvfrom if connectionless.

Depending on the client/server (if they were written right, or wrong),
you may get back a reply from a host other than you sent it to.

--Ken