password change protocol implementation

[Sam Hartman]

>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

    Ken> I just can't really get the energy to develop a new API that
    Ken> will, in my mind, _only_ be used by the change password
    Ken> server.


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.

If you can't get the energy to separate out the patches, then I get we
get nothing;)

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.

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.


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.


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.

I think that's the simplest proposal I can make that balances my need
to avoid introducing new hacks into the API against the need of
implementation simplicity.  If that's still too much time for you,
then I'm sorry we won't be able to support the feature at this time.

--Sam