[krbdev.mit.edu #1415] subkeys fubar

[Tom Yu via RT]

>>>>> "Nico" == Public Submitter via RT <rt-comment at krbdev.mit.edu> writes:

Nico> [tlyu - Wed Apr 16 19:40:57 2003]:

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

Nico> Er, well, I suspect not, but if the default mkr_req/mk_rep
Nico> behaviour changes apps would break, no?  What about older kcmd?

Changing the default subkey negotiation doesn't break the
AP-REQ/AP-REP exchange, since those messages only contain ciphertext
encrypted using the ticket session key.  They may break the state of
what applications are expecting in terms of local and remote subkeys,
though.

kcmd applications use the local subkey on the client side and the
remote subkey on the server side.  This is just one key for
bidirectional use.

It seems that telnet does something similar to kcmd, but I haven't
traced the code thoroughly.

The GSS library also uses only one key -- the local subkey in the
initiator and the remote subkey in the acceptor.

To achieve "server subkey wins", we sould have to stomp on
local_subkey in the client and on remote_subkey in the server.  This
might cause pointer aliasing nastiness, but is very probably
manageable, given that the structure involved is supposed to be
opaque.

Nico> Is there a reflection attack there if unidirectional keys are
Nico> not used?

There is a reflection attack if you use a bidirectional subkey _if_
you don't utilize some other mechanism for identifying reflections,
e.g. directional "addresses".

---Tom