password change protocol implementation
kenh at cmf.nrl.navy.mil
Tue Feb 17 12:38:10 EST 2004
>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
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.
More information about the krbdev