logo_kerberos.gif

Difference between revisions of "Projects/RFC 4537"

From K5Wiki
Jump to: navigation, search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{project-review|January 10, 2009}}
+
{{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.
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 subkey with an enctype different to the ticket session key enctype was negotiated.
   
 
==GSS-API Integration==
 
==GSS-API Integration==

Latest revision as of 00:22, 16 February 2010

This project was completed in release 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.

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.

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

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