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 TAA14099; Wed, 16 Apr 2003 19:40:54 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.9.3) id TAA13236; Wed, 16 Apr 2003 19:40:54 -0400 (EDT)
To: rt-comment@krbdev.mit.edu
Subject: [krbdev.mit.edu #1415] subkey fubar description
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 16 Apr 2003 19:40:54 -0400
Message-Id: <ldvy92aui2h.fsf@cathode-dark-space.mit.edu>
Lines: 42
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 1362

mk_safe, mk_priv key selection priority

1.  local_subkey
2.  remote_subkey
3.  session key from ticket

rd_safe, rd_priv key selection priority

1.  remote_subkey
2.  local_subkey
3.  session key from ticket

NOTE: (1) and (2) were reversed in krb5-1.0.x.

mk_req_ext -- generates local_subkey if requested, sends inside
AP-REQ msg.

rd_req_dec -- records subkey from authenticator as remote_subkey.
AP-REP is encrypted with the auth_context keyblock.

mk_rep -- subkey sent in AP-REP message is always the subkey from the
authenticator.

rd_rep -- subkey sent in AP-REP stored as remote_subkey.

krb-clarifications says that the AP-REP is always encrypted with the
ticket's session key.

The current state of affairs prevents server-side generation of subkey.

Even if server sends a subkey, the client won't encrypt using the
server subkey if there is a client-generated subkey.  This prevents
the use of server-side subkey for replay prevention.  Effectively,
this forces a choice of unidirectional subkeys if server-side subkey
generation is ever implemented.  The layout of the auth_context
structure implies that there was at least at some point an effort to
implememnt unidirectional subkeys.

Do we want an option to allow for "server subkey wins"?

Are there any applications currently depending on the functionality of
unidirectional subsession keys?