Projects/Services4User - Revision history

Ghudson at 17:40, 16 February 2010

2010-02-16T17:40:17Z

TomYu at 04:31, 16 February 2010

2010-02-16T04:31:20Z

Lukeh: /* Background */

2009-11-15T10:20:36Z

‎Background

Ghudson at 02:53, 13 September 2009

2009-09-13T02:53:47Z

Ghudson: /* Approvals */

2009-09-10T17:17:54Z

‎Approvals

Ghudson: /* S4U2Proxy */

2009-09-10T17:17:31Z

‎S4U2Proxy

Lukeh: /* Status */

2009-09-08T10:55:18Z

‎Status

Lukeh: /* Status */

2009-08-30T08:27:17Z

‎Status

Lukeh: /* Status */

2009-08-30T08:27:05Z

‎Status

Lukeh: /* Background */

2009-08-27T15:04:41Z

‎Background

← Older revision		Revision as of 17:40, 16 February 2010
Line 1:		Line 1:
−	{{project-rel\|1.7}}	+	{{project-rel\|1.8}}

	Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.		Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.

← Older revision		Revision as of 04:31, 16 February 2010
Line 1:		Line 1:
−	{{project-~~completed~~}}	+	{{project-rel\|1.7}}

	Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.		Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.

@@ Line 14: / Line 14: @@
 The KDC will typically make some authorization checks before permitting the above: for S4U2Self, a flag on the service indicating that it is "trusted to authenticate for delegation" and, for S4U2Proxy, a set of server principals to which the service is permitted to delegate to. (Note: the trusted to authentictae for delegation flag controls whether a service can use S4U2Self to get forwardable tickets, not whether it can use S4U2Self.)
-There was already some KDC-side support for these protocols in MIT Kerberos 1.7 (although supporting S4U2Proxy requires explicit backend support that is not included with the standard distribution, and S4U2Self does not support some protocol extensions Microsoft made in Windows 2008).
+There was already some KDC-side support for these protocols in MIT Kerberos 1.7 (although supporting S4U2Proxy requires explicit backend support that is not included with the standard distribution, and S4U2Self does not support some protocol extensions Microsoft made in Windows 2008). (Note: this is old information. See [http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation ConstrainedDelegation].)
 This proposal is principally concerned with the client-side (or, more correctly, service-side) implementation of S4U, although we have also updated the KDC and kadmin to more completely support S4U2Self.

← Older revision		Revision as of 02:53, 13 September 2009
Line 1:		Line 1:
−	{{project-~~approved~~}}	+	{{project-completed}}

	Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.		Working code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/s4u users/lhoward/s4u] branch.

@@ Line 237: / Line 237: @@
 ===Approvals===
 sbuckley 2009-08-24
 ===Discussion===

← Older revision		Revision as of 17:17, 10 September 2009
Line 117:		Line 117:

	krb5_gss_accept_sec_context() has been changed such that, if the delegated credential handle parameter is non-NULL, and the verifier credential's usage is GSS_C_BOTH, a delegated credential handle will always be returned, and GSS_C_DELEG_FLAG will be set. This "proxy" credential can be passed directly to gss_init_sec_context() (for constrained delegation).		krb5_gss_accept_sec_context() has been changed such that, if the delegated credential handle parameter is non-NULL, and the verifier credential's usage is GSS_C_BOTH, a delegated credential handle will always be returned, and GSS_C_DELEG_FLAG will be set. This "proxy" credential can be passed directly to gss_init_sec_context() (for constrained delegation).
−
−	====gss_acquire_cred_impersonate_cred====
−
−	<pre>
−	OM_uint32 KRB5_CALLCONV
−	gss_acquire_cred_impersonate_cred(
−	OM_uint32 , / minor_status */
−	const gss_cred_id_t, /* impersonator_cred_handle */
−	const gss_cred_id_t, /* subject_cred_handle */
−	OM_uint32, /* time_req */
−	const gss_OID_set, /* desired_mechs */
−	gss_cred_usage_t, /* cred_usage */
−	gss_cred_id_t , / output_cred_handle */
−	gss_OID_set , / actual_mechs */
−	OM_uint32 ); / time_rec */
−	</pre>
−
−	This function uses <i>impersonator_cred_handle</i> to acquire a credential for <i>subject_cred_handle</i>. Only the initiator credential usage is supported by Kerberos. The returned credential can be passed into gss_init_sec_context(). (For the Kerberos mechanism, the S4U2Proxy request is deferred until gss_init_sec_context(), because only at that point is the target name known.)
−
−	For Kerberos, <i>subject_cred_handle</i> will be used to acquire a service ticket to the impersonation principal. This is of somewhat dubious utility, as if you possess the subject's TGT, you can acquire credentials in the normal way. But this interface may be useful to other GSS mechanisms, and is implemented for completeness.
−
−	Note that typically applications will not need to call this function. Constrained delegated credential handles returned by gss_accept_sec_context(), as well as credential handles returned by gss_acquire_cred_impersonate_name(), can be passed directly into gss_init_sec_contxet().
−
−	====gss_add_cred_impersonate_cred====
−
−	<pre>
−	OM_uint32 KRB5_CALLCONV
−	gss_add_cred_impersonate_cred(
−	OM_uint32 , / minor_status */
−	gss_cred_id_t, /* input_cred_handle */
−	const gss_cred_id_t, /* impersonator_cred_handle */
−	const gss_cred_id_t, /* subject_cred_handle */
−	const gss_OID, /* desired_mech */
−	gss_cred_usage_t, /* cred_usage */
−	OM_uint32, /* initiator_time_req */
−	OM_uint32, /* acceptor_time_req */
−	gss_cred_id_t , / output_cred_handle */
−	gss_OID_set , / actual_mechs */
−	OM_uint32 , / initiator_time_rec */
−	OM_uint32 ); / acceptor_time_rec */
−	</pre>

	==Implementation details==		==Implementation details==

@@ Line 261: / Line 261: @@
 ==Status==
-Implementation-wise, S4U2Self and S4U2Proxy are presently working against Windows 2008. A test program can be found in src/tests/gssapi/t_s4u.c. I have tested both a single- and two-realm (child domain) setup. Also, S4U2Self has been tested against a MIT 1.8 KDC.
+Implementation-wise, S4U2Self and S4U2Proxy are presently working against Windows 2008. A test program can be found in src/tests/gssapi/t_s4u.c. I have tested:
 ==Review==

@@ Line 263: / Line 263: @@
 Implementation-wise, S4U2Self and S4U2Proxy are presently working against Windows 2008. A test program can be found in src/tests/gssapi/t_s4u.c. I have tested both a single- and two-realm (child domain) setup. Also, S4U2Self has been tested against a MIT 1.8 KDC.
-[B]Testing S4U2Self across more than two domains is outstanding.[/B]
+<b>Testing S4U2Self across more than two domains is outstanding.</b>
 ==Review==

← Older revision		Revision as of 08:27, 30 August 2009
Line 262:		Line 262:

	Implementation-wise, S4U2Self and S4U2Proxy are presently working against Windows 2008. A test program can be found in src/tests/gssapi/t_s4u.c. I have tested both a single- and two-realm (child domain) setup. Also, S4U2Self has been tested against a MIT 1.8 KDC.		Implementation-wise, S4U2Self and S4U2Proxy are presently working against Windows 2008. A test program can be found in src/tests/gssapi/t_s4u.c. I have tested both a single- and two-realm (child domain) setup. Also, S4U2Self has been tested against a MIT 1.8 KDC.
		+
		+	[B]Testing S4U2Self across more than two domains is outstanding.[/B]

	==Review==		==Review==

@@ Line 12: / Line 12: @@
 Together, these extensions are referred to as Services4User, or S4U.
-The KDC will typically make some authorization checks before permitting the above: for S4U2Self, a flag on the service indicating that it is "trusted to authenticate for delegation" and, for S4U2Proxy, a set of server principals to which the service is permitted to delegate to. There is already some KDC-side support for these protocols in MIT Kerberos 1.7 (although supporting S4U2Proxy requires explicit backend support that is not included with the standard distribution, and S4U2Self does not support some protocol extensions Microsoft made in Windows 2008).
+The KDC will typically make some authorization checks before permitting the above: for S4U2Self, a flag on the service indicating that it is "trusted to authenticate for delegation" and, for S4U2Proxy, a set of server principals to which the service is permitted to delegate to. (Note: the trusted to authentictae for delegation flag controls whether a service can use S4U2Self to get forwardable tickets, not whether it can use S4U2Self.)
 This proposal is principally concerned with the client-side (or, more correctly, service-side) implementation of S4U, although we have also updated the KDC and kadmin to more completely support S4U2Self.