On Thu, May 8, 2025 at 3:55 PM Greg Hudson <[email protected]> wrote:
> 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) > Wow. Thanks for the detailed run-through. So the reductive understanding seems to be that the AP-REP subkey defaults to the Authenticator subkey and doing otherwise is controlled by various forces like adding RFC4537 AD-ETYPE-NEGOTIATION to the authorization_data so that the acceptor knows to / how to upgrade the key (which is the "difference" I was seeing from the MITK initiator). Fortunately I don't have to implement everything. For multiple reasons I code to the Windows SSPI which is MUCH easier than what you're doing. DCE_STYLE is next on my list after I polish up IAKERB so your pointers are super helpful. Mike -- Michael B Allen Java AD DS Integration https://www.ioplex.com/ <http://www.ioplex.com/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
