| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Greg Hudson <ghudson@mit.edu>
To: Chris Hecker <checker@d6.com>
In-Reply-To: <4E3D0BAC.20502@d6.com>
Date: Mon, 08 Aug 2011 01:46:01 -0400
Message-ID: <1312782361.2242.20.camel@ray>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Sat, 2011-08-06 at 05:38 -0400, Chris Hecker wrote:
> Everywhere a subkey is generated or read in
> these functions (that I could find), they stomp both send_subkey and
> recv_subkey with the same key.
Right. RFC 4120 gives application protocols a fair amount of latitude
on what key to use for KRB-SAFE and KRB-PRIV messages (see section
3.2.6) but generally speaking, the most recent subkey to be asserted is
used in both directions.
> 2. Why have send_subkey and recv_subkey if they're always equal?
I'm not certain; this code is quite old. It would be possible for a
sophisticated application to use the krb5_auth_con_set{send,recv}subkey
functions to set different subkeys for each direction, although I'm not
aware of any application doing so.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |