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 SAA28560; Fri, 25 Apr 2003 18:38:02 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.9.3) id SAA06897; Fri, 25 Apr 2003 18:38:02 -0400 (EDT) To: rt-comment@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #1415] subkey fubar description References: From: Tom Yu Date: Fri, 25 Apr 2003 18:38:02 -0400 In-Reply-To: ("Tom Yu via RT"'s message of "Wed, 16 Apr 2003 19:40:59 -0400 (EDT)") Message-Id: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1257 First, clarification on my message of 20030416 -- (1) and (2) are swapped in 1.0.x only for rd_safe/rd_priv, not mk_safe/mk_priv. Conclusions from discussion yesterday with Sam and Ken: There will be three subkeys stored in the auth_context: "subkey", "send_subkey", and "recv_subkey" (or similarly named things). "send_subkey" will be what "local_subkey" is now, and "recv_subkey" will be what "remote_subkey" is now, except that they won't be set anymore. New APIs may be written to allow the application to set "send_subkey" and "recv_subkey". On the client side, mk_req and rd_rep will set "subkey" only. mk_safe/mk_priv will prefer "send_subkey", followed by "subkey". rd_safe/rd_priv will prefer "recv_subkey", followed by "subkey". In the future, new APIs will allow a client application to extract the different subkeys by querying the subkey either after mk_req or after rd_rep. mk_req will set "subkey" if requested, and send it in the AP-REQ message. rd_rep will read the subkey from the AP-REP message, and store it in "subkey", possibly overwriting one stored there by mk_req. On the server side, rd_req will set "subkey", and mk_rep may eventually allow an application to set a new "subkey", which will also be transmitted by mk_rep.