GSS unwrap fails using RC4 session key instead of subkey

[Greg Hudson]

On 5/8/25 14:17, Michael B Allen wrote:
> As you can see, the SSPI acceptor simply uses the same key for the
> Authenticator subkey and AP-REP subkey.
> Not sure how the SSPI knows to do this.

The MIT krb5 acceptor will do this as well, when the enctype is older 
and it can't negotiate a better enctype (e.g. if permitted_enctypes = 
rc4-hmac on the client or server).  See:

* accept_sec_context.c:1020-1024, where cfx_generate_subkey is only set 
when the enctype is newer, when we are using DCE-style, or when 
ap_req_options contains AP_OPTS_USE_SUBKEY (which means when we can 
negotiate a better enctype; see rd_req_dec.c:766-773)

* accept_sec_context.c:1030, where KRB5_AUTH_CONTEXT_USE_SUBKEY is only 
set when cfx_generate_subkey is set

* mk_rep.c:96-106, where repl.subkey is set to 
auth_context->authentp->subkey when KRB5_AUTH_CONTEXT_USE_SUBKEY isn't set

As best I can currently tell, there isn't a good reason for the 
conditional at init_sec_context.c:808-810 to be more complicated than 
ap_rep_data->subkey != NULL.  The other conditions seem to be there out 
of an abundance of caution, preserving the behavior of release 
1.6--which had no enctype negotiation or DCE-style support, and only 
ever used the acceptor subkey for newer enctypes.  But:

* When the MIT krb5 acceptor does generate a subkey, it expects the 
initiator to use it (accept_sec_context.c:1058).

* Heimdal appears to use the acceptor subkey for all enctypes (see 
wrap.c:_gsskrb5i_get_token_key() and it use in _gsskrb5_wrap()).