Projects/Acceptor Names - Revision history

Ghudson at 18:19, 12 October 2011

2011-10-12T18:19:11Z

Ghudson at 19:02, 8 February 2011

2011-02-08T19:02:45Z

Ghudson at 19:02, 8 February 2011

2011-02-08T19:02:02Z

Ghudson at 18:59, 8 February 2011

2011-02-08T18:59:48Z

Ghudson: /* Implementation Design */

2011-02-07T18:32:46Z

‎Implementation Design

Ghudson: /* Implementation Design */

2011-02-05T22:08:17Z

‎Implementation Design

Ghudson at 05:05, 2 February 2011

2011-02-02T05:05:51Z

Ghudson at 04:59, 2 February 2011

2011-02-02T04:59:13Z

Ghudson: /* Implementation Design */

2011-02-01T19:12:26Z

‎Implementation Design

Ghudson: /* Implementation Design */

2011-02-01T19:08:15Z

‎Implementation Design

← Older revision		Revision as of 18:19, 12 October 2011
Line 60:		Line 60:

	Python tests and a simple GSS initiator/acceptor C harness will be created to test each aspect of the new behavior.		Python tests and a simple GSS initiator/acceptor C harness will be created to test each aspect of the new behavior.
		+
		+	==Release Notes==
		+
		+	Developer experience:
		+
		+	* Add the ability for GSSAPI servers to use any keytab key for a specified service, if the server specifies a host-based name with no hostname component.
		+
		+	Administrator experience:
		+
		+	* Add the profile variable ignore_acceptor_hostname in libdefaults. If set, GSSAPI will ignore the hostname component of acceptor names supplied by the server, allowing any keytab key matching the service to be used.

← Older revision		Revision as of 19:02, 8 February 2011
Line 1:		Line 1:
−	{{project-completed}}
	{{project-rel\|1.10}}		{{project-rel\|1.10}}

← Older revision		Revision as of 19:02, 8 February 2011
Line 1:		Line 1:
		+	{{project-completed}}
	{{project-rel\|1.10}}		{{project-rel\|1.10}}

← Older revision		Revision as of 18:59, 8 February 2011
Line 1:		Line 1:
−	{{project-~~review~~\|~~February 8, 2011~~}}	+	{{project-rel\|1.10}}
−	{{project-target\|1.10}}

	==Overview==		==Overview==

@@ Line 37: / Line 37: @@
 When we create a krb5 mechanism name from a host-based GSS name, we should record the service name and hostname (if given).
-If the name is used on the initiator path (as an initiator name or target name) or is exported, we should convert from the recorded form to the principal we would construct with today's code, using krb5_sname_to_principal.
+If the name is used on the initiator path (as an initiator name or target name) or is exported, we should convert from the recorded form to the principal we would construct with today's code, using krb5_sname_to_principal.  (UPDATE: it proved to be too difficult to calculate the krb5_sname_to_principal result only when it is needed.  Instead, we record the passed-on service and hostname, but also call krb5_sname_to_principal at mechanism name import time, even though in some cases the result won't be used.)
 If the name is used in an acceptor cred, we should construct a matching principal service/hostname@ (empty realm) or service/@ (empty hostname and realm) depending on whether a name was recorded.  We should scan the keytab to make sure the matching principal is matched by a keytab entry.  If the keytab has no iteration support, we should just skip this check.

← Older revision		Revision as of 22:08, 5 February 2011
Line 45:		Line 45:
	We will need a new krb5 library interface for matching a principal against a matching principal, following the same rules as krb5_rd_req will apply. The proposed API for this function is:		We will need a new krb5 library interface for matching a principal against a matching principal, following the same rules as krb5_rd_req will apply. The proposed API for this function is:

−	krb5_error_code
		+	krb5_boolean
	krb5_sname_match(krb5_context context, krb5_const_principal matching, krb5_const_principal princ);		krb5_sname_match(krb5_context context, krb5_const_principal matching, krb5_const_principal princ);

← Older revision		Revision as of 05:05, 2 February 2011
Line 57:		Line 57:

	The changes proposed in this project should further that goal. By recording the original hostname when a host-based name is imported into the mechanism, we make it possible for the GSSAPI initiator code to use that information if the ccache indicates that it should.		The changes proposed in this project should further that goal. By recording the original hostname when a host-based name is imported into the mechanism, we make it possible for the GSSAPI initiator code to use that information if the ccache indicates that it should.
		+
		+	==Test Plan==
		+
		+	Python tests and a simple GSS initiator/acceptor C harness will be created to test each aspect of the new behavior.

← Older revision		Revision as of 04:59, 2 February 2011
Line 1:		Line 1:
−	{{project-~~early~~}}	+	{{project-review\|February 8, 2011}}
	{{project-target\|1.10}}		{{project-target\|1.10}}

@@ Line 41: / Line 41: @@
 If the name is used in an acceptor cred, we should construct a matching principal service/hostname@ (empty realm) or service/@ (empty hostname and realm) depending on whether a name was recorded.  We should scan the keytab to make sure the matching principal is matched by a keytab entry.  If the keytab has no iteration support, we should just skip this check.
-When an acceptor cred with an imported host-based name is used to accept a security context, we should try krb5_rd_req with the matching principal.  krb5_rd_req should treat matching principals as restrictions on the keytab scan it already performs when no principal is passed in.  krb5_rd_req should ignore the hostname component of a matching principal if the ignore_acceptor_hostname profile variable is set.  If the keytab has no iterator function, then krb5_rd_req should check that the principal asserted by the client matches the partial host-based principal, and look up that principal in the keytab.
+When an acceptor cred with an imported host-based name is used to accept a security context, we should try krb5_rd_req with the matching principal.  krb5_rd_req should treat matching principals as restrictions on the keytab scan it already performs when no principal is passed in.  krb5_rd_req should ignore the hostname component of a matching principal if the ignore_acceptor_hostname profile variable is set.  If the keytab has no iterator function, then krb5_rd_req should check that the principal asserted by the client matches the matching principal, and look up that principal in the keytab.
-We will need a new krb5 library interface for matching a principal against a partial principal, following the same rules as krb5_rd_req will apply.  The proposed API for this function is:
+We will need a new krb5 library interface for matching a principal against a matching principal, following the same rules as krb5_rd_req will apply.  The proposed API for this function is:
   krb5_error_code