Projects/RFC 4537 - Revision history

TomYu at 04:22, 16 February 2010

TomYu — Tue, 16 Feb 2010 04:22:59 GMT

Lukeh at 18:37, 14 September 2009

Lukeh — Mon, 14 Sep 2009 18:37:47 GMT

TomYu: move to approved

TomYu — Tue, 13 Jan 2009 03:05:11 GMT

move to approved

Lukeh: /* New krb5_mk_req option */

Lukeh — Thu, 08 Jan 2009 03:33:19 GMT

‎New krb5_mk_req option

Lukeh: note krb5_rd_req differences

Lukeh — Thu, 08 Jan 2009 03:32:57 GMT

note krb5_rd_req differences

Ghudson at 20:03, 7 January 2009

Ghudson — Wed, 07 Jan 2009 20:03:28 GMT

SamHartman: Project for enctype negotiation

SamHartman — Tue, 06 Jan 2009 17:24:02 GMT

Project for enctype negotiation

New page

{{project-review|January 10, 2009}}

RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.

==New krb5_mk_req option==

The '''AP_OPTS_ETYPE_NEGOTIATION''' option is introduced. If this option is passed into '''krb5_mk_req''', then the RFC 4537 authorization data is included in the AP-REQ. If this data is included and mutual authentication is used, then the server will see if any of the enctypes included in this option are preferred to the ticket session key enctype. If so, one of these enctypes is used to propose a subkey in the ap-rep.

==GSS-API Integration==

The GSS-API mechanism uses the AP_OPTS_ETYPE_NEGOTIATION option in gss_init_sec_context. If the acceptor returns a subkey of a different encryption type, it is used.

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

	RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.		RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.

← Older revision		Revision as of 18:37, 14 September 2009
Line 1:		Line 1:
−	{{project-~~approved~~}}	+	{{project-completed}}

	RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.		RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.

← Older revision		Revision as of 03:05, 13 January 2009
Line 1:		Line 1:
−	{{project-~~review\|January 10, 2009~~}}	+	{{project-approved}}

	RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.		RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.

@@ Line 7: / Line 7: @@
 The '''AP_OPTS_ETYPE_NEGOTIATION''' option is introduced.  If this option is passed into '''krb5_mk_req''', then  the RFC 4537  authorization data is included in the AP-REQ.  If this data is included  and mutual authentication is used, then the server will see if any of the enctypes included in this option are preferred to the ticket session key enctype.  If so, one of these enctypes is used to propose a subkey in the ap-rep.
-'''krb5_rd_req''' will return '''AP_OPTS_ETYPE_NEGOTIATION''' if the RFC 4537 EtypeList was present; and in addition, '''AP_OPTS_USE_SUBKEY''' if a key was an enctype different to the ticket session key enctype was negotiated.
+'''krb5_rd_req''' will return '''AP_OPTS_ETYPE_NEGOTIATION''' if the RFC 4537 EtypeList was present; and in addition, '''AP_OPTS_USE_SUBKEY''' if a subkey with an enctype different to the ticket session key enctype was negotiated.
 ==GSS-API Integration==

← Older revision		Revision as of 03:32, 8 January 2009
Line 6:		Line 6:

	The '''AP_OPTS_ETYPE_NEGOTIATION''' option is introduced. If this option is passed into '''krb5_mk_req''', then the RFC 4537 authorization data is included in the AP-REQ. If this data is included and mutual authentication is used, then the server will see if any of the enctypes included in this option are preferred to the ticket session key enctype. If so, one of these enctypes is used to propose a subkey in the ap-rep.		The '''AP_OPTS_ETYPE_NEGOTIATION''' option is introduced. If this option is passed into '''krb5_mk_req''', then the RFC 4537 authorization data is included in the AP-REQ. If this data is included and mutual authentication is used, then the server will see if any of the enctypes included in this option are preferred to the ticket session key enctype. If so, one of these enctypes is used to propose a subkey in the ap-rep.
		+
		+	'''krb5_rd_req''' will return '''AP_OPTS_ETYPE_NEGOTIATION''' if the RFC 4537 EtypeList was present; and in addition, '''AP_OPTS_USE_SUBKEY''' if a key was an enctype different to the ticket session key enctype was negotiated.

	==GSS-API Integration==		==GSS-API Integration==

← Older revision		Revision as of 20:03, 7 January 2009
Line 10:		Line 10:

	The GSS-API mechanism uses the AP_OPTS_ETYPE_NEGOTIATION option in gss_init_sec_context. If the acceptor returns a subkey of a different encryption type, it is used.		The GSS-API mechanism uses the AP_OPTS_ETYPE_NEGOTIATION option in gss_init_sec_context. If the acceptor returns a subkey of a different encryption type, it is used.
		+
		+	==Aprovals==
		+
		+	Greg Hudson, 7 January 2009