password change protocol implementation
kenh at cmf.nrl.navy.mil
Fri Feb 13 18:25:24 EST 2004
>> krb5_auth_con_init(ctx, &actx);
>> krb5_auth_con_setflags(ctx, actx, KRB5_AUTH_CON_DO_SEQUENCE);
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.
More information about the krbdev