Content-Transfer-Encoding: binary
To: rt@krbdev.mit.edu
Subject: SPNEGO init/accept output parameter bugs
X-RT-Interface: Web
Date: Tue, 05 Nov 2019 13:47:37 -0500
Message-ID: <rt-4.4.4-110505-1572979657-1171.0-0-0@mit.edu>
Content-Disposition: inline
X-Mailer: MIME-tools 5.507 (Entity 5.507)
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
From: ghudson@mit.edu
X-RT-Original-Encoding: utf-8
Content-Length: 2935

gss_init_sec_context() and gss_accept_sec_context() both output a token and either create or modify a security context.&nbsp; There are some additional outputs: actual_mech_type, ret_flags, and time_rec for gss_init_sec_context(), and src_name, mech_type, ret_flags, time_rec, and delegated_cred_handle for gss_accept_sec_context().&nbsp; RFC 2744 sections 5.1 and 5.19 define some rules for how these parameters should be set when GSS_S_CONTINUE_NEEDED is returned.<br />
<br />
Although the mechglue initializes most output parameters, it does not do so for ret_flags and time_rec.&nbsp; This is a separate bug, which impacts the following SPNEGO misbehaviors; if SPNEGO does not set these output parameters, the caller&#39;s value will remain unchanged.<br />
<br />
The current SPNEGO implementation has the following bugs related to the additional output parameters:<br />
<br />
* gss_init_sec_context() only sets ret_flags if the underlying mech is called and returns GSS_S_COMPLETE, or if SPNEGO itself will return GSS_S_COMPLETE.&nbsp; gss_accept_sec_context() initializes ret_flags to 0, and only sets ret_flags to another value if the underlying mech is called and returns GSS_S_COMPLETE; ret_flags could remain as 0 on SPNEGO&#39;s final return from gss_accept_sec_context(), if the MIC exchange forces an extra round trip.<br />
<br />
* gss_init_sec_context() and gss_accept_sec_context() do not filter out PROT_READY from ret_flags as required by RFC 4178.<br />
<br />
* gss_init_sec_context() and gss_accept_sec_context() pass time_rec directly to the underlying mech.&nbsp; gss_accept_sec_context() initializes time_rec to 0 but gss_init_sec_context() does not.&nbsp; Neither function will set time_rec to a meaningful value if the underlying mech is not called on the final SPNEGO call due to the MIC exchange.&nbsp; Note that time_rec is relative to the current time; if SPNEGO records time_rec from the underlying mech at one step and reports it to the caller at a later step, the time differential between steps could render that value inaccurate.&nbsp; SPNEGO could either adjust the value by the differential, or call gss_context_time() on the underlying context.<br />
<br />
* gss_accept_sec_context() initializes mech_type to GSS_C_NO_OID and passes it directly to the underlying mech.&nbsp; If the underlying mech is not called on the final step, mech_type will remain as GSS_C_NO_OID.<br />
<br />
* gss_accept_sec_context() initializes delegated_cred_handle to GSS_C_NO_CREDENTIAL and passes it directly to the underlying mech.&nbsp; SPNEGO could report a delegated cred to the caller too early (before the MIC exchange) and not on the final call.<br />
<br />
* gss_accept_sec_context() could leak a value of src_name (recorded as sc-&gt;internal_name) if the underlying mech reports it twice.&nbsp; RFC 2744 doesn&#39;t explicitly prohibit this, although it seems like it should be unusual.<br />
&nbsp;