1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.KERBEROS

  • Re: GSS unwrap fails using RC4 session key instead of subkey

    From Greg Hudson@21:1/5 to Michael B Allen on Wed May 7 17:59:21 2025
    To: kerberos@mit.edu (kerberos)

    On 5/7/25 13:36, Michael B Allen wrote:
    Where does the MITK initiator select the session key vs the subkey?
    RC4 is a "not newer" enctype, so krb5_gss_wrap() calls
    make_seal_token_v1() with enc=ctx->enc.

    ctx->enc is set up by kg_setup_keys() called at init_sec_context time.
    It is called first unconditionally in kg_new_connection(), with the
    initiator's subkey as set by krb5_mk_req_extended(). It may be called
    again by mutual_auth() with the acceptor's subkey, but only if:

    * Mutual authentication is performed
    * The AP-REP EncAPRepPart included an acceptor subkey
    * The RFC 4121 message format is used (not for RC4), OR
    DCE-style authencation is in use, OR
    the acceptor subkey has a different enctype from the initiator subkey

    Bonus question: Is there a trick to getting gdb to work with gss-client -pass?

    I haven't needed any trick. Using the test suite, I can run (from the
    top level of a build tree):

    cd appl/gss-sample
    PYTHONPATH=../../../src/util python3 ../../../src/appl/gss-sample/t_gss_sample.py
    # Open testlog in a text editor and search for "arcfour"
    # from there, search for "-pass" and note the command number
    # for me right now that is 156, but there have been some recent
    # changes to the test script
    PYTHONPATH=../../../src/util python3 ../../../src/appl/gss-sample/t_gss_sample.py -v --debug=156
    (gdb) break krb5_gss_wrap
    (gdb) run

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Michael B Allen on Thu May 8 15:55:44 2025
    To: kerberos@mit.edu (kerberos)

    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()).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)