https://k5wiki.kerberos.org/w/api.php?action=feedcontributions&user=Lukeh&feedformat=atomK5Wiki - User contributions [en]2024-03-29T13:56:15ZUser contributionsMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3653Projects/GS22010-09-28T08:03:59Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Some additional features in the GSS mechanism glue are useful for implementors of SASL GS2.<br />
<br />
* RFC 5801: GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname<br />
* RFC 5587: gss_inquire_attrs_for_mech &c<br />
<br />
These allow a SASL library to dynamically bridge GSS mechanisms without mechanism-specific knowledge.<br />
<br />
==Architecture==<br />
<br />
The functionality of the aforementioned APIs is as follows:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names. (In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.)<br />
* a means to determine which features, denoted by OIDs, are supported by mechanisms<br />
<br />
For example, a GS2 implementation that wished to ignore negotiate mechanisms whilst selecting mechanisms that supported mutual authentication, might do:<br />
<br />
<pre><br />
static int gs2_indicate_mechs(void)<br />
{<br />
OM_uint32 major, minor;<br />
gss_OID_desc desired_oids[2];<br />
gss_OID_set_desc desired_attrs;<br />
gss_OID_desc except_oids[3];<br />
gss_OID_set_desc except_attrs;<br />
<br />
desired_oids[0] = *GSS_C_MA_AUTH_INIT;<br />
desired_oids[1] = *GSS_C_MA_AUTH_TARG;<br />
desired_attrs.count = sizeof(desired_oids)/sizeof(desired_oids[0]);<br />
desired_attrs.elements = desired_oids;<br />
<br />
except_oids[0] = *GSS_C_MA_MECH_NEGO;<br />
except_oids[1] = *GSS_C_MA_NOT_MECH;<br />
except_oids[2] = *GSS_C_MA_DEPRECATED;<br />
<br />
except_attrs.count = sizeof(except_oids)/sizeof(except_oids[0]);<br />
except_attrs.elements = except_oids;<br />
<br />
major = gss_indicate_mechs_by_attrs(&minor,<br />
&desired_attrs,<br />
&except_attrs,<br />
GSS_C_NO_OID_SET,<br />
&gs2_mechs);<br />
if (GSS_ERROR(major)) {<br />
return SASL_FAIL;<br />
}<br />
<br />
return SASL_OK;<br />
</pre><br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c and src/lib/gssapi/mechglue/g_mechattr.c, respectively.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
GS2 implementation at http://www.project-moonshot.org/git/cyrus-sasl in plugins/gs2.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech : GS2-EAP-AES256<br />
Mech name : eap-aes256-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech : GS2-6PUERUGDUSC<br />
Mech name : eap-arcfour-hmac<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/Database_Access_Layer_cleanup&diff=3649Projects/Database Access Layer cleanup2010-09-26T10:46:33Z<p>Lukeh: /* Jump points (db_set_option and db_invoke) */</p>
<hr />
<div>{{project-target|1.9}}<br />
<br />
This project page describes ideas and a prioritized plan for cleaning up the KDB Database Access Layer (DAL).<br />
<br />
=Analysis of 1.8 DAL=<br />
<br />
==Master key encryption==<br />
<br />
DB2 and LDAP encrypt key entries in a master key, which is obtained either through password entry at KDC/kadmind startup time or from a stash file. Encryption and decryption of key data is currently performed explicitly in the KDC and libkadm5.<br />
<br />
It is possible to construct a database plugin which does not encrypt key data in a master key, but it is hackish: the plugin overrides the default fetch_master_key function to return a dummy key, and overrides the default dbekd_encrypt_key_data and dbekd_decrypt_key_data functions to perform no encryption or decryption.<br />
<br />
It would perhaps be cleaner if key encryption and decryption were performed underneath the DAL. Since the user interface features associated with master keys (kdb5_util functions and the command-line options to krb5kdc and kadmind for keyboard entry of the master password) necessarily exist above the DAL, we would still need entry points to implement those features. To avoid decrypting all key entries on every lookup, all accesses to key data would need to go through the DAL--in a sense, this is already the case because of the need to call dbekd_decrypt_key_data, but the accessor interface could be simplified by removing the need to pass in the correct master key.<br />
<br />
There are opportunities for functional improvements to master keys, which should be noted even if they are out of scope for a DAL cleanup effort. Master keys are a prime candidate for storage on external tokens; we should make it easier to generate them randomly; and in some environments it may make sense to generate the master key randomly and then encrypt it in a keyboard-entered password (combining "what you have" and "what you know" for access to the KDB key data).<br />
<br />
If a comprehensive redesign of master key encryption is not performed, there is plenty of opportunity for minor cleanups to the master key functions:<br />
<br />
* get_master_key is unused, and its default implementation is invalid. set_master_key is used in the KDC and kadmind, but not productively, and the two modules are inconsistent about whether they copy or alias the provided memory.<br />
<br />
* The KDC and kadmind retrieve the master key list from the database using fetch_master_key_list, and then feed that value back into the module with set_master_key_list, so that the module can feed it back out to the KDB keytab via get_master_key_list. This seems unnecessarily complicated; the get and set functions can probably be excised from the DAL. The default implementation of get_master_key_list is invalid.<br />
<br />
* store_master_key has a password argument which is not used in the default implementation; this is probably okay because a DB module might want access to it. store_master_key_list also has a password argument, which makes little sense as the key list did not necessarily all derive from the same password.<br />
<br />
* verify_master_key only verifies against the most current master key entry; its functionality is pretty much subsumed by fetch_master_key_list. Most of its call sites were ifdef'd out during the master key migration project, except for kdb5_util dump -mkey_convert, which should perhaps be updated.<br />
<br />
* fetch_master_key_list allocates memory inside the database module, which is then freed by the caller. This is inconsistent with the design of other DAL functions which take care to allocate and free memory on the same side of the DAL.<br />
<br />
==DB entry format==<br />
<br />
The current DB entry structure contains fields specific to the DB2 back end. The tl_data field in particular was introduced in order to make the DB2 back end extensible, and is not a very natural way to access the information outside of that back end. Moreover, some back ends may not contain information in a format which maps naturally to the DB entry fields; for instance, an AD-style back end could contain user passwords rather than enctype-specific key data.<br />
<br />
An ambitious goal here might be to make the DB entry completely opaque from the perspective of the libkdb5 consumer, and use accessor functions (provided by the DAL) to retrieve and modify all entries. The back end would allocate and define the layout of the entire structure. A compromise might expose some of the structure but leave the rest to the back end.<br />
<br />
A less ambitious, but still work-intensive goal might be to remove the tl_data field and instead add specific fields for the information contained therein, making the back end responsible for encoding and decoding that data as tl_data when storing and reading entries.<br />
<br />
==Jump points (db_set_option and db_invoke)==<br />
<br />
The functions db_set_option and db_invoke accept a method number and arguments (a void * for db_set_option, and a pair of krb5_data objects for db_invoke) whose interpretation depends on the method number. They each serve a variety of unrelated purposes. There is currently no good reason to combine multiple operations into a single vtable entry this way. (Originally this was done to minimise the cost of maintaining a fork.)<br />
<br />
db_set_option is unused and should be removed. db_invoke should be split out into separate, type-safe interfaces.<br />
<br />
==krb5_key_data==<br />
<br />
The krb5_key_data structure is very representation-oriented. It contains a "version" (separate from the kvno) which indicates whether or not there is an explicit salt associated with the key, and then the type/length/contents pointers are arrays of two elements, the second of which determines the explicit salt. This structure should be redefined in a more logical fashion, and the conversion to the format used by the DB2 back end should be performed underneath the DAL.<br />
<br />
==Alias-related flags==<br />
<br />
The flags field for db_get_principal does not explicitly indicate whether aliases are okay. (They should be allowed for TGS requests, and for AS requests if the client indicates a willingness to accept them.) Currently the LDAP back end uses a combination of CLIENT_REFERRALS_ONLY and CANONICALIZE to decide whether to return aliases. There should be an explicit flag.<br />
<br />
==Separation of KDC and admin DAL interfaces==<br />
<br />
Currently the KDC and libkadm5srv libraries use the same set of interfaces, each requiring overlapping subsets of the functions. It might be cleaner to have separate vtables for the KDC and for administrative access. This would make the required functionality clearer for modules which only wish to target the KDC, and would also clean up situations where functionality in the overlapping functions (like db_get_principal) varies subtly between KDC access and administrative access scenarios.<br />
<br />
==The memory allocation barrier==<br />
<br />
Particularly on Windows, it is possible for different build environments to use different malloc/free implementations. Because of this, there is some attention paid in Kerberos to making sure that memory is allocated and freed on the same side of any public interface, including plugin provider interfaces.<br />
<br />
The DAL pays attention to this requirement to some degree. Principally, the krb5_db_alloc() and krb5_db_free() functions can be used to allocate and free memory within the KDB module; this is mainly used by libkadm5srv when it wants to create or modify a krb5_db_entry which will later be freed by the KDB module's free_principal method. Using krb5_db_alloc can be cumbersome; for instance, there is a 50+ line function in libkadm5srv to copy a principal into storage allocated by the DB module.<br />
<br />
There are numerous violations of the memory allocation barrier, some inherent in the DAL interfaces and some due to implementation sloppiness. Because the DAL is not currently used under Windows, these violations are not discovered in testing and create minimal pain, but do render moot the efforts made by other pieces of code to obey the memory allocation barrier as it applies to the DAL.<br />
<br />
This problem can be addressed in either direction. The DAL can be declared not to be a memory allocation barrier, in which case krb5_db_alloc and krb5_db_free can go away (and some code can be simplified), or all of the violations of the barrier can be fixed.<br />
<br />
A partial list of violations follows:<br />
<br />
* fetch_master_key_list allocates memory inside the DB module, which is later freed by callers outside of the DB module.<br />
<br />
* The CHECK_POLICY_AS and CHECK_POLICY_TGS methods of db_invoke allocate memory for status inside the DB module; it is freed by the KDC.<br />
<br />
==Miscellaneous cleanup==<br />
<br />
The db_get_principal function takes "nentries" and "more" parameters which are never productively used. A principal name can only have one associated principal. The db_get_policy function has a similar argument "cnt" which makes equally little sense.<br />
<br />
The db_put_principal function takes a list of krb5_db_entry structures. We never use it to put more than one principal, and we have no expectation of needing transactional updates across principals. It should take only a single krb5_db_entry.<br />
<br />
Some krb5_db functions are never used, such as krb5_db_set_option. Since we have no compatibility promises for libkdb across releases, these should be inventoried and removed.<br />
<br />
There are two different "not supported" error codes used by krb5_db. The LDAP plugin mostly returns KRB5_PLUGIN_OP_NOTSUPP (except in db_invoke), while kdb5.h and hdb use KRB5_KDB_DBTYPE_NOSUP. kdb5_util dump expects to see KRB5_PLUGIN_OP_NOTSUPP from a database which does not support locks. These error codes should be collapsed into one.<br />
<br />
There appears to be no precise rule as to whether kdb5.c will check for the nullity of a function pointer, assert non-nullity, or simply use it without checking. At a minimum, kdb5.c should be consistent about whether to assert non-nullity before using a mandatory function, and certain obviously mandatory functions like db_get_principal should not be treated as optional.<br />
<br />
krb5_db_iterate returns success if the module does not support iteration. This is not a correct answer; it should return an error instead. (Existing modules all support iteration, so this would not be a functional change for current modules.)<br />
<br />
errcode_2_string is not productively used. In db2 it is not implemented; in LDAP it has the overall effect of calling krb5_get_error_message on the error code and then krb5_set_error_message on the result, which is a complicated no-op. This function and release_errcode_string should be removed.<br />
<br />
db_change_pwd should be named dbe_change_pwd for consistency with other functions operating on in-memory database entries as opposed to the database itself.<br />
<br />
kdb5_util specifies a db_args value of "temporary" to instruct the back end to open a side copy of the database, and then calls promote_db to make the database live when the load is complete. (On failure, the same "temporary" argument instructs destroy to remove the temporary copy of the DB.) Specifying a temporary DB should ideally be accomplished via a symbolic parameter, not via invasion of the db_args namespace. Furthermore, there should be a programmatic way to determine if the module does not support opening a temporary DB, so that kdb5_util can supply a good error message on its own. Currently the LDAP back end returns EINVAL and supplies an error message written with knowledge of the kdb5_util UI.<br />
<br />
=Prioritization=<br />
<br />
The following plan gives a prioritized list of cleanup proposals; the goal is to implement as many of them as possible for 1.9, realizing that the ones near the end of the list may be deferred. When changes are proposed to DAL interfaces, assume that the corresponding krb5_db interface will also be changed except when otherwise noted.<br />
<br />
==Safety Mechanisms==<br />
<br />
Define a constant in kdb.h which increments with incompatible modifications to the DAL vtable. Set this as the major version of the vtables for the in-tree KDB modules. In libkdb5, refuse to use a DB module whose major version does not match the current version.<br />
<br />
Define a KDB API version in kdb.h to allow external users of libkdb5 to conditionalize across incompatible changes to the API. This version is intended to be in sync with the library ABI version number, so will start at 5.<br />
<br />
==Simple Cleanups==<br />
<br />
* Remove the following interfaces, which are either unused or not productively used:<br />
** db_supported_realms<br />
** db_free_supported_realms<br />
** errcode_2_string<br />
** get_master_key<br />
** release_errcode_string<br />
** setup_master_key_name<br />
** set_master_key<br />
** set_option<br />
<br />
* Rename the following library APIs:<br />
** krb5_dbekd_decrypt_key_data -> krb5_dbe_decrypt_key_data<br />
** krb5_dbekd_encrypt_key_data -> krb5_dbe_encrypt_key_data<br />
<br />
* Make the following library APIs return void:<br />
** krb5_db_free_principal<br />
** krb5_db_free_mkey_list<br />
<br />
* Remove the db_ or similar prefix from all interfaces in the DAL (but leave it in the library APIs).<br />
<br />
* Remove verify_master_key, updating kdb5_util mkey_convert to use krb5_db_fetch_mkey_list instead.<br />
<br />
* Remove store_master_key, and implement krb5_db_store_master_key in terms of store_master_key_list.<br />
<br />
* Change all uses of KRB5_KDB_DBTYPE_NOSUP to KRB5_PLUGIN_OP_NOTSUPP.<br />
<br />
* Return KRB5_KDB_DBTYPE_NOSUP from krb5_db_iterate if the module does not implement db_iterate.<br />
<br />
* Remove the default implementations of get_master_key_list, set_master_key_list, and promote_db, and make the KDB APIs for those functions return KRB5_PLUGIN_OP_NOTSUPP if the module does not implement them.<br />
<br />
* Remove assertions in kdb5.c for init_module and fini_module being non-null.<br />
<br />
==Principal and Policy API Changes==<br />
<br />
* Remove the nentries and more parameters from get_principal, and make it return an error if the principal does not exist.<br />
<br />
* Remove the library API krb5_db_get_principal_ext, and add its flags argument to krb5_db_get_principal.<br />
<br />
* Remove the count parameter from free_principal.<br />
<br />
* Remove the nentries parameter from put_principal.<br />
<br />
* Make get_principal and free_principal responsible for allocating the krb5_db_entry container (so get_principal's output argument would gain an extra level of indirection). This allows for more robust cleanup and is consistent with get_policy.<br />
<br />
* Remove the nentries parameter from delete_principal, and make it return an error if the principal did not exist.<br />
<br />
* Remove checks for nullity of get_principal and free_principal, as they are mandatory for KDC operation.<br />
<br />
* Remove the cnt parameter from get_policy, and make it return an error if the policy did not exist.<br />
<br />
* Define a flag KRB5_KDB_ALIAS_OK for use with get_principal. Set it for TGS requests, for AS requests when the canonicalize flag was requested, and for requests via libkadm5.<br />
<br />
==Split db_invoke==<br />
<br />
Replace db_invoke and its associated structures with the following interfaces:<br />
* sign_auth_data<br />
* check_transited_realms<br />
* check_policy_as<br />
* audit_as<br />
* audit_tgs<br />
* refresh_policy<br />
* check_allowed_to_delegate<br />
<br />
==Master Key Redesign (separate project)==<br />
<br />
Redesign the master key interfaces. The precise design is deferred to a separate project writeup, with the following desirables:<br />
<br />
* Modules which don't use master key encryption can simply decline to implement the relevant interfaces, rather than having to fake them out.<br />
<br />
* Memory allocated by fetch_master_key_list (or equivalent) should be freed inside the module, not by the caller.<br />
<br />
* Eliminate set_master_key_list and get_master_key_list, making the caller responsible for caching those.<br />
<br />
==DB Entry Redesign (separate project)==<br />
<br />
Redesign the krb5_db_entry structure to be independent of its representation within the DB2 module. The precise design is deferred to a separate project writeup, with the following desirables:<br />
<br />
* Eliminate e_length, e_data, and tl_data, replacing them with the logical elements currently stored using tl_data.<br />
<br />
* Provide a well-defined place for module-specific entry data.<br />
<br />
* Abstract key data accesses through a functional interface, to better handle AD-style modules which store the password rather than a list of keys.<br />
<br />
==Separate KDC and Admin Interfaces (separate project)==<br />
<br />
Subject to further review, define separate plugin interfaces for the KDC and kadmin, allowing bridge-style modules to provide a more narrow set of interfaces. The precise design is deferred to a separate project.<br />
<br />
=Status=<br />
<br />
All cleanups have been implemented for the 1.9 release except those deferred to separate projects. Early project pages have been created for the separate projects.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3648Projects/GS22010-09-26T10:44:37Z<p>Lukeh: /* Architecture */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Some additional features in the GSS mechanism glue are useful for implementors of SASL GS2.<br />
<br />
* RFC 5801: GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname<br />
* RFC 5587: gss_inquire_attrs_for_mech &c<br />
<br />
These allow a SASL library to dynamically bridge GSS mechanisms without mechanism-specific knowledge.<br />
<br />
==Architecture==<br />
<br />
The functionality of the aforementioned APIs is as follows:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names. (In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.)<br />
* a means to determine which features, denoted by OIDs, are supported by mechanisms<br />
<br />
For example, a GS2 implementation that wished to ignore negotiate mechanisms whilst selecting mechanisms that supported mutual authentication, might do:<br />
<br />
<pre><br />
static int gs2_indicate_mechs(void)<br />
{<br />
OM_uint32 major, minor;<br />
gss_OID_desc desired_oids[2];<br />
gss_OID_set_desc desired_attrs;<br />
gss_OID_desc except_oids[3];<br />
gss_OID_set_desc except_attrs;<br />
<br />
desired_oids[0] = *GSS_C_MA_AUTH_INIT;<br />
desired_oids[1] = *GSS_C_MA_AUTH_TARG;<br />
desired_attrs.count = sizeof(desired_oids)/sizeof(desired_oids[0]);<br />
desired_attrs.elements = desired_oids;<br />
<br />
except_oids[0] = *GSS_C_MA_MECH_NEGO;<br />
except_oids[1] = *GSS_C_MA_NOT_MECH;<br />
except_oids[2] = *GSS_C_MA_DEPRECATED;<br />
<br />
except_attrs.count = sizeof(except_oids)/sizeof(except_oids[0]);<br />
except_attrs.elements = except_oids;<br />
<br />
major = gss_indicate_mechs_by_attrs(&minor,<br />
&desired_attrs,<br />
&except_attrs,<br />
GSS_C_NO_OID_SET,<br />
&gs2_mechs);<br />
if (GSS_ERROR(major)) {<br />
return SASL_FAIL;<br />
}<br />
<br />
return SASL_OK;<br />
</pre><br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c and src/lib/gssapi/mechglue/g_mechattr.c, respectively.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech : GS2-EAP-AES256<br />
Mech name : eap-aes256-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech : GS2-6PUERUGDUSC<br />
Mech name : eap-arcfour-hmac<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3647Projects/GS22010-09-26T10:44:13Z<p>Lukeh: /* Architecture */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Some additional features in the GSS mechanism glue are useful for implementors of SASL GS2.<br />
<br />
* RFC 5801: GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname<br />
* RFC 5587: gss_inquire_attrs_for_mech &c<br />
<br />
These allow a SASL library to dynamically bridge GSS mechanisms without mechanism-specific knowledge.<br />
<br />
==Architecture==<br />
<br />
The functionality of the aforementioned APIs is as follows:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names. (In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.)<br />
* a means to determine which features, denoted by OIDs, are supported by mechanisms<br />
<br />
For example, a GS2 implementation that wished to ignore negotiate mechanisms whilst selecting mechanisms that supported mutual authentication, might do:<br />
<br />
<pre><br />
static int gs2_indicate_mechs(void)<br />
{<br />
OM_uint32 major, minor;<br />
gss_OID_desc desired_oids[2];<br />
gss_OID_set_desc desired_attrs;<br />
gss_OID_desc except_oids[3];<br />
gss_OID_set_desc except_attrs;<br />
<br />
if (gs2_mechs != GSS_C_NO_OID_SET)<br />
return SASL_OK;<br />
<br />
desired_oids[0] = *GSS_C_MA_AUTH_INIT;<br />
desired_oids[1] = *GSS_C_MA_AUTH_TARG;<br />
desired_attrs.count = sizeof(desired_oids)/sizeof(desired_oids[0]);<br />
desired_attrs.elements = desired_oids;<br />
<br />
except_oids[0] = *GSS_C_MA_MECH_NEGO;<br />
except_oids[1] = *GSS_C_MA_NOT_MECH;<br />
except_oids[2] = *GSS_C_MA_DEPRECATED;<br />
<br />
except_attrs.count = sizeof(except_oids)/sizeof(except_oids[0]);<br />
except_attrs.elements = except_oids;<br />
<br />
major = gss_indicate_mechs_by_attrs(&minor,<br />
&desired_attrs,<br />
&except_attrs,<br />
GSS_C_NO_OID_SET,<br />
&gs2_mechs);<br />
if (GSS_ERROR(major)) {<br />
return SASL_FAIL;<br />
}<br />
<br />
return SASL_OK;<br />
</pre><br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c and src/lib/gssapi/mechglue/g_mechattr.c, respectively.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech : GS2-EAP-AES256<br />
Mech name : eap-aes256-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech : GS2-6PUERUGDUSC<br />
Mech name : eap-arcfour-hmac<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3646Projects/GS22010-09-26T10:44:02Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Some additional features in the GSS mechanism glue are useful for implementors of SASL GS2.<br />
<br />
* RFC 5801: GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname<br />
* RFC 5587: gss_inquire_attrs_for_mech &c<br />
<br />
These allow a SASL library to dynamically bridge GSS mechanisms without mechanism-specific knowledge.<br />
<br />
==Architecture==<br />
<br />
The functionality of the aforementioned APIs is as follows:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names. (In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.)<br />
* a means to determine which features, denoted by OIDs, are supported by mechanisms<br />
<br />
For example, a GS2 implementation that wished to ignore negotiate mechanisms whilst selecting mechanisms that supported mutual authentication, might do:<br />
<br />
<pre><br />
static int gs2_indicate_mechs(void<br />
{<br />
OM_uint32 major, minor;<br />
gss_OID_desc desired_oids[2];<br />
gss_OID_set_desc desired_attrs;<br />
gss_OID_desc except_oids[3];<br />
gss_OID_set_desc except_attrs;<br />
<br />
if (gs2_mechs != GSS_C_NO_OID_SET)<br />
return SASL_OK;<br />
<br />
desired_oids[0] = *GSS_C_MA_AUTH_INIT;<br />
desired_oids[1] = *GSS_C_MA_AUTH_TARG;<br />
desired_attrs.count = sizeof(desired_oids)/sizeof(desired_oids[0]);<br />
desired_attrs.elements = desired_oids;<br />
<br />
except_oids[0] = *GSS_C_MA_MECH_NEGO;<br />
except_oids[1] = *GSS_C_MA_NOT_MECH;<br />
except_oids[2] = *GSS_C_MA_DEPRECATED;<br />
<br />
except_attrs.count = sizeof(except_oids)/sizeof(except_oids[0]);<br />
except_attrs.elements = except_oids;<br />
<br />
major = gss_indicate_mechs_by_attrs(&minor,<br />
&desired_attrs,<br />
&except_attrs,<br />
GSS_C_NO_OID_SET,<br />
&gs2_mechs);<br />
if (GSS_ERROR(major)) {<br />
return SASL_FAIL;<br />
}<br />
<br />
return SASL_OK;<br />
</pre><br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c and src/lib/gssapi/mechglue/g_mechattr.c, respectively.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech : GS2-EAP-AES256<br />
Mech name : eap-aes256-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech : GS2-6PUERUGDUSC<br />
Mech name : eap-arcfour-hmac<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3645Projects/GS22010-09-25T21:16:24Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Some additional features in the GSS mechanism glue are useful for implementors of SASL GS2.<br />
<br />
* GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in RFC 5801<br />
* gss_inquire_attrs_for_mech and friends as described in RFC 5587<br />
<br />
These allow a SASL library to dynamically bridge GSS mechanisms without mechanism-specific knowledge.<br />
<br />
==Architecture==<br />
<br />
The functionality of the aforementioned APIs is as follows:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names. (In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.)<br />
* a means to determine which features, denoted by OIDs, are supported by mechanisms<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c and src/lib/gssapi/mechglue/g_mechattr.c, respectively.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech : GS2-EAP-AES256<br />
Mech name : eap-aes256-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech : GS2-6PUERUGDUSC<br />
Mech name : eap-arcfour-hmac<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3644Projects/GS22010-09-25T20:06:05Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Some additional features in the GSS mechanism glue are useful for implementors of SASL GS2.<br />
<br />
* GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20 draft-ietf-sasl-gs2-20[/url].<br />
* gss_inquire_attrs_for_mech and friends as described in RFC 5587<br />
<br />
These allow a SASL library to dynamically bridge GSS mechanisms without mechanism-specific knowledge.<br />
<br />
==Architecture==<br />
<br />
The functionality of the aforementioned APIs is as follows:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names. (In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.)<br />
* a means to determine which features, denoted by OIDs, are supported by mechanisms<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c and src/lib/gssapi/mechglue/g_mechattr.c, respectively.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech : GS2-EAP-AES256<br />
Mech name : eap-aes256-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech : GS2-6PUERUGDUSC<br />
Mech name : eap-arcfour-hmac<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3643Projects/GS22010-09-25T19:06:14Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
* Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20 draft-ietf-sasl-gs2-20[/url].<br />
* Implement gss_inquire_attrs_for_mech and friends as described in RFC 5587<br />
<br />
==Architecture==<br />
<br />
These APIs provide the following:<br />
<br />
* a bidirectional mapping between GSS OIDs and SASL mechanism names (in the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID)<br />
* a means to determine which features are supported by mechanisms<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_indicate_mechs_by_attrs(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID_set, /* desired_mech_attrs */<br />
gss_const_OID_set, /* except_mech_attrs */<br />
gss_const_OID_set, /* critical_mech_attrs */<br />
gss_OID_set *); /* mechs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_inquire_attrs_for_mech(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech */<br />
gss_OID_set *, /* mech_attrs */<br />
gss_OID_set *); /* known_mech_attrs */<br />
<br />
OM_uint32 KRB5_CALLCONV<br />
gss_display_mech_attr(<br />
OM_uint32 *, /* minor_status */<br />
gss_const_OID, /* mech_attr */<br />
gss_buffer_t, /* name */<br />
gss_buffer_t, /* short_desc */<br />
gss_buffer_t); /* long_desc */<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms and their attributes.<br />
<br />
<pre><br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech : GS2-KRB5<br />
Mech name : krb5<br />
Mech desc : Kerberos 5 GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_CTX_TRANS GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech : SPNEGO<br />
Mech name : spnego<br />
Mech desc : Simple and Protected GSS-API Negotiation Mechanism<br />
Mech attrs: GSS_C_MA_MECH_NEGO GSS_C_MA_ITOK_FRAMED GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech : GS2-ZGMBGB5SLBQ<br />
Mech name : eap-des3-cbc-sha1<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech : GS2-EAP-AES128<br />
Mech name : eap-aes128-cts-hmac-sha1-96<br />
Mech desc : Extensible Authentication Protocol GSS-API Mechanism<br />
Mech attrs: GSS_C_MA_NOT_DFLT_MECH <br />
Known attrs: GSS_C_MA_MECH_CONCRETE GSS_C_MA_MECH_PSEUDO GSS_C_MA_MECH_COMPOSITE GSS_C_MA_MECH_NEGO GSS_C_MA_MECH_GLUE GSS_C_MA_NOT_MECH GSS_C_MA_DEPRECATED GSS_C_MA_NOT_DFLT_MECH GSS_C_MA_ITOK_FRAMED GSS_C_MA_AUTH_INIT GSS_C_MA_AUTH_TARG GSS_C_MA_AUTH_INIT_INIT GSS_C_MA_AUTH_TARG_INIT GSS_C_MA_AUTH_INIT_ANON GSS_C_MA_AUTH_TARG_ANON GSS_C_MA_DELEG_CRED GSS_C_MA_INTEG_PROT GSS_C_MA_CONF_PROT GSS_C_MA_MIC GSS_C_MA_WRAP GSS_C_MA_PROT_READY GSS_C_MA_REPLAY_DET GSS_C_MA_OOS_DET GSS_C_MA_CBINDINGS GSS_C_MA_PFS GSS_C_MA_COMPRESS GSS_C_MA_CTX_TRANS <br />
------------------------------------------------------------------------------<br />
<br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3642Projects/GS22010-09-25T13:48:39Z<p>Lukeh: /* Status */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20]draft-ietf-sasl-gs2-20[/url].<br />
<br />
==Architecture==<br />
<br />
These APIs provide a bidirectional mapping between GSS OIDs and SASL mechanism names. In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin. Code is in the users/lhoward/sasl-gs2 branch (note that this is branched off import-cred; pick up only the changes you need).<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms.<br />
<br />
<pre><br />
<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech: SPNEGO<br />
Mech name: spnego<br />
Mech desc: Simple and Protected GSS-API Negotiation Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 }<br />
SASL mech: GS2-EAP<br />
Mech name: eap<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech: GS2-ZGMBGB5SLBQ<br />
Mech name: eap-des3-cbc-sha1<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech: GS2-EAP-AES128<br />
Mech name: eap-aes128-cts-hmac-sha1-96<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech: GS2-EAP-AES256<br />
Mech name: eap-aes256-cts-hmac-sha1-96<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech: GS2-6PUERUGDUSC<br />
Mech name: eap-arcfour-hmac<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3641Projects/GS22010-09-25T13:48:08Z<p>Lukeh: /* Examples */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20]draft-ietf-sasl-gs2-20[/url].<br />
<br />
==Architecture==<br />
<br />
These APIs provide a bidirectional mapping between GSS OIDs and SASL mechanism names. In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin.<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms.<br />
<br />
<pre><br />
<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
Got different OID { 1 2 840 113554 1 2 2 } for mechanism GS2-KRB5<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech: SPNEGO<br />
Mech name: spnego<br />
Mech desc: Simple and Protected GSS-API Negotiation Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 }<br />
SASL mech: GS2-EAP<br />
Mech name: eap<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech: GS2-ZGMBGB5SLBQ<br />
Mech name: eap-des3-cbc-sha1<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech: GS2-EAP-AES128<br />
Mech name: eap-aes128-cts-hmac-sha1-96<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech: GS2-EAP-AES256<br />
Mech name: eap-aes256-cts-hmac-sha1-96<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech: GS2-6PUERUGDUSC<br />
Mech name: eap-arcfour-hmac<br />
Mech desc: Extensible Authentication Protocol GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
</pre></div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3640Projects/GS22010-09-25T13:47:58Z<p>Lukeh: /* Status */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20]draft-ietf-sasl-gs2-20[/url].<br />
<br />
==Architecture==<br />
<br />
These APIs provide a bidirectional mapping between GSS OIDs and SASL mechanism names. In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin.<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3639Projects/GS22010-09-25T13:32:08Z<p>Lukeh: /* Status */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20]draft-ietf-sasl-gs2-20[/url].<br />
<br />
==Architecture==<br />
<br />
These APIs provide a bidirectional mapping between GSS OIDs and SASL mechanism names. In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin.<br />
<br />
A test program is in src/tests/gssapi/t_saslname.c.<br />
<br />
<pre><br />
<br />
[rand:src/tests/gssapi] lukeh% ./t_saslname<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 113554 1 2 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 5 1 5 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 2 840 48018 1 2 2 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 2 5 }<br />
SASL mech: GS2-KRB5<br />
Mech name: krb5<br />
Mech desc: Kerberos 5 GSS-API Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 5 5 2 }<br />
SASL mech: SPNEGO<br />
Mech name: spnego<br />
Mech desc: Simple and Protected GSS-API Negotiation Mechanism<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 }<br />
SASL mech: GS2-EAP<br />
Mech name: eap<br />
Mech desc: A GSS-API Mechanism for the Extensible Authentication Protocol<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 16 }<br />
SASL mech: GS2-ZGMBGB5SLBQ<br />
Mech name: eap-des3-cbc-sha1<br />
Mech desc: A GSS-API Mechanism for the Extensible Authentication Protocol<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 17 }<br />
SASL mech: GS2-EAP-AES128<br />
Mech name: eap-aes128-cts-hmac-sha1-96<br />
Mech desc: A GSS-API Mechanism for the Extensible Authentication Protocol<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 18 }<br />
SASL mech: GS2-EAP-AES256<br />
Mech name: eap-aes256-cts-hmac-sha1-96<br />
Mech desc: A GSS-API Mechanism for the Extensible Authentication Protocol<br />
------------------------------------------------------------------------------<br />
------------------------------------------------------------------------------<br />
OID : { 1 3 6 1 4 1 5322 21 1 23 }<br />
SASL mech: GS2-6PUERUGDUSC<br />
Mech name: eap-arcfour-hmac<br />
Mech desc: A GSS-API Mechanism for the Extensible Authentication Protocol<br />
------------------------------------------------------------------------------<br />
</pre><br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GS2&diff=3638Projects/GS22010-09-25T13:01:01Z<p>Lukeh: New page: {{project-early}} {{project-target|1.9}} ==Background== Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf...</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
==Background==<br />
<br />
Implement GSS_Inquire_SASLname_for_mech and GSS_Inquire_mech_for_SASLname as defined in [url http://tools.ietf.org/html/draft-ietf-sasl-gs2-20]draft-ietf-sasl-gs2-20[/url].<br />
<br />
==Architecture==<br />
<br />
These APIs provide a bidirectional mapping between GSS OIDs and SASL mechanism names. In the case of no mapping, the mechanism glue synthesises a SASL name using a base-32 encoded SHA-1 of the OID.<br />
<br />
==Implementation==<br />
<br />
The implementations live in src/lib/gssapi/mechglue/g_saslname.c.<br />
<br />
<pre><br />
OM_uint32 KRB5_CALLCONV gss_inquire_saslname_for_mech(<br />
OM_uint32 *minor_status,<br />
const gss_OID desired_mech,<br />
gss_buffer_t sasl_mech_name,<br />
gss_buffer_t mech_name,<br />
gss_buffer_t mech_description);<br />
<br />
OM_uint32 KRB5_CALLCONV gss_inquire_mech_for_saslname(<br />
OM_uint32 *minor_status,<br />
const gss_buffer_t sasl_mech_name,<br />
gss_OID *mech_type);<br />
</pre><br />
<br />
If a mechanism does not provide the entry point or returns GSS_S_BAD_MECH, then the name is mapped as described above.<br />
<br />
The Kerberos and SPNEGO mechanisms have been updated to return GS2-KRB5 and SPNEGO, respectively, as their SASL names.<br />
<br />
==Status==<br />
<br />
Implemented and tested with a prototype GS2 implementation, as well as a mechanism plugin.<br />
<br />
==Examples==<br />
<br />
A list of GS2 mechanisms.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/Camellia_encryption&diff=3284Projects/Camellia encryption2010-05-11T15:13:39Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
== Camellia Introduction ==<br />
<br />
Camellia is a symmetric key block cipher developed jointly in 2000 by world top class encryption researchers at NTT and Mitsubishi Electric Corporation. Technologically speaking, Camellia naturally has not only a high level of security, but also excellent efficiency and practical characteristics. It can be implemented at high performance by software on various platforms. In regard to hardware implementation, compact and low-power consumption type implementation as well as high-speed implementation is possible.<br />
<br />
Based on these technological advantages, Camellia has been internationally recognized. For example, the selection project on the European recommendation of strong cryptographic primitives (NESSIE) evaluated Camellia to have "many similarities to the AES, so much of the analysis for the AES is also applicable to Camellia." Currently, Camellia is the only cipher internationally recognized which has the same level of security and performance as AES.<br />
<br />
Camellia already has been adopted by the IETF and other international standardization organizations. In particular, the IETF has published specifications for the use of Camellia with IPsec, TLS, and others. Camellia is one of the three ISO/IEC international standard 128-bit block ciphers (Camellia, AES, and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project. In addition, it was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japanese CRYPTREC (Cryptography Research and Evaluation Committees).<br />
<br />
Since optimized source code is available under several open source licenses, Camellia has also been adopted by several open source projects (OpenSSL, BouncyCastel, GnuTLS, FreeBSD, and Linux). Furthermore, it is also adopted by Mozilla and Camellia is ready for use with Firefox3.0 released in June 2008. In addition, Camellia has also adopted by IAIK-JCE and iSaSiLk toolkits(for SSL/TLS library).<br />
<br />
NTT and Mitsubishi Electric Corporation grant royalty-free licenses of the essential patents for Camellia in order to establish a leadership role toward achieving a low-cost secure advanced telecommunication society through the proliferation and promotion of Camellia that contribute to the construction of an environment in which various security products and services can be used widely.<br />
<br />
In accordance with an agreement between NTT and Mitsubishi, Camellia essential patents can be used at no charge by any Camellia user without concluding such royalty-free licensing agreement hereafter. For details, please see the Intellectual Property Information page.<br />
<br />
URL: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html<br />
<br />
== Project Proposal ==<br />
<br />
We propose the addition of the Camellia algorithm for Kerberos V5(KRB5). In the configuration files, the Camellia encryption types to be supported initially are the following:<br />
<br />
* camellia256-cts-hmac-sha1-96/camellia256-cts: Camellia-256 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia128-cts-hmac-sha1-96/camellia128-cts: Camellia-128 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia256-ccm-128/camellia256-ccm: Camellia-256 CCM mode with 128-bit MAC<br />
* camellia128-ccm-128/camellia128-ccm: Camellia-128 CCM mode with 128-bit MAC<br />
<br />
These encryption types are supported for all Kerberos operations.<br />
<br />
Note that because CCM provides both authentication and encryption, the associated Kerberos checksum type is only used for explicit checksum operations (not for authenticating encrypted plaintexts). The 128-bit MAC above refers to both the CBC-MAC specified by CCM, and a 128-bit CMAC available as the following checksum types:<br />
<br />
* cmac-128-camellia128: 128-bit CMAC with Camellia-128 bit key<br />
* cmac-128-camellia256: 128-bit CMAC with Camellia-256 bit key<br />
<br />
== Impact on Enctypes ==<br />
<br />
We will initially be adding two Enctypes for Camellia-CTS to the Supported Encryption types for KRB5. We will also be submitting the relevant internet-drafts to the IETF for approval.<br />
<br />
These Enctypes are as follows:<br />
<br />
camellia256-cts-hmac-sha1-96.<br />
camellia256-cts.<br />
Camellia-256 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia128-cts-hmac-sha1-96.<br />
camellia128-cts.<br />
Camellia-128 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
== Impact on Crypto-Library ==<br />
<br />
<br />
We do not anticipate any negative impact (of adding Camellia) on the KRB5 crypto-library.<br />
<br />
We believe adding Camellia support will be beneficial for Kerberos adoption in Japan and other countries, as the Camellia algorithm has been internationally evaluated as the same level of security and performance as AES.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/camellia-ccm users/lhoward/camellia-ccm branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/Camellia_encryption&diff=3279Projects/Camellia encryption2010-05-10T17:28:57Z<p>Lukeh: /* Project Proposal */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
== Camellia Introduction ==<br />
<br />
Camellia is a symmetric key block cipher developed jointly in 2000 by world top class encryption researchers at NTT and Mitsubishi Electric Corporation. Technologically speaking, Camellia naturally has not only a high level of security, but also excellent efficiency and practical characteristics. It can be implemented at high performance by software on various platforms. In regard to hardware implementation, compact and low-power consumption type implementation as well as high-speed implementation is possible.<br />
<br />
Based on these technological advantages, Camellia has been internationally recognized. For example, the selection project on the European recommendation of strong cryptographic primitives (NESSIE) evaluated Camellia to have "many similarities to the AES, so much of the analysis for the AES is also applicable to Camellia." Currently, Camellia is the only cipher internationally recognized which has the same level of security and performance as AES.<br />
<br />
Camellia already has been adopted by the IETF and other international standardization organizations. In particular, the IETF has published specifications for the use of Camellia with IPsec, TLS, and others. Camellia is one of the three ISO/IEC international standard 128-bit block ciphers (Camellia, AES, and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project. In addition, it was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japanese CRYPTREC (Cryptography Research and Evaluation Committees).<br />
<br />
Since optimized source code is available under several open source licenses, Camellia has also been adopted by several open source projects (OpenSSL, BouncyCastel, GnuTLS, FreeBSD, and Linux). Furthermore, it is also adopted by Mozilla and Camellia is ready for use with Firefox3.0 released in June 2008. In addition, Camellia has also adopted by IAIK-JCE and iSaSiLk toolkits(for SSL/TLS library).<br />
<br />
NTT and Mitsubishi Electric Corporation grant royalty-free licenses of the essential patents for Camellia in order to establish a leadership role toward achieving a low-cost secure advanced telecommunication society through the proliferation and promotion of Camellia that contribute to the construction of an environment in which various security products and services can be used widely.<br />
<br />
In accordance with an agreement between NTT and Mitsubishi, Camellia essential patents can be used at no charge by any Camellia user without concluding such royalty-free licensing agreement hereafter. For details, please see the Intellectual Property Information page.<br />
<br />
URL: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html<br />
<br />
== Project Proposal ==<br />
<br />
We propose the addition of the Camellia algorithm for Kerberos V5(KRB5). In the configuration files, the Camellia encryption types to be supported initially are the following:<br />
<br />
* camellia256-cts-hmac-sha1-96/camellia256-cts: Camellia-256 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia128-cts-hmac-sha1-96/camellia128-cts: Camellia-128 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia256-ccm-128/camellia256-ccm: Camellia-256 CCM mode with 128-bit MAC<br />
* camellia128-ccm-128/camellia128-ccm: Camellia-128 CCM mode with 128-bit MAC<br />
<br />
These encryption types are supported for all Kerberos operations.<br />
<br />
Note that because CCM provides both authentication and encryption, the associated Kerberos checksum type is only used for explicit checksum operations (not for authenticating encrypted plaintexts). The 128-bit MAC above refers to both the CBC-MAC specified by CCM, and a 128-bit CMAC available as the following checksum types:<br />
<br />
* cmac-128-camellia128: 128-bit CMAC with Camellia-128 bit key<br />
* cmac-128-camellia256: 128-bit CMAC with Camellia-256 bit key<br />
<br />
== Impact on Enctypes ==<br />
<br />
We will initially be adding two Enctypes for Camellia-CTS to the Supported Encryption types for KRB5. We will also be submitting the relevant internet-drafts to the IETF for approval.<br />
<br />
These Enctypes are as follows:<br />
<br />
camellia256-cts-hmac-sha1-96.<br />
camellia256-cts.<br />
Camellia-256 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia128-cts-hmac-sha1-96.<br />
camellia128-cts.<br />
Camellia-128 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
== Impact on Crypto-Library ==<br />
<br />
<br />
We do not anticipate any negative impact (of adding Camellia) on the KRB5 crypto-library.<br />
<br />
We believe adding Camellia support will be beneficial for Kerberos adoption in Japan and other countries, as the Camellia algorithm has been internationally evaluated as the same level of security and performance as AES.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/Camellia_encryption&diff=3278Projects/Camellia encryption2010-05-10T17:28:44Z<p>Lukeh: /* Project Proposal */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
== Camellia Introduction ==<br />
<br />
Camellia is a symmetric key block cipher developed jointly in 2000 by world top class encryption researchers at NTT and Mitsubishi Electric Corporation. Technologically speaking, Camellia naturally has not only a high level of security, but also excellent efficiency and practical characteristics. It can be implemented at high performance by software on various platforms. In regard to hardware implementation, compact and low-power consumption type implementation as well as high-speed implementation is possible.<br />
<br />
Based on these technological advantages, Camellia has been internationally recognized. For example, the selection project on the European recommendation of strong cryptographic primitives (NESSIE) evaluated Camellia to have "many similarities to the AES, so much of the analysis for the AES is also applicable to Camellia." Currently, Camellia is the only cipher internationally recognized which has the same level of security and performance as AES.<br />
<br />
Camellia already has been adopted by the IETF and other international standardization organizations. In particular, the IETF has published specifications for the use of Camellia with IPsec, TLS, and others. Camellia is one of the three ISO/IEC international standard 128-bit block ciphers (Camellia, AES, and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project. In addition, it was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japanese CRYPTREC (Cryptography Research and Evaluation Committees).<br />
<br />
Since optimized source code is available under several open source licenses, Camellia has also been adopted by several open source projects (OpenSSL, BouncyCastel, GnuTLS, FreeBSD, and Linux). Furthermore, it is also adopted by Mozilla and Camellia is ready for use with Firefox3.0 released in June 2008. In addition, Camellia has also adopted by IAIK-JCE and iSaSiLk toolkits(for SSL/TLS library).<br />
<br />
NTT and Mitsubishi Electric Corporation grant royalty-free licenses of the essential patents for Camellia in order to establish a leadership role toward achieving a low-cost secure advanced telecommunication society through the proliferation and promotion of Camellia that contribute to the construction of an environment in which various security products and services can be used widely.<br />
<br />
In accordance with an agreement between NTT and Mitsubishi, Camellia essential patents can be used at no charge by any Camellia user without concluding such royalty-free licensing agreement hereafter. For details, please see the Intellectual Property Information page.<br />
<br />
URL: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html<br />
<br />
== Project Proposal ==<br />
<br />
We propose the addition of the Camellia algorithm for Kerberos V5(KRB5). In the configuration files, the Camellia encryption types to be supported initially are the following:<br />
<br />
* camellia256-cts-hmac-sha1-96/camellia256-cts: Camellia-256 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia128-cts-hmac-sha1-96/camellia128-cts: Camellia-128 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia256-ccm-128/camellia256-ccm: Camellia-256 CCM mode with 128-bit MAC<br />
* camellia128-ccm-128/camellia128-ccm: Camellia-128 CCM mode with 128-bit MAC<br />
<br />
These encryption types are supported for all Kerberos operations.<br />
<br />
Note that because CCM provides both authentication and encryption, the associated Kerberos checksum type is only used for explicit checksum operations (not for authenticating encrypted plaintexts). The 128-bit MAC above refers to both the CBC-MAC specified by CCM, and a 128-bit CMAC available as the following checksumtypes:<br />
<br />
* cmac-128-camellia128: 128-bit CMAC with Camellia-128 bit key<br />
* cmac-128-camellia256: 128-bit CMAC with Camellia-256 bit key<br />
<br />
== Impact on Enctypes ==<br />
<br />
We will initially be adding two Enctypes for Camellia-CTS to the Supported Encryption types for KRB5. We will also be submitting the relevant internet-drafts to the IETF for approval.<br />
<br />
These Enctypes are as follows:<br />
<br />
camellia256-cts-hmac-sha1-96.<br />
camellia256-cts.<br />
Camellia-256 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia128-cts-hmac-sha1-96.<br />
camellia128-cts.<br />
Camellia-128 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
== Impact on Crypto-Library ==<br />
<br />
<br />
We do not anticipate any negative impact (of adding Camellia) on the KRB5 crypto-library.<br />
<br />
We believe adding Camellia support will be beneficial for Kerberos adoption in Japan and other countries, as the Camellia algorithm has been internationally evaluated as the same level of security and performance as AES.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/Camellia_encryption&diff=3277Projects/Camellia encryption2010-05-10T17:27:32Z<p>Lukeh: /* Project Proposal */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
== Camellia Introduction ==<br />
<br />
Camellia is a symmetric key block cipher developed jointly in 2000 by world top class encryption researchers at NTT and Mitsubishi Electric Corporation. Technologically speaking, Camellia naturally has not only a high level of security, but also excellent efficiency and practical characteristics. It can be implemented at high performance by software on various platforms. In regard to hardware implementation, compact and low-power consumption type implementation as well as high-speed implementation is possible.<br />
<br />
Based on these technological advantages, Camellia has been internationally recognized. For example, the selection project on the European recommendation of strong cryptographic primitives (NESSIE) evaluated Camellia to have "many similarities to the AES, so much of the analysis for the AES is also applicable to Camellia." Currently, Camellia is the only cipher internationally recognized which has the same level of security and performance as AES.<br />
<br />
Camellia already has been adopted by the IETF and other international standardization organizations. In particular, the IETF has published specifications for the use of Camellia with IPsec, TLS, and others. Camellia is one of the three ISO/IEC international standard 128-bit block ciphers (Camellia, AES, and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project. In addition, it was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japanese CRYPTREC (Cryptography Research and Evaluation Committees).<br />
<br />
Since optimized source code is available under several open source licenses, Camellia has also been adopted by several open source projects (OpenSSL, BouncyCastel, GnuTLS, FreeBSD, and Linux). Furthermore, it is also adopted by Mozilla and Camellia is ready for use with Firefox3.0 released in June 2008. In addition, Camellia has also adopted by IAIK-JCE and iSaSiLk toolkits(for SSL/TLS library).<br />
<br />
NTT and Mitsubishi Electric Corporation grant royalty-free licenses of the essential patents for Camellia in order to establish a leadership role toward achieving a low-cost secure advanced telecommunication society through the proliferation and promotion of Camellia that contribute to the construction of an environment in which various security products and services can be used widely.<br />
<br />
In accordance with an agreement between NTT and Mitsubishi, Camellia essential patents can be used at no charge by any Camellia user without concluding such royalty-free licensing agreement hereafter. For details, please see the Intellectual Property Information page.<br />
<br />
URL: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html<br />
<br />
== Project Proposal ==<br />
<br />
We propose the addition of the Camellia algorithm for Kerberos V5(KRB5). In the configuration files, the Camellia encryption types to be supported initially are the following:<br />
<br />
* camellia256-cts-hmac-sha1-96/camellia256-cts: Camellia-256 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia128-cts-hmac-sha1-96/camellia128-cts: Camellia-128 CTS mode with 96-bit SHA-1 HMAC<br />
* camellia256-ccm-128/camellia256-ccm: Camellia-256 CCM mode with 128-bit MAC<br />
* camellia128-ccm-128/camellia128-ccm: Camellia-128 CCM mode with 128-bit MAC<br />
<br />
These encryption types are supported for all Kerberos operations.<br />
<br />
Note that because CCM provides both authentication and encryption, the associated Kerberos checksum type is only used for explicit checksum operations (not for authenticating encrypted plaintexts). The 128-bit MAC above refers to both the CBC-MAC specified by CCM, and a 128-bit CMAC available as a Kerberos checksum type.<br />
<br />
== Impact on Enctypes ==<br />
<br />
We will initially be adding two Enctypes for Camellia-CTS to the Supported Encryption types for KRB5. We will also be submitting the relevant internet-drafts to the IETF for approval.<br />
<br />
These Enctypes are as follows:<br />
<br />
camellia256-cts-hmac-sha1-96.<br />
camellia256-cts.<br />
Camellia-256 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia128-cts-hmac-sha1-96.<br />
camellia128-cts.<br />
Camellia-128 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
== Impact on Crypto-Library ==<br />
<br />
<br />
We do not anticipate any negative impact (of adding Camellia) on the KRB5 crypto-library.<br />
<br />
We believe adding Camellia support will be beneficial for Kerberos adoption in Japan and other countries, as the Camellia algorithm has been internationally evaluated as the same level of security and performance as AES.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/Camellia_encryption&diff=3276Projects/Camellia encryption2010-05-10T17:26:26Z<p>Lukeh: /* Project Proposal */</p>
<hr />
<div>{{project-early}}<br />
{{project-target|1.9}}<br />
<br />
== Camellia Introduction ==<br />
<br />
Camellia is a symmetric key block cipher developed jointly in 2000 by world top class encryption researchers at NTT and Mitsubishi Electric Corporation. Technologically speaking, Camellia naturally has not only a high level of security, but also excellent efficiency and practical characteristics. It can be implemented at high performance by software on various platforms. In regard to hardware implementation, compact and low-power consumption type implementation as well as high-speed implementation is possible.<br />
<br />
Based on these technological advantages, Camellia has been internationally recognized. For example, the selection project on the European recommendation of strong cryptographic primitives (NESSIE) evaluated Camellia to have "many similarities to the AES, so much of the analysis for the AES is also applicable to Camellia." Currently, Camellia is the only cipher internationally recognized which has the same level of security and performance as AES.<br />
<br />
Camellia already has been adopted by the IETF and other international standardization organizations. In particular, the IETF has published specifications for the use of Camellia with IPsec, TLS, and others. Camellia is one of the three ISO/IEC international standard 128-bit block ciphers (Camellia, AES, and SEED). Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project. In addition, it was included in the list of cryptographic techniques for Japanese e-Government systems that was selected by the Japanese CRYPTREC (Cryptography Research and Evaluation Committees).<br />
<br />
Since optimized source code is available under several open source licenses, Camellia has also been adopted by several open source projects (OpenSSL, BouncyCastel, GnuTLS, FreeBSD, and Linux). Furthermore, it is also adopted by Mozilla and Camellia is ready for use with Firefox3.0 released in June 2008. In addition, Camellia has also adopted by IAIK-JCE and iSaSiLk toolkits(for SSL/TLS library).<br />
<br />
NTT and Mitsubishi Electric Corporation grant royalty-free licenses of the essential patents for Camellia in order to establish a leadership role toward achieving a low-cost secure advanced telecommunication society through the proliferation and promotion of Camellia that contribute to the construction of an environment in which various security products and services can be used widely.<br />
<br />
In accordance with an agreement between NTT and Mitsubishi, Camellia essential patents can be used at no charge by any Camellia user without concluding such royalty-free licensing agreement hereafter. For details, please see the Intellectual Property Information page.<br />
<br />
URL: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html<br />
<br />
== Project Proposal ==<br />
<br />
We propose the addition of the Camellia algorithm for Kerberos V5(KRB5). In the configuration files, the Camellia encryption types to be supported initially are the following:<br />
<br />
camellia256-cts-hmac-sha1-96.<br />
camellia256-cts.<br />
Camellia-256 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia128-cts-hmac-sha1-96.<br />
camellia128-cts.<br />
Camellia-128 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia256-ccm-128.<br />
camellia256-ccm.<br />
Camellia-256 CCM mode with 128-bit MAC.<br />
<br />
camellia128-ccm-128.<br />
camellia128-ccm.<br />
Camellia-128 CCM mode with 128-bit MAC.<br />
<br />
These encryption types are supported for all Kerberos operations.<br />
<br />
Note that because CCM provides both authentication and encryption, the associated Kerberos checksum type is only used for explicit checksum operations (not for authenticating encryption plaintexts). The 128-bit MAC above refers to both the CBC-MAC specified by CCM, and a 128-bit CMAC surfaced as a Kerberos checksum type.<br />
<br />
Additionally, we will do a CCM (or GCM) implementation once the CTS implementation has been completed.<br />
<br />
== Impact on Enctypes ==<br />
<br />
We will initially be adding two Enctypes for Camellia-CTS to the Supported Encryption types for KRB5. We will also be submitting the relevant internet-drafts to the IETF for approval.<br />
<br />
These Enctypes are as follows:<br />
<br />
camellia256-cts-hmac-sha1-96.<br />
camellia256-cts.<br />
Camellia-256 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
camellia128-cts-hmac-sha1-96.<br />
camellia128-cts.<br />
Camellia-128 CTS mode with 96-bit SHA-1 HMAC.<br />
<br />
== Impact on Crypto-Library ==<br />
<br />
<br />
We do not anticipate any negative impact (of adding Camellia) on the KRB5 crypto-library.<br />
<br />
We believe adding Camellia support will be beneficial for Kerberos adoption in Japan and other countries, as the Camellia algorithm has been internationally evaluated as the same level of security and performance as AES.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/SignedPathNamingExts&diff=3275Projects/SignedPathNamingExts2010-05-09T10:57:46Z<p>Lukeh: /* Status */</p>
<hr />
<div>{{project-rel|1.9}}<br />
<br />
==Background==<br />
<br />
Implement a mechanism for exposing the constrained delegation path via GSS naming extensions.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
A new authorization data naming extensions backend is added in src/lib/krb5/krb/s4u_authdata.c. This maps the "delegated" member of krb5_ad_signedpath (KRB5_AUTHDATA_SIGNTICKET) to the urn:constrained-delegation:transited-services attribute.<br />
<br />
No support for the transited services encoding in [MS-PAC] is yet provided, because that would require an NDR interpreter within the krb5 runtime. This would be more suitably implemented as a third-party plugin.<br />
<br />
==Open issues==<br />
<br />
It's impossible to mark this attribute as authenticated because the delegation path is signed with the TGS key, which the GSS acceptor does not have. A KDC that supports KRB5_AUTHDATA_SIGNTICKET will reject such user-submitted authorization data, but the acceptor has no in-band knowledge of what kind of KDC issued the ticket.<br />
<br />
Interestingly this would not be an issue with the [MS-PAC] delegation path, because it is also signed with the acceptor key.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/signedpath-naming-exts users/lhoward/signedpath-naming-exts branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/SignedPathNamingExts&diff=3274Projects/SignedPathNamingExts2010-05-08T17:27:46Z<p>Lukeh: </p>
<hr />
<div>{{project-rel|1.9}}<br />
<br />
==Background==<br />
<br />
Implement a mechanism for exposing the constrained delegation path via GSS naming extensions.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
A new authorization data naming extensions backend is added in src/lib/krb5/krb/s4u_authdata.c. This maps the "delegated" member of krb5_ad_signedpath (KRB5_AUTHDATA_SIGNTICKET) to the urn:constrained-delegation:transited-services attribute.<br />
<br />
No support for the transited services encoding in [MS-PAC] is yet provided, because that would require an NDR interpreter within the krb5 runtime. This would be more suitably implemented as a third-party plugin.<br />
<br />
==Open issues==<br />
<br />
It's impossible to mark this attribute as authenticated because the delegation path is signed with the TGS key, which the GSS acceptor does not have. A KDC that supports KRB5_AUTHDATA_SIGNTICKET will reject such user-submitted authorization data, but the acceptor has no in-band knowledge of what kind of KDC issued the ticket.<br />
<br />
Interestingly this would not be an issue with the [MS-PAC] delegation path, because it is also signed with the acceptor key.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/signedpath-naming-exts branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/SignedPathNamingExts&diff=3273Projects/SignedPathNamingExts2010-05-08T17:21:24Z<p>Lukeh: New page: {{project-rel|1.9}} ==Background== Implement a mechanism for exposing the constrained delegation transited services path via GSS naming extensions. ==Architecture== ==Implementation== ...</p>
<hr />
<div>{{project-rel|1.9}}<br />
<br />
==Background==<br />
<br />
Implement a mechanism for exposing the constrained delegation transited services path via GSS naming extensions.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
A new authorization data naming extensions backend is added in src/lib/krb5/krb/s4u_authdata.c. This maps the "delegated" member of krb5_ad_signedpath (KRB5_AUTHDATA_SIGNTICKET) to the urn:constrained-delegation:transited-services attribute.<br />
<br />
No support for the transited services encoding in [MS-PAC] is yet provided, because that would require an NDR interpreter within the krb5 runtime. This would be more suitably implemented as a third-party plugin.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/signedpath-naming-exts branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GSSExtras&diff=3031Projects/GSSExtras2009-12-01T19:39:23Z<p>Lukeh: </p>
<hr />
<div>{{project-review|2009-12-08}}<br />
<br />
==Background==<br />
<br />
Implement:<br />
<br />
* gss_pseudo_random (RFC 4401 and RFC 4402)<br />
* gss_store_cred (RFC 5588)<br />
* gss_context_query_attributes for GSS_C_ATTR_STREAM_SIZES (from Heimdal)<br />
<br />
==Architecture==<br />
<br />
Each function touches:<br />
<br />
* the mechglue<br />
* the Kerberos 5 mechanism<br />
* SPNEGO<br />
<br />
==Implementation==<br />
<br />
===gss_pseudo_random===<br />
<br />
Implemented in terms of krb5_c_prf (why no krb5_k_prf?)<br />
<br />
This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_store_cred===<br />
<br />
Copies credentials into default credentials cache (like Solaris, requires default_cred argument be true.) This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_context_query_attributes===<br />
<br />
<pre><br />
typedef struct gss_context_stream_sizes_struct {<br />
size_t header;<br />
size_t trailer;<br />
size_t max_msg_size;<br />
size_t buffers;<br />
size_t blocksize;<br />
} gss_context_stream_sizes;<br />
<br />
GSS_DLLIMP extern gss_OID GSS_C_ATTR_STREAM_SIZES;<br />
<br />
OM_uint32 KRB5_CALLCONV gss_context_query_attributes<br />
(<br />
OM_uint32 *, /* minor_status */<br />
const gss_ctx_id_t, /* context_handle */<br />
const gss_OID, /* attribute */<br />
void *, /* data */<br />
size_t /* len */<br />
);<br />
</pre><br />
<br />
The API is similar to gss_inquire_sec_context_by_oid() except it takes a void * pointer instead of a buffer set. A single OID is presently supported, which returns the sizes of different components in a GSS wrap stream buffer.<br />
<br />
This is implemented in terms of gss_wrap_size_limit() and gss_wrap_iov_length(), which begs the question: why do we need this API? (Particularly given that it ostensibly serves the same function as gss_inquire_sec_context_by_oid()). It is slightly more convenient to use though. If we do merge this, then we should possibly consider whether some of the other gss_inquire_sec_context_by_oid()-based APIs (internal or otherwise) should be re-factored in terms of this function.<br />
<br />
==Open issues==<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/gssexts branch].<br />
<br />
Tests are in src/tests/gssapi/t_gssexts.c. This is a variant of t_s4u, the usage is the same. Sorry, no individual tests yet: this file exercises all APIs.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GSSExtras&diff=3030Projects/GSSExtras2009-12-01T19:39:01Z<p>Lukeh: /* gss_context_query_attributes */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement:<br />
<br />
* gss_pseudo_random (RFC 4401 and RFC 4402)<br />
* gss_store_cred (RFC 5588)<br />
* gss_context_query_attributes for GSS_C_ATTR_STREAM_SIZES (from Heimdal)<br />
<br />
==Architecture==<br />
<br />
Each function touches:<br />
<br />
* the mechglue<br />
* the Kerberos 5 mechanism<br />
* SPNEGO<br />
<br />
==Implementation==<br />
<br />
===gss_pseudo_random===<br />
<br />
Implemented in terms of krb5_c_prf (why no krb5_k_prf?)<br />
<br />
This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_store_cred===<br />
<br />
Copies credentials into default credentials cache (like Solaris, requires default_cred argument be true.) This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_context_query_attributes===<br />
<br />
<pre><br />
typedef struct gss_context_stream_sizes_struct {<br />
size_t header;<br />
size_t trailer;<br />
size_t max_msg_size;<br />
size_t buffers;<br />
size_t blocksize;<br />
} gss_context_stream_sizes;<br />
<br />
GSS_DLLIMP extern gss_OID GSS_C_ATTR_STREAM_SIZES;<br />
<br />
OM_uint32 KRB5_CALLCONV gss_context_query_attributes<br />
(<br />
OM_uint32 *, /* minor_status */<br />
const gss_ctx_id_t, /* context_handle */<br />
const gss_OID, /* attribute */<br />
void *, /* data */<br />
size_t /* len */<br />
);<br />
</pre><br />
<br />
The API is similar to gss_inquire_sec_context_by_oid() except it takes a void * pointer instead of a buffer set. A single OID is presently supported, which returns the sizes of different components in a GSS wrap stream buffer.<br />
<br />
This is implemented in terms of gss_wrap_size_limit() and gss_wrap_iov_length(), which begs the question: why do we need this API? (Particularly given that it ostensibly serves the same function as gss_inquire_sec_context_by_oid()). It is slightly more convenient to use though. If we do merge this, then we should possibly consider whether some of the other gss_inquire_sec_context_by_oid()-based APIs (internal or otherwise) should be re-factored in terms of this function.<br />
<br />
==Open issues==<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/gssexts branch].<br />
<br />
Tests are in src/tests/gssapi/t_gssexts.c. This is a variant of t_s4u, the usage is the same. Sorry, no individual tests yet: this file exercises all APIs.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GSSExtras&diff=3012Projects/GSSExtras2009-11-24T19:00:46Z<p>Lukeh: /* Status */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement:<br />
<br />
* gss_pseudo_random (RFC 4401 and RFC 4402)<br />
* gss_store_cred (RFC 5588)<br />
* gss_context_query_attributes for GSS_C_ATTR_STREAM_SIZES (from Heimdal)<br />
<br />
==Architecture==<br />
<br />
Each function touches:<br />
<br />
* the mechglue<br />
* the Kerberos 5 mechanism<br />
* SPNEGO<br />
<br />
==Implementation==<br />
<br />
===gss_pseudo_random===<br />
<br />
Implemented in terms of krb5_c_prf (why no krb5_k_prf?)<br />
<br />
This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_store_cred===<br />
<br />
Copies credentials into default credentials cache (like Solaris, requires default_cred argument be true.) This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_context_query_attributes===<br />
<br />
<pre><br />
typedef struct gss_context_stream_sizes_struct {<br />
size_t header;<br />
size_t trailer;<br />
size_t max_msg_size;<br />
size_t buffers;<br />
size_t blocksize;<br />
} gss_context_stream_sizes;<br />
<br />
GSS_DLLIMP extern gss_OID GSS_C_ATTR_STREAM_SIZES;<br />
<br />
OM_uint32 KRB5_CALLCONV gss_context_query_attributes<br />
(<br />
OM_uint32 *, /* minor_status */<br />
const gss_ctx_id_t, /* context_handle */<br />
const gss_OID, /* attribute */<br />
void *, /* data */<br />
size_t /* len */<br />
);<br />
</pre><br />
<br />
The API is similar to gss_inquire_sec_context_by_oid() except it takes a void * pointer instead of a buffer set. A single OID is presently supported, which returns the sizes of different components in a GSS wrap stream buffer.<br />
<br />
This is implemented in terms of gss_wrap_size_limit() and gss_wrap_iov_length(), which begs the question: why do we need this API? (Particularly given that it ostensibly serves the same function as gss_inquire_sec_context_by_oid()). It is slightly more convenient to use though.<br />
<br />
So, I would propose we don't merge this.<br />
<br />
==Open issues==<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/gssexts branch].<br />
<br />
Tests are in src/tests/gssapi/t_gssexts.c. This is a variant of t_s4u, the usage is the same. Sorry, no individual tests yet: this file exercises all APIs.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GSSExtras&diff=3011Projects/GSSExtras2009-11-24T18:59:28Z<p>Lukeh: </p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement:<br />
<br />
* gss_pseudo_random (RFC 4401 and RFC 4402)<br />
* gss_store_cred (RFC 5588)<br />
* gss_context_query_attributes for GSS_C_ATTR_STREAM_SIZES (from Heimdal)<br />
<br />
==Architecture==<br />
<br />
Each function touches:<br />
<br />
* the mechglue<br />
* the Kerberos 5 mechanism<br />
* SPNEGO<br />
<br />
==Implementation==<br />
<br />
===gss_pseudo_random===<br />
<br />
Implemented in terms of krb5_c_prf (why no krb5_k_prf?)<br />
<br />
This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_store_cred===<br />
<br />
Copies credentials into default credentials cache (like Solaris, requires default_cred argument be true.) This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_context_query_attributes===<br />
<br />
<pre><br />
typedef struct gss_context_stream_sizes_struct {<br />
size_t header;<br />
size_t trailer;<br />
size_t max_msg_size;<br />
size_t buffers;<br />
size_t blocksize;<br />
} gss_context_stream_sizes;<br />
<br />
GSS_DLLIMP extern gss_OID GSS_C_ATTR_STREAM_SIZES;<br />
<br />
OM_uint32 KRB5_CALLCONV gss_context_query_attributes<br />
(<br />
OM_uint32 *, /* minor_status */<br />
const gss_ctx_id_t, /* context_handle */<br />
const gss_OID, /* attribute */<br />
void *, /* data */<br />
size_t /* len */<br />
);<br />
</pre><br />
<br />
The API is similar to gss_inquire_sec_context_by_oid() except it takes a void * pointer instead of a buffer set. A single OID is presently supported, which returns the sizes of different components in a GSS wrap stream buffer.<br />
<br />
This is implemented in terms of gss_wrap_size_limit() and gss_wrap_iov_length(), which begs the question: why do we need this API? (Particularly given that it ostensibly serves the same function as gss_inquire_sec_context_by_oid()). It is slightly more convenient to use though.<br />
<br />
So, I would propose we don't merge this.<br />
<br />
==Open issues==<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/gssexts branch].<br />
<br />
Tests are in src/tests/gssapi/t_gssexts.c. Sorry, no individual tests yet.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GSSExtras&diff=3007Projects/GSSExtras2009-11-24T09:42:13Z<p>Lukeh: /* gss_context_query_attributes */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement:<br />
<br />
* gss_pseudo_random (RFC 4401 and RFC 4402)<br />
* gss_store_cred (RFC 5588)<br />
* gss_context_query_attributes for GSS_C_ATTR_STREAM_SIZES (from Heimdal)<br />
<br />
==Architecture==<br />
<br />
Each function touches:<br />
<br />
* the mechglue<br />
* the Kerberos 5 mechanism<br />
* SPNEGO<br />
<br />
==Implementation==<br />
<br />
===gss_pseudo_random===<br />
<br />
Implemented in terms of krb5_c_prf (why no krb5_k_prf?)<br />
<br />
This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_store_cred===<br />
<br />
Copies credentials into default credentials cache (like Solaris, requires default_cred argument be true.) This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_context_query_attributes===<br />
<br />
<pre><br />
typedef struct gss_context_stream_sizes_struct {<br />
size_t header;<br />
size_t trailer;<br />
size_t max_msg_size;<br />
size_t buffers;<br />
size_t blocksize;<br />
} gss_context_stream_sizes;<br />
<br />
GSS_DLLIMP extern gss_OID GSS_C_ATTR_STREAM_SIZES;<br />
<br />
OM_uint32 KRB5_CALLCONV gss_context_query_attributes<br />
(<br />
OM_uint32 *, /* minor_status */<br />
const gss_ctx_id_t, /* context_handle */<br />
const gss_OID, /* attribute */<br />
void *, /* data */<br />
size_t /* len */<br />
);<br />
</pre><br />
<br />
The API is similar to gss_inquire_sec_context_by_oid() except it takes a void * pointer instead of a buffer set. A single OID is presently supported, which returns the sizes of different components in a GSS wrap stream buffer.<br />
<br />
This is implemented in terms of gss_wrap_size_limit() and gss_wrap_iov_length(), which begs the question: why do we need this API? (Particularly given that it ostensibly serves the same function as gss_inquire_sec_context_by_oid()). It is slightly more convenient to use though.<br />
<br />
So, I would propose we don't merge this.<br />
<br />
==Open issues==<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/gssexts branch].<br />
<br />
Tests for PRF and query_context_attributes are in src/tests/gssapi/t_prf.c. No test for gss_store_cred() yet.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/GSSExtras&diff=3006Projects/GSSExtras2009-11-24T09:37:32Z<p>Lukeh: New page: {{project-early}} <includeonly>Category: early stage projects</includeonly> ==Background== Implement: * gss_pseudo_random (RFC 4401 and RFC 4402) * gss_store_cred (RFC 5588) * gss_...</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement:<br />
<br />
* gss_pseudo_random (RFC 4401 and RFC 4402)<br />
* gss_store_cred (RFC 5588)<br />
* gss_context_query_attributes for GSS_C_ATTR_STREAM_SIZES (from Heimdal)<br />
<br />
==Architecture==<br />
<br />
Each function touches:<br />
<br />
* the mechglue<br />
* the Kerberos 5 mechanism<br />
* SPNEGO<br />
<br />
==Implementation==<br />
<br />
===gss_pseudo_random===<br />
<br />
Implemented in terms of krb5_c_prf (why no krb5_k_prf?)<br />
<br />
This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_store_cred===<br />
<br />
Copies credentials into default credentials cache (like Solaris, requires default_cred argument be true.) This function is declared in gssapi.h instead of gssapi_ext.h because it is defined in an RFC.<br />
<br />
===gss_context_query_attributes===<br />
<br />
<pre><br />
typedef struct gss_context_stream_sizes_struct {<br />
size_t header;<br />
size_t trailer;<br />
size_t max_msg_size;<br />
size_t buffers;<br />
size_t blocksize;<br />
} gss_context_stream_sizes;<br />
<br />
GSS_DLLIMP extern gss_OID GSS_C_ATTR_STREAM_SIZES;<br />
<br />
OM_uint32 KRB5_CALLCONV gss_context_query_attributes<br />
(<br />
OM_uint32 *, /* minor_status */<br />
const gss_ctx_id_t, /* context_handle */<br />
const gss_OID, /* attribute */<br />
void *, /* data */<br />
size_t /* len */<br />
);<br />
</pre><br />
<br />
The API is similar to gss_inquire_sec_context_by_oid() except it takes a void * pointer instead of a buffer set.<br />
<br />
Implemented in terms of gss_wrap_size_limit() and gss_wrap_iov_length(), which begs the question: why do we need this API? (Particularly given that it ostensibly serves the same function as gss_inquire_sec_context_by_oid()). It is slightly more convenient to use though.<br />
<br />
So, I would propose we don't merge this.<br />
<br />
==Open issues==<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/gssexts branch].<br />
<br />
Tests for PRF and query_context_attributes are in src/tests/gssapi/t_prf.c. No test for gss_store_cred() yet.</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2976Projects/IAKERB2009-11-17T18:55:51Z<p>Lukeh: /* Open issues */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously. Note: the context retains a pointer to ccache; ccache must be valid for the lifetime of the context.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist in Heimdal, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_tkt_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_tkt_creds_free(krb5_context,<br />
krb5_tkt_creds_context);<br />
</pre><br />
<br />
Free a krb5_tkt_creds_context.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism appeared to have a bug with multiple-leg exchanges, resolved by the following patch:<br />
<br />
<pre><br />
@@ -830,7 +836,7 @@<br />
* we're done unless a MIC needs to be<br />
* generated/handled.<br />
*/<br />
- if (*send_token == CONT_TOKEN_SEND &&<br />
+ if (mechtok_in->length != 0 &&<br />
mechtok_out->length == 0 &&<br />
(!sc->mic_reqd ||<br />
!(sc->ctx_flags & GSS_C_INTEG_FLAG))) {<br />
@@ -852,7 +858,8 @@<br />
*send_token = ERROR_TOKEN_SEND;<br />
}<br />
*negState = REJECT;<br />
- }<br />
+ } else if (*send_token == NO_TOKEN_SEND)<br />
+ *send_token = CONT_TOKEN_SEND;<br />
</pre><br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
The KDC must support referrals for cross-realm operation. We probably need to fix this before merging, but the author of the IAKERB implementation is not volunteering to do this.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2975Projects/IAKERB2009-11-17T18:03:41Z<p>Lukeh: /* TGS */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously. Note: the context retains a pointer to ccache; ccache must be valid for the lifetime of the context.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist in Heimdal, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_tkt_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_tkt_creds_free(krb5_context,<br />
krb5_tkt_creds_context);<br />
</pre><br />
<br />
Free a krb5_tkt_creds_context.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism appeared to have a bug with multiple-leg exchanges, resolved by the following patch:<br />
<br />
<pre><br />
@@ -830,7 +836,7 @@<br />
* we're done unless a MIC needs to be<br />
* generated/handled.<br />
*/<br />
- if (*send_token == CONT_TOKEN_SEND &&<br />
+ if (mechtok_in->length != 0 &&<br />
mechtok_out->length == 0 &&<br />
(!sc->mic_reqd ||<br />
!(sc->ctx_flags & GSS_C_INTEG_FLAG))) {<br />
@@ -852,7 +858,8 @@<br />
*send_token = ERROR_TOKEN_SEND;<br />
}<br />
*negState = REJECT;<br />
- }<br />
+ } else if (*send_token == NO_TOKEN_SEND)<br />
+ *send_token = CONT_TOKEN_SEND;<br />
</pre><br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
The KDC must support referrals for cross-realm operation.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2974Projects/IAKERB2009-11-17T18:02:32Z<p>Lukeh: /* krb5_init_creds_init */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously. Note: the context retains a pointer to ccache; ccache must be valid for the lifetime of the context.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_tkt_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_tkt_creds_free(krb5_context,<br />
krb5_tkt_creds_context);<br />
</pre><br />
<br />
Free a krb5_tkt_creds_context.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism appeared to have a bug with multiple-leg exchanges, resolved by the following patch:<br />
<br />
<pre><br />
@@ -830,7 +836,7 @@<br />
* we're done unless a MIC needs to be<br />
* generated/handled.<br />
*/<br />
- if (*send_token == CONT_TOKEN_SEND &&<br />
+ if (mechtok_in->length != 0 &&<br />
mechtok_out->length == 0 &&<br />
(!sc->mic_reqd ||<br />
!(sc->ctx_flags & GSS_C_INTEG_FLAG))) {<br />
@@ -852,7 +858,8 @@<br />
*send_token = ERROR_TOKEN_SEND;<br />
}<br />
*negState = REJECT;<br />
- }<br />
+ } else if (*send_token == NO_TOKEN_SEND)<br />
+ *send_token = CONT_TOKEN_SEND;<br />
</pre><br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
The KDC must support referrals for cross-realm operation.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2973Projects/IAKERB2009-11-17T18:00:43Z<p>Lukeh: /* TGS */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_tkt_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_tkt_creds_free(krb5_context,<br />
krb5_tkt_creds_context);<br />
</pre><br />
<br />
Free a krb5_tkt_creds_context.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism appeared to have a bug with multiple-leg exchanges, resolved by the following patch:<br />
<br />
<pre><br />
@@ -830,7 +836,7 @@<br />
* we're done unless a MIC needs to be<br />
* generated/handled.<br />
*/<br />
- if (*send_token == CONT_TOKEN_SEND &&<br />
+ if (mechtok_in->length != 0 &&<br />
mechtok_out->length == 0 &&<br />
(!sc->mic_reqd ||<br />
!(sc->ctx_flags & GSS_C_INTEG_FLAG))) {<br />
@@ -852,7 +858,8 @@<br />
*send_token = ERROR_TOKEN_SEND;<br />
}<br />
*negState = REJECT;<br />
- }<br />
+ } else if (*send_token == NO_TOKEN_SEND)<br />
+ *send_token = CONT_TOKEN_SEND;<br />
</pre><br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
The KDC must support referrals for cross-realm operation.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2972Projects/IAKERB2009-11-17T17:59:23Z<p>Lukeh: /* SPNEGO mech */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism appeared to have a bug with multiple-leg exchanges, resolved by the following patch:<br />
<br />
<pre><br />
@@ -830,7 +836,7 @@<br />
* we're done unless a MIC needs to be<br />
* generated/handled.<br />
*/<br />
- if (*send_token == CONT_TOKEN_SEND &&<br />
+ if (mechtok_in->length != 0 &&<br />
mechtok_out->length == 0 &&<br />
(!sc->mic_reqd ||<br />
!(sc->ctx_flags & GSS_C_INTEG_FLAG))) {<br />
@@ -852,7 +858,8 @@<br />
*send_token = ERROR_TOKEN_SEND;<br />
}<br />
*negState = REJECT;<br />
- }<br />
+ } else if (*send_token == NO_TOKEN_SEND)<br />
+ *send_token = CONT_TOKEN_SEND;<br />
</pre><br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
The KDC must support referrals for cross-realm operation.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2971Projects/IAKERB2009-11-17T17:58:30Z<p>Lukeh: /* Open issues */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
The KDC must support referrals for cross-realm operation.<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2970Projects/IAKERB2009-11-17T17:54:21Z<p>Lukeh: /* Architecture */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains a header indicating the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2969Projects/IAKERB2009-11-17T17:53:45Z<p>Lukeh: /* iakerb_gss_init_sec_context() */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs: the KDC messages are wrapped inside IAKERB tokens. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2968Projects/IAKERB2009-11-17T17:53:04Z<p>Lukeh: /* IAKERB mech */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; initiators should request it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2967Projects/IAKERB2009-11-17T17:52:16Z<p>Lukeh: /* IAKERB mech */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a distinct mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2966Projects/IAKERB2009-11-17T17:52:00Z<p>Lukeh: /* Kerberos mech */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator. These variants are not used outside the Kerberos/IAKERB mechanisms; they are internal functions.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2965Projects/IAKERB2009-11-17T17:51:22Z<p>Lukeh: /* Mechglue */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password. Actual credentials acquisition is deferred until context initialisation in the case of IAKERB.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2964Projects/IAKERB2009-11-17T17:50:45Z<p>Lukeh: /* TGS */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously. However the code duplicate is minimal: the entire asynchronous ticket acquisition implementation is about 400 lines of code.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of asynchronous credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2963Projects/IAKERB2009-11-17T17:48:52Z<p>Lukeh: /* ASN.1 */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Encodes and decoders are introduced for the IAKERB-HEADER and IAKERB-FINISHED structures. The structures themselves are defined below:<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2962Projects/IAKERB2009-11-17T17:48:28Z<p>Lukeh: /* libkrb5 */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors codes are defined:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2961Projects/IAKERB2009-11-17T17:48:07Z<p>Lukeh: /* Background */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs, including MIT Kerberos 1.7 and Windows 2000 (and above), support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2960Projects/IAKERB2009-11-17T17:47:40Z<p>Lukeh: /* Architecture */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
IAKERB specifies a mechanism by which a GSS initiator can proxy KDC messages via a GSS acceptor. In order to do this, we must separate the client-side processing of KDC messages from their transmission to the KDC. This requires as asynchronous interface to the credentials acquisition functions, one which does not call sendto_kdc() but instead returns a buffer that can be forwarded to the acceptor.<br />
<br />
The IAKERB exchange consists of the aforementioned KDC exchange, wrapped in a IAKERB token (which contains the realm to which to send the request and an optional cookie). A checksum of the entire IAKERB conversation is included in the GSS checksum. Once the IAKERB exchange is complete, the Kerberos mechanism proceeds as normal. If the client already has credentials for the target service, the IAKERB exchange may be skipped entirely. If the client already has a TGT, then the AS-REQ may be skipped.<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2959Projects/IAKERB2009-11-17T17:42:12Z<p>Lukeh: /* AS */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
=====krb5_init_creds_get=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Acquires credentials synchronously.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2958Projects/IAKERB2009-11-17T17:41:33Z<p>Lukeh: /* AS */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition). The synchronous APIs are re-factored in terms of the asynchronous APIs.<br />
<br />
=====krb5_init_creds_free=====<br />
<br />
<pre><br />
void KRB5_CALLCONV<br />
krb5_init_creds_free(krb5_context context,<br />
krb5_init_creds_context ctx);<br />
</pre><br />
<br />
Free an initial credentials asynchronous context.<br />
<br />
=====krb5_init_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired initial credentials into creds.<br />
<br />
=====krb5_init_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_store_creds(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired creds in ccache.<br />
<br />
=====krb5_init_creds_get_error=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_get_error(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_error **error);<br />
</pre><br />
<br />
Get last error data from KDC, if any.<br />
<br />
=====krb5_init_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_init(krb5_context context,<br />
krb5_principal client,<br />
krb5_prompter_fct prompter,<br />
void *data,<br />
krb5_deltat start_time,<br />
krb5_get_init_creds_opt *options,<br />
krb5_init_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context for acquiring initial credentials asynchronously.<br />
<br />
=====krb5_init_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_step(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags);<br />
</pre><br />
<br />
Performs next step of asynchronous initial credentials acquisition. The in buffer is the KDC response (empty on the first call). The out buffer is to be sent by the caller to the KDC, for the indicated realm. Once the credentials have been acquired, the out buffer is empty and flags is set to 1. If the request should be retried with TCP, KRB5KRB_ERR_RESPONSE_TOO_BIG is returned.<br />
<br />
=====krb5_init_creds_set_password=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_init_creds_set_password(krb5_context context,<br />
krb5_init_creds_context ctx,<br />
const char *password);<br />
</pre><br />
<br />
Sets the password for acquiring initial credentials.<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2957Projects/IAKERB2009-11-17T17:34:58Z<p>Lukeh: /* TGS */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition).<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs. Note the synchronous APIs are not yet factored in terms of these, because of the referrals-only limitation mentioned previously.<br />
<br />
===== krb5_tkt_creds_init=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_init(krb5_context context,<br />
krb5_ccache ccache,<br />
krb5_creds *creds,<br />
int kdcopt,<br />
krb5_tkt_creds_context *pctx);<br />
</pre><br />
<br />
Initialise a new context handle for asynchronously acquiring a service ticket using a TGT.<br />
<br />
===== krb5_tkt_creds_get_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_get_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_creds *creds);<br />
</pre><br />
<br />
Copy acquired credentials into creds.<br />
<br />
===== krb5_tkt_creds_store_creds=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_store_creds(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_ccache ccache);<br />
</pre><br />
<br />
Store acquired credentials and any TGTs in ccache. If ccache is NULL, the ccache the context was initialised with is used.<br />
<br />
=====krb5_tkt_creds_step=====<br />
<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5_tkt_creds_step(krb5_context context,<br />
krb5_tkt_creds_context ctx,<br />
krb5_data *in,<br />
krb5_data *out,<br />
krb5_data *realm,<br />
unsigned int *flags)<br />
</pre><br />
<br />
Perform the next step of credentials acquisition. The in buffer should be empty on the first call; on subsequent calls it must be set to the KDC reply. The caller must send the out buffer to a KDC for realm; this is set on output. Once the credentials have been acquired, flags is set to 1.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2956Projects/IAKERB2009-11-17T17:30:21Z<p>Lukeh: /* SPNEGO mech */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition).<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
The SPNEGO mechanism was modified to handle multiple leg context exchanges. There appeared to be some bugs here.<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2955Projects/IAKERB2009-11-17T17:30:01Z<p>Lukeh: /* gss-sample= */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition).<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
===gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukehhttps://k5wiki.kerberos.org/wiki?title=Projects/IAKERB&diff=2954Projects/IAKERB2009-11-17T17:29:52Z<p>Lukeh: /* Mechglue */</p>
<hr />
<div>{{project-early}}<br />
<br />
<includeonly>[[Category: early stage projects]]</includeonly><br />
<br />
==Background==<br />
<br />
Implement [http://tools.ietf.org/html/draft-zhu-ws-kerb-03 IAKERB]. IAKERB is a protocol for proxying KDC exchanges via GSS-API.<br />
<br />
Note: the implementation requires the KDC to support referrals to work in cross-realm environments. Making the non-referral cross-realm heuristics asynchronous will be a considerable amount of work. Most modern KDCs support referrals.<br />
<br />
==Architecture==<br />
<br />
==Implementation==<br />
<br />
===libkrb5===<br />
<br />
New errors:<br />
<br />
<pre><br />
#define KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 /* The IAKERB proxy could not find a KDC */<br />
#define KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 /* The KDC did not respond to the IAKERB proxy */<br />
</pre><br />
<br />
====ASN.1====<br />
<br />
Helper functions are introduced to encode IAKERB-HEADER and IAKERB-FINISHED structures.<br />
<br />
<pre><br />
typedef struct _krb5_iakerb_header {<br />
krb5_data target_realm;<br />
krb5_data *cookie;<br />
} krb5_iakerb_header;<br />
<br />
typedef struct _krb5_iakerb_finished {<br />
krb5_checksum checksum;<br />
} krb5_iakerb_finished;<br />
</pre><br />
<br />
====AS====<br />
<br />
New APIs are required to acquire initial credentials asynchronously. These APIs are also present in Heimdal (although krb5_init_creds_store_creds() is a MIT addition).<br />
<br />
====TGS====<br />
<br />
New APIs are required to acquire credentials asynchronously using a TGT. Equivalent functionality does not exist elsewhere, but they are modelled on the synchronous APIs and on the initial credentials asynchronous APIs.<br />
<br />
===GSS===<br />
<br />
====Mechglue====<br />
<br />
The gss_acquire_cred_with_password() method from the Sun mechglue code drop is resurrected. This acquires a credentials handle given a password.<br />
<br />
====Kerberos mech====<br />
<br />
* New internal variants of gss_init_sec_context() and gss_accept_sec_context() are introduced which pass an extensible (internal) structure, krb5_gss_ctx_ext_t. This is presently used only for carrying the IAKERB conversation to be checksummed in the GSS authenticator.<br />
* Support is added for acquiring credentials using a password. In the IAKERB case, the password is stashed in the credential; otherwise the credentials are acquired immediately.<br />
<br />
====IAKERB mech====<br />
<br />
The IAKERB mechanism is implemented as a separate mechanism within the Kerberos mechanism; however, it shares all methods and data structures except for those related to the context. In the case where a IAKERB method could be passed either a Kerberos or a IAKERB context, magic numbers are used to disambiguate (similar to the SPNEGO mechanism).<br />
<br />
The IAKERB mechanism is identified by the following exported symbol:<br />
<br />
<pre><br />
GSS_DLLIMP extern const gss_OID_desc * const gss_mech_iakerb;<br />
</pre><br />
<br />
Presently IAKERB is not the preferred mechanism negotiated via SPNEGO; you must select it explicitly. Note that if the initiator has a ticket for the target service, then IAKERB will be skipped, even if the IAKERB mechanism was requested.<br />
<br />
=====iakerb_gss_init_sec_context()=====<br />
<br />
This is implemented as a state machine with three states: AS-REQ, TGS-REQ and AP-REQ. The first two states call into the libkrb5 asynchronous ticket acquisition APIs. The latter state is handled by directly calling the Kerberos 5 GSS mechanism. Once a context is complete, then the native Kerberos context handle is returned to the initiator; this avoids modifying any other Kerberos mechanism methods to be explicitly aware of IAKERB. The IAKERB conversation is saved and used to generate the IAKERB-FINISHED checksum.<br />
<br />
=====iakerb_gss_accept_sec_context()=====<br />
<br />
This method unpacks the IAKERB token and forwards it to the KDC for the indicated realm. All tokens after and including the first non-IAKERB token are forwarded to the Kerberos 5 GSS mechanism. The IAKERB conversation is saved and used to verify the IAKERB-FINISHED checksum.<br />
<br />
====SPNEGO mech====<br />
<br />
==gss-sample===<br />
<br />
gss-sample is enhanced to support acquiring credentials with a password and specifying IAKERB and SPNEGO mechanisms using command-line options.<br />
<br />
==Open issues==<br />
<br />
==Status==<br />
<br />
Code is in the [http://src.mit.edu/fisheye/browse/krb5/users/lhoward/iakerb users/lhoward/iakerb-refonly branch].</div>Lukeh