[4101] in Kerberos-V5-bugs
[krbdev.mit.edu #1415] subkey fubar description
daemon@ATHENA.MIT.EDU (Tom Yu via RT)
Wed Apr 16 19:41:11 2003
Date: Wed, 16 Apr 2003 19:40:59 -0400 (EDT)
Message-Id: <rt-1415-5755.7.40914179458699@krbdev.mit.edu>
In-Reply-To: <rt-1415@krbdev.mit.edu>
From: "Tom Yu via RT" <rt-comment@krbdev.mit.edu>
To: krb5-prs@mit.edu
Reply-To: rt-comment@krbdev.mit.edu
Errors-To: krb5-bugs-bounces@mit.edu
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?
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/krb5-bugs
