Show quoted text
>>>>> "Nico" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:
Show quoted text
Nico> Er, why can't server subkey wins (or any other variation) be a
Nico> per-auth-context option that can be set by the application, with
Nico> the current ignore-the-server's- offered-subkey behaviour as the
Nico> default?
The current behavior isn't "ignore-the-server's-offered-subkey". The
current behavior is to accept the server's subkey and use it to
decrypt/verify the KRB-PRIV/KRB-SAFE messages from the server. If
clients running current code attempt to talk to a server where the
server actually generates a new subkey, the client won't use the
server-generated subkey to transmit messages to the server.
If we change client code to additionally smash the local subkey if it
receives a subkey from the server, then the semantic of "server subkey
wins" will be accomplished. This change to the client code won't
break against servers with the old behavior of merely sending back in
the AP-REP the client subkey as received in the AP-REQ.
The question does arise as to what the default behavior should be.
Changing the default client behavior to "server subkey wins" doesn't
change the behavior of any application code code currently in our
source tree, provided that the server implementation continues to send
the client subkey as its subkey. Clearly, changing the default
behavior of the server library will require changes in applications
that assume that the local and remote subkeys are identical. I think
that changing the server to actually generate a new subkey would
constitute a change in the application protocol.
I propose that we maintain the current default behavior in the server
library, but consider the possibility of altering the client library
code to default to "server subkey wins". Either behavior should
probably be modifiable by a flag in the auth_context.
---Tom
