password change protocol implementation

[Ken Hornstein]

>Then we are interested in well-written patches to make the password
>client use a connected socket and the password server bind to all
>addresses, but not your implementation of directional addresses for
>the password server or client.

I can do that, no problem.

>An implementation plan for proper directional address support that may
>happen to meet your resource constraints follows.
>
>In krb5_rd_cred, krb5_rd_priv, and krb5_rd_safe, compare both against
>the address in the context and the appropriate directional address.
>If either comparison is successful, the address check is successful.
>You may need to add a flag to the authcontext to indicate whether
>mk_priv was called.

Hm.  Well, my big concern was against a major API implementation, but
maybe this isn't so bad after all.  Just so I understand ... you mean
add a flag to indicate whether or not mk_req was called, _not_ mk_priv,
right?  I ask because I understood that the determining of the "direction"
was based on who issued the AP_REQ.

>I'm actually not sure whether krb5_rd_cred should accept directional
>addresses; I believe clarifications speaks to this but don't remember
>what it says.

Hm, would a directional address even have any meaning for a KRB_CRED?

>Then add functionality to krb5_genaddrs to set up an auth context to
>use directional addresses for the sending (local) but not receiving
>(remote) address.

So, something like:

krb5_auth_con_genaddrs(ctx, actx, KRB5_AUTH_CONTEXT_GENERATE_LOCAL_DIR_ADDR, ...)

?

>Finally, modify the sample application to optionally take adavantage
>of this functionality and add calls to the dejagnu tests to call the
>sample application in this manner.

That seems reasonable as well.  I think I can do all of that; I was thinking
that you wanted something a lot more involved.

--Ken