Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) by krbdev.mit.edu (8.9.3) with ESMTP id UAA06882; Fri, 18 Apr 2003 20:04:04 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.9.3) id UAA29741; Fri, 18 Apr 2003 20:04:04 -0400 (EDT) To: rt-comment@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #1415] subkeys fubar References: From: Tom Yu Date: Fri, 18 Apr 2003 20:04:03 -0400 In-Reply-To: ("Public Submitter via RT"'s message of "Fri, 18 Apr 2003 00:14:00 -0400 (EDT)") Message-Id: Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1888 >>>>> "Nico" == Public Submitter via RT writes: 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