https://k5wiki.kerberos.org/w/api.php?action=feedcontributions&user=SamHartman&feedformat=atomK5Wiki - User contributions [en]2024-03-29T11:22:56ZUser contributionsMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Projects/Kadmin_hook_interface&diff=3651Projects/Kadmin hook interface2010-09-27T17:53:43Z<p>SamHartman: review</p>
<hr />
<div>{{project-review|2010-01-05}}<br />
''The Kadm5 hook interface'' provides a plugin interface for plugins to be aware of administrative operations for kadm5 principals.<br />
Plugins track the following administrative operations:<br />
* Principal creation<br />
* Change password<br />
* Principal modification<br />
The plugins are called twice: once in a precommit phase before the operation takes place and if no plugins fail and the database is updated, once in a postcommit operation.<br />
This interface is based on a proposed patch to Heimdal by Russ Allbery for the [http://www.eyrie.org/~eagle/software/krb5-sync/ krb5-sync] plugin. Russ indicated that Heimdal is likely to adopt an approach based on stackable database plugins rather than his approach. That's probably undesirable for MIT because the kadm5 API is more stable than the KDB API and because this interface is easier for plugin authors than writing a KDB module. This interface has the following changes from Russ's interface:<br />
# Opaque struct rather than void * for the module context<br />
# Include key-salt tuples for create/chpass<br />
# Add a remove entry point<br />
# Remove name and vendor entries to be consistent with other plugin framework uses<br />
== Plugin header ==<br />
<pre><br />
/* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */<br />
/*<br />
* include/krb5/kadm5_hook_plugin.h<br />
*/<br />
/*<br />
* Copyright (C) 2010 by the Massachusetts Institute of Technology.<br />
* All rights reserved.<br />
*<br />
* Export of this software from the United States of America may<br />
* require a specific license from the United States Government.<br />
* It is the responsibility of any person or organization contemplating<br />
* export to obtain such a license before exporting.<br />
*<br />
* WITHIN THAT CONSTRAINT, permission to use, copy, modify, and<br />
* distribute this software and its documentation for any purpose and<br />
* without fee is hereby granted, provided that the above copyright<br />
* notice appear in all copies and that both that copyright notice and<br />
* this permission notice appear in supporting documentation, and that<br />
* the name of M.I.T. not be used in advertising or publicity pertaining<br />
* to distribution of the software without specific, written prior<br />
* permission. Furthermore if you modify this software you must label<br />
* your software as modified software and not distribute it in such a<br />
* fashion that it might be confused with the original M.I.T. software.<br />
* M.I.T. makes no representations about the suitability of<br />
* this software for any purpose. It is provided "as is" without express<br />
* or implied warranty.<br />
*/<br />
<br />
#ifndef H_KRB5_KADM5_HOOK_PLUGIN<br />
#define H_KRB5_KADM5_HOOK_PLUGIN<br />
<br />
/**<br />
* @file krb5/krb5_kadm5_hook_plugin.h<br />
* Provide a plugin interface for kadm5 operations. This interface<br />
* permits a plugin to intercept principal modification, creation and<br />
* change password operations. Operations run at two stages: a<br />
* precommit stage that runs before the operation is committed to the<br />
* database and a postcommit operation that runs after the database<br />
* is updated.<br />
*<br />
* This interface is based on a proposed extension to Heimdal by Russ<br />
* Allbery; it is likely that Heimdal will adopt an approach based on<br />
* stacked kdb modules rather than this interface. For MIT, writing a<br />
* plugin to this interface is significantly easier than stacking kdb<br />
* modules. Also, the kadm5 interface is significantly more stable<br />
* than the kdb interface, so this approach is more desirable than<br />
* stacked kdb modules.<br />
*<br />
* This interface depends on kadm5/admin.h. As such, the interface<br />
* does not provide strong guarantees of ABI stability.<br />
*/<br />
<br />
#include <krb5/krb5.h><br />
#include <krb5/plugin.h><br />
#include <kadm5/admin.h><br />
<br />
/**<br />
* Whether the operation is being run before or after the database<br />
* update<br />
*/<br />
enum kadm5_hook_stage {<br />
KADM5_HOOK_STAGE_PRECOMMIT,<br />
KADM5_HOOK_STAGE_POSTCOMMIT<br />
};<br />
<br />
/** Opaque module data pointer*/<br />
typedef struct kadm5_hook_modinfo_st kadm5_hook_modinfo;<br />
<br />
/**<br />
* Interface for the v1 virtual table for the kadm5_hook plugin<br />
*/<br />
typedef struct kadm5_hook_vtable_1_st {<br />
<br />
/** Initialize a plugin module<br />
* @param modinfo returns newly allocated module info for future<br />
* calls. Cleaned up by the fini() function.<br />
*/<br />
kadm5_ret_t (*init)(krb5_context, kadm5_hook_modinfo **modinfo);<br />
<br />
/** Clean up a module and free @a modinfo*/<br />
void (*fini)(krb5_context, kadm5_hook_modinfo *modinfo);<br />
<br />
/** Indicates that the password is being changed.<br />
* @param stage is an integer from #kadm5_hook_stage enumeration<br />
* */<br />
kadm5_ret_t (*chpass)(krb5_context,<br />
kadm5_hook_modinfo *modinfo,<br />
int stage,<br />
krb5_principal,<br />
int n_ks_tuple,<br />
krb5_key_salt_tuple *ks_tuple,<br />
const char *newpass);<br />
<br />
/** Indicate a principal is created*/<br />
kadm5_ret_t (*create)(krb5_context,<br />
kadm5_hook_modinfo *,<br />
int stage,<br />
kadm5_principal_ent_t, long mask,<br />
int n_ks_tuple,<br />
krb5_key_salt_tuple *ks_tuple,<br />
const char *password);<br />
/** Modify a principal*/<br />
kadm5_ret_t (*modify)(krb5_context,<br />
kadm5_hook_modinfo *,<br />
int stage,<br />
kadm5_principal_ent_t, long mask);<br />
<br />
<br />
/** Indicate a principal is deleted*/<br />
kadm5_ret_t (* remove) (krb5_context,<br />
kadm5_hook_modinfo *modinfo,<br />
int stage, krb5_principal<br />
);<br />
<br />
/*End of minor version 1*/<br />
}kadm5_hook_vftable_1;<br />
<br />
#endif /*H_KRB5_KADM5_HOOK_PLUGIN*/<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Kadmin_hook_interface&diff=3650Projects/Kadmin hook interface2010-09-27T17:52:22Z<p>SamHartman: kadm5 hook inteface for krb5-sync</p>
<hr />
<div>{{project-early}}<br />
''The Kadm5 hook interface'' provides a plugin interface for plugins to be aware of administrative operations for kadm5 principals.<br />
Plugins track the following administrative operations:<br />
* Principal creation<br />
* Change password<br />
* Principal modification<br />
The plugins are called twice: once in a precommit phase before the operation takes place and if no plugins fail and the database is updated, once in a postcommit operation.<br />
This interface is based on a proposed patch to Heimdal by Russ Allbery for the [http://www.eyrie.org/~eagle/software/krb5-sync/ krb5-sync] plugin. Russ indicated that Heimdal is likely to adopt an approach based on stackable database plugins rather than his approach. That's probably undesirable for MIT because the kadm5 API is more stable than the KDB API and because this interface is easier for plugin authors than writing a KDB module. This interface has the following changes from Russ's interface:<br />
# Opaque struct rather than void * for the module context<br />
# Include key-salt tuples for create/chpass<br />
# Add a remove entry point<br />
# Remove name and vendor entries to be consistent with other plugin framework uses<br />
== Plugin header ==<br />
<pre><br />
/* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */<br />
/*<br />
* include/krb5/kadm5_hook_plugin.h<br />
*/<br />
/*<br />
* Copyright (C) 2010 by the Massachusetts Institute of Technology.<br />
* All rights reserved.<br />
*<br />
* Export of this software from the United States of America may<br />
* require a specific license from the United States Government.<br />
* It is the responsibility of any person or organization contemplating<br />
* export to obtain such a license before exporting.<br />
*<br />
* WITHIN THAT CONSTRAINT, permission to use, copy, modify, and<br />
* distribute this software and its documentation for any purpose and<br />
* without fee is hereby granted, provided that the above copyright<br />
* notice appear in all copies and that both that copyright notice and<br />
* this permission notice appear in supporting documentation, and that<br />
* the name of M.I.T. not be used in advertising or publicity pertaining<br />
* to distribution of the software without specific, written prior<br />
* permission. Furthermore if you modify this software you must label<br />
* your software as modified software and not distribute it in such a<br />
* fashion that it might be confused with the original M.I.T. software.<br />
* M.I.T. makes no representations about the suitability of<br />
* this software for any purpose. It is provided "as is" without express<br />
* or implied warranty.<br />
*/<br />
<br />
#ifndef H_KRB5_KADM5_HOOK_PLUGIN<br />
#define H_KRB5_KADM5_HOOK_PLUGIN<br />
<br />
/**<br />
* @file krb5/krb5_kadm5_hook_plugin.h<br />
* Provide a plugin interface for kadm5 operations. This interface<br />
* permits a plugin to intercept principal modification, creation and<br />
* change password operations. Operations run at two stages: a<br />
* precommit stage that runs before the operation is committed to the<br />
* database and a postcommit operation that runs after the database<br />
* is updated.<br />
*<br />
* This interface is based on a proposed extension to Heimdal by Russ<br />
* Allbery; it is likely that Heimdal will adopt an approach based on<br />
* stacked kdb modules rather than this interface. For MIT, writing a<br />
* plugin to this interface is significantly easier than stacking kdb<br />
* modules. Also, the kadm5 interface is significantly more stable<br />
* than the kdb interface, so this approach is more desirable than<br />
* stacked kdb modules.<br />
*<br />
* This interface depends on kadm5/admin.h. As such, the interface<br />
* does not provide strong guarantees of ABI stability.<br />
*/<br />
<br />
#include <krb5/krb5.h><br />
#include <krb5/plugin.h><br />
#include <kadm5/admin.h><br />
<br />
/**<br />
* Whether the operation is being run before or after the database<br />
* update<br />
*/<br />
enum kadm5_hook_stage {<br />
KADM5_HOOK_STAGE_PRECOMMIT,<br />
KADM5_HOOK_STAGE_POSTCOMMIT<br />
};<br />
<br />
/** Opaque module data pointer*/<br />
typedef struct kadm5_hook_modinfo_st kadm5_hook_modinfo;<br />
<br />
/**<br />
* Interface for the v1 virtual table for the kadm5_hook plugin<br />
*/<br />
typedef struct kadm5_hook_vtable_1_st {<br />
<br />
/** Initialize a plugin module<br />
* @param modinfo returns newly allocated module info for future<br />
* calls. Cleaned up by the fini() function.<br />
*/<br />
kadm5_ret_t (*init)(krb5_context, kadm5_hook_modinfo **modinfo);<br />
<br />
/** Clean up a module and free @a modinfo*/<br />
void (*fini)(krb5_context, kadm5_hook_modinfo *modinfo);<br />
<br />
/** Indicates that the password is being changed.<br />
* @param stage is an integer from #kadm5_hook_stage enumeration<br />
* */<br />
kadm5_ret_t (*chpass)(krb5_context,<br />
kadm5_hook_modinfo *modinfo,<br />
int stage,<br />
krb5_principal,<br />
int n_ks_tuple,<br />
krb5_key_salt_tuple *ks_tuple,<br />
const char *newpass);<br />
<br />
/** Indicate a principal is created*/<br />
kadm5_ret_t (*create)(krb5_context,<br />
kadm5_hook_modinfo *,<br />
int stage,<br />
kadm5_principal_ent_t, long mask,<br />
int n_ks_tuple,<br />
krb5_key_salt_tuple *ks_tuple,<br />
const char *password);<br />
/** Modify a principal*/<br />
kadm5_ret_t (*modify)(krb5_context,<br />
kadm5_hook_modinfo *,<br />
int stage,<br />
kadm5_principal_ent_t, long mask);<br />
<br />
<br />
/** Indicate a principal is deleted*/<br />
kadm5_ret_t (* remove) (krb5_context,<br />
kadm5_hook_modinfo *modinfo,<br />
int stage, krb5_principal<br />
);<br />
<br />
/*End of minor version 1*/<br />
}kadm5_hook_vftable_1;<br />
<br />
#endif /*H_KRB5_KADM5_HOOK_PLUGIN*/<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/What_does_God_need_with_a_password&diff=3632Projects/What does God need with a password2010-09-14T16:53:30Z<p>SamHartman: review</p>
<hr />
<div>{{project-review|2010-09-24}}<br />
''kinit -C'' with apologies to [http://www.imdb.com/title/tt0098382/quotes Star Trek].<br />
<br />
The administrator of a Kerberos database has access to all user keys within that database. This is sufficient to impersonate any user. Today, no convenient user interface is provided for logging in as a given user without changing that user's passowrd.<br />
This project proposes to add a ''-c'' (cheat) option to kinit. If this option is supplied, then the key will be extracted from the database rather than prompting for a password. This option requires that kinit be run on a KDC with read access to the Kerberos database and stash file.<br />
<br />
<br />
== Implementation ==<br />
<br />
Kinit will register and use the kdb keytab in order to access the database. It will actually contact the KDC process and go through th efull AS-REQ path. The advantage of this is that any authorization data is generated. The disadvantage is that users who require pkinit or hardware preauth cannot be logged in using this mechanism. As a result, kinit will link against libkdb5 and libkadm5srv.<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
(hash mark followed by four tilde characters) on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/What_does_God_need_with_a_password&diff=3631Projects/What does God need with a password2010-09-13T20:50:56Z<p>SamHartman: kinit -C</p>
<hr />
<div>{{project-early}}<br />
''kinit -C'' with apologies to [http://www.imdb.com/title/tt0098382/quotes Star Trek].<br />
<br />
The administrator of a Kerberos database has access to all user keys within that database. This is sufficient to impersonate any user. Today, no convenient user interface is provided for logging in as a given user without changing that user's passowrd.<br />
This project proposes to add a ''-c'' (cheat) option to kinit. If this option is supplied, then the key will be extracted from the database rather than prompting for a password. This option requires that kinit be run on a KDC with read access to the Kerberos database and stash file.<br />
<br />
<br />
== Implementation ==<br />
<br />
Kinit will register and use the kdb keytab in order to access the database. It will actually contact the KDC process and go through th efull AS-REQ path. The advantage of this is that any authorization data is generated. The disadvantage is that users who require pkinit or hardware preauth cannot be logged in using this mechanism. As a result, kinit will link against libkdb5 and libkadm5srv.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/SecurID_SAM_support&diff=3625Projects/SecurID SAM support2010-09-01T19:53:41Z<p>SamHartman: Projects/SecureID SAM Support moved to Projects/SecurID SAM support: product name incorrect</p>
<hr />
<div>{{project-review | 31 August 2010}}<br />
''The RSA SecurID SAM'' project proposes to add support for using [http://www.rsa.com/node.aspx?id=1156 SecurID] with [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-sam Single Use Authentication Mechanism] Kerberos pre-authentication.<br />
This is a backward compatibility project for sites with deployed code.<br />
==Relation to FAST and OTP Preauth ==<br />
{{idref|draft-ietf-krb-wg-otp-preauth}} describes a mechanism for using [[Projects/FAST|FAST]] with one-time password tokens such as RSA SecureID. <br />
The SAM approach is a much older solution to that problem that does not depend on FAST. The FAST/OTP approach has a number of benefits over SAM. For tokens such as SecurID, the strength of the reply key is limited to the user's long-term password. So if an attacker observes an authentication and the user has a weak long-term password, then the attacker can recover the resulting ticket. FAST addresses this weakness by using an armor key. The checksum of the SAM challenge provides the attacker with plaintext encrypted in the user's long-term password. So as originally specified, SAM is incompatible with today's recommended practice of not sending text encrypted in the long-term secret before the client has proven knowledge of that secret. It may be possible to combine SAM with encrypted timestap.<br />
Nothing stops SAM from being used in conjunction with FAST. If SAM is used with FAST, the SAM messages will not be bound to the FAST armor key. An attacker could capture messages from a non-FAST SAM exchange and include them in a FAST SAM exchange. Doing so does not appear to give the attacker any advantage. If SAM is used with FAST, then the user's long-term password is protected. However the weakness where an attacker could gain access to ciphertext encrypted in the user's password still exists.<br />
== Relation to PA-SAM-CHALLENGE ==<br />
This version of the SAM mechanism defines PA-SAM-CHALLENGE-2 and PA-SAM-RESPONSE-2. The MIT Kerberos client has supported this since 2002. The KDC contains support for some tokens with PA-SAM-CHALLENGE and no support for PA-SAM-CHALLENGE-2.<br />
== Proposed Work ==<br />
MIT has been using patches that implement the following functionality:<br />
* SAM-2 for SecurID and Cryptocard<br />
* support for {{idref|draft-ietf-krb-wg-hw-auth}}<br />
* Support for allowing a KDC to drop a packet if this KDC is not the right KDC to talk to an SecureID server.<br />
* Support for the PA-RETURN-AS-REP pre-authentication item<br />
This project will forward port the following:<br />
* Support for PA-SAM-CHALLENGE-2 SecureID<br />
* Support for KDCs dropping packets<br />
The other items will not be forward ported. In addition, support for PA-SAM-CHALLENGE will be removed from the client and KDC.<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
(hash mark followed by four tilde characters) on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
#[[User:Ghudson|Ghudson]] 00:07, 24 August 2010 (UTC)<br />
<br />
===Discussion===<br />
== Deployment ==<br />
This text should make its way into the administrator's guide.<br />
In order to deploy this mechanism, Kerberos needs to be compiled against the SecurID SDK. The SDK needs to be placed in the library and include path such that configure will find it. Then an administrator creates <t><i>principal/</i>securid</t> principals to enable SecurID for a given principal. If this is done, then the KDC will call into the SecureID SDK and request authentication from the user.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/SecureID_SAM_Support&diff=3626Projects/SecureID SAM Support2010-09-01T19:53:41Z<p>SamHartman: Projects/SecureID SAM Support moved to Projects/SecurID SAM support: product name incorrect</p>
<hr />
<div>#REDIRECT [[Projects/SecurID SAM support]]</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/SecurID_SAM_support&diff=3624Projects/SecurID SAM support2010-09-01T19:52:00Z<p>SamHartman: Secure ID->securID; add deployment info</p>
<hr />
<div>{{project-review | 31 August 2010}}<br />
''The RSA SecurID SAM'' project proposes to add support for using [http://www.rsa.com/node.aspx?id=1156 SecurID] with [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-sam Single Use Authentication Mechanism] Kerberos pre-authentication.<br />
This is a backward compatibility project for sites with deployed code.<br />
==Relation to FAST and OTP Preauth ==<br />
{{idref|draft-ietf-krb-wg-otp-preauth}} describes a mechanism for using [[Projects/FAST|FAST]] with one-time password tokens such as RSA SecureID. <br />
The SAM approach is a much older solution to that problem that does not depend on FAST. The FAST/OTP approach has a number of benefits over SAM. For tokens such as SecurID, the strength of the reply key is limited to the user's long-term password. So if an attacker observes an authentication and the user has a weak long-term password, then the attacker can recover the resulting ticket. FAST addresses this weakness by using an armor key. The checksum of the SAM challenge provides the attacker with plaintext encrypted in the user's long-term password. So as originally specified, SAM is incompatible with today's recommended practice of not sending text encrypted in the long-term secret before the client has proven knowledge of that secret. It may be possible to combine SAM with encrypted timestap.<br />
Nothing stops SAM from being used in conjunction with FAST. If SAM is used with FAST, the SAM messages will not be bound to the FAST armor key. An attacker could capture messages from a non-FAST SAM exchange and include them in a FAST SAM exchange. Doing so does not appear to give the attacker any advantage. If SAM is used with FAST, then the user's long-term password is protected. However the weakness where an attacker could gain access to ciphertext encrypted in the user's password still exists.<br />
== Relation to PA-SAM-CHALLENGE ==<br />
This version of the SAM mechanism defines PA-SAM-CHALLENGE-2 and PA-SAM-RESPONSE-2. The MIT Kerberos client has supported this since 2002. The KDC contains support for some tokens with PA-SAM-CHALLENGE and no support for PA-SAM-CHALLENGE-2.<br />
== Proposed Work ==<br />
MIT has been using patches that implement the following functionality:<br />
* SAM-2 for SecurID and Cryptocard<br />
* support for {{idref|draft-ietf-krb-wg-hw-auth}}<br />
* Support for allowing a KDC to drop a packet if this KDC is not the right KDC to talk to an SecureID server.<br />
* Support for the PA-RETURN-AS-REP pre-authentication item<br />
This project will forward port the following:<br />
* Support for PA-SAM-CHALLENGE-2 SecureID<br />
* Support for KDCs dropping packets<br />
The other items will not be forward ported. In addition, support for PA-SAM-CHALLENGE will be removed from the client and KDC.<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
(hash mark followed by four tilde characters) on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
#[[User:Ghudson|Ghudson]] 00:07, 24 August 2010 (UTC)<br />
<br />
===Discussion===<br />
== Deployment ==<br />
This text should make its way into the administrator's guide.<br />
In order to deploy this mechanism, Kerberos needs to be compiled against the SecurID SDK. The SDK needs to be placed in the library and include path such that configure will find it. Then an administrator creates <t><i>principal/</i>securid</t> principals to enable SecurID for a given principal. If this is done, then the KDC will call into the SecureID SDK and request authentication from the user.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/SecurID_SAM_support&diff=3599Projects/SecurID SAM support2010-08-23T20:21:17Z<p>SamHartman: new project</p>
<hr />
<div>{{project-review | 31 August 2010}}<br />
''The RSA Secure ID SAM'' project proposes to add support for using [http://www.rsa.com/node.aspx?id=1156 Secure ID] with [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-sam Single Use Authentication Mechanism] Kerberos pre-authentication.<br />
This is a backward compatibility project for sites with deployed code.<br />
==Relation to FAST and OTP Preauth ==<br />
{{idref|draft-ietf-krb-wg-otp-preauth}} describes a mechanism for using [[Projects/FAST|FAST]] with one-time password tokens such as RSA SecureID. <br />
The SAM approach is a much older solution to that problem that does not depend on FAST. The FAST/OTP approach has a number of benefits over SAM. For tokens such as Secure ID, the strength of the reply key is limited to the user's long-term password. So if an attacker observes an authentication and the user has a weak long-term password, then the attacker can recover the resulting ticket. FAST addresses this weakness by using an armor key. The checksum of the SAM challenge provides the attacker with plaintext encrypted in the user's long-term password. So as originally specified, SAM is incompatible with today's recommended practice of not sending text encrypted in the long-term secret before the client has proven knowledge of that secret. It may be possible to combine SAM with encrypted timestap.<br />
Nothing stops SAM from being used in conjunction with FAST. If SAM is used with FAST, the SAM messages will not be bound to the FAST armor key. An attacker could capture messages from a non-FAST SAM exchange and include them in a FAST SAM exchange. Doing so does not appear to give the attacker any advantage. If SAM is used with FAST, then the user's long-term password is protected. However the weakness where an attacker could gain access to ciphertext encrypted in the user's password still exists.<br />
== Relation to PA-SAM-CHALLENGE ==<br />
This version of the SAM mechanism defines PA-SAM-CHALLENGE-2 and PA-SAM-RESPONSE-2. The MIT Kerberos client has supported this since 2002. The KDC contains support for some tokens with PA-SAM-CHALLENGE and no support for PA-SAM-CHALLENGE-2.<br />
== Proposed Work ==<br />
MIT has been using patches that implement the following functionality:<br />
* SAM-2 for Secure ID and Cryptocard<br />
* support for {{idref|draft-ietf-krb-wg-hw-auth}}<br />
* Support for allowing a KDC to drop a packet if this KDC is not the right KDC to talk to an SecureID server.<br />
* Support for the PA-RETURN-AS-REP pre-authentication item<br />
This project will forward port the following:<br />
* Support for PA-SAM-CHALLENGE-2 SecureID<br />
* Support for KDCs dropping packets<br />
The other items will not be forward ported. In addition, support for PA-SAM-CHALLENGE will be removed from the client and KDC.<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
(hash mark followed by four tilde characters) on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Anonymous_kerberos&diff=3103Anonymous kerberos2010-01-11T16:46:37Z<p>SamHartman: add pointers to pkinit configuration</p>
<hr />
<div>'''Anonymous kerberos''' provides a mechanism for<br />
[[Principal|principals]] to authenticate to a remote service without disclosing their identity.There are two primary use cases:<br />
<br />
# Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication<br />
# Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.<br />
<br />
There are two modes of anonymous Kerberos to meet these objectives: completely anonymous and realm-exposed.<br />
<br />
==Completely anonymous ==<br />
<br />
In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm. Diffie-Hellman key exchange is used to establish a shared secret.. To use completely anonymous Kerberos:<br />
<br />
# Configure the KDC to support [[Pkinit configuration |Pkinit]]<br />
# Create the <tt>WELLKNOWN/ANONYMOUS</tt> principal in the realm to signal that fully anonymous Kerberos is enabled. Use the command <pre> addprinc -randkey WELLKNOWN/ANONYMOUS</pre> in <b>kadmin</b> to accomplish this.<br />
<br />
On the client use <tt> kinit -n @<i>REALM</i></tt> or <tt> kadmin -n<br />
@<i>REALM</i></tt> to request anonymous tickets. In klist and in<br />
service ACLs the resulting authentication will use the<br />
<tt>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</tt> [[well known principal]].<br />
<br />
== Realm Exposed Anonymous ==<br />
<br />
Alternatively, clients can authenticate normally to the KDC but request that the KDC return a credential that only exposes the client's realm. The MIT Kerberos client is believed to support this mode as of Kerberos 1.8, although the KDC currently does not support this mode.<br />
<br />
On the client, use <tt>kinit -n <i>principal</i></tt> to authenticate. A password or other credential will be required just as if the <tt>-n</tt> flag is not included. However, the resulting principal will be <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt>.<br />
<br />
== Host registration ==<br />
<br />
One common use case for anonymous Kerberos is to permit any user to register a host in a realm even if they don't have a Kerberos identity. That way, these automated installation systems can register a host for Kerberos so that Kerberos services can be established. To permit this use case, configure fully anonymous Kerberos as described above. Then, add the following entry to <tt>kadm5.acl</tt><br />
<pre><br />
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS a host/*@YOUR_REALm<br />
</pre><br />
<br />
== Implementation status ==<br />
<br />
See [[Projects/Anonymous pkinit]] for implementation status.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3101Pkinit configuration2010-01-07T20:28:19Z<p>SamHartman: fix OpenSSL; describe debugging</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use OpenSSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an OpenSSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample OpenSSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert -CAcreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem<br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.<br />
== Debugging Pkinit ==<br />
By default, the MIT Kerberos Pkinit plugin does not support debugging output. Debugging can be enabled but requires changing the source and rebuilding the plugin. Add the following line to the top of <tt>src/plugins/preauth/pkinit.h</tt><br />
<pre><br />
#define DEBUG<br />
</pre><br />
Then, rebuild the sources. Copy the generated <tt>pkinit.so</tt> into place to get debugging output.<br />
==Extensions file==<br />
<pre><br />
[ kdc_cert ]<br />
basicConstraints=CA:FALSE<br />
<br />
# Here are some examples of the usage of nsCertType. If it is omitted<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement<br />
<br />
#Pkinit EKU<br />
extendedKeyUsage = 1.3.6.1.5.2.3.5<br />
<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
# Add id-pkinit-san (pkinit subjectAlternativeName)<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name<br />
<br />
[kdc_princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:kdc_principal_seq<br />
<br />
[kdc_principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:kdc_principals<br />
<br />
[kdc_principals]<br />
princ1 = GeneralString:krbtgt<br />
princ2 = GeneralString:${ENV::REALM}<br />
<br />
[ client_cert ]<br />
<br />
# These extensions are added when 'ca' signs a request.<br />
<br />
basicConstraints=CA:FALSE<br />
<br />
keyUsage = digitalSignature, keyEncipherment, keyAgreement<br />
<br />
extendedKeyUsage = 1.3.6.1.5.2.3.4<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name<br />
<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
[princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:principal_seq<br />
<br />
[principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:principals<br />
<br />
[principals]<br />
princ1 = GeneralString:${ENV::CLIENT}<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3099Pkinit configuration2010-01-07T20:08:50Z<p>SamHartman: Users/SamHartman/Pkinit configuration moved to Pkinit configuration: promote out of user space</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert -CAcreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem<br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.<br />
==Extensions file==<br />
<pre><br />
[ kdc_cert ]<br />
basicConstraints=CA:FALSE<br />
<br />
# Here are some examples of the usage of nsCertType. If it is omitted<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement<br />
<br />
#Pkinit EKU<br />
extendedKeyUsage = 1.3.6.1.5.2.3.5<br />
<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
# Add id-pkinit-san (pkinit subjectAlternativeName)<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name<br />
<br />
[kdc_princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:kdc_principal_seq<br />
<br />
[kdc_principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:kdc_principals<br />
<br />
[kdc_principals]<br />
princ1 = GeneralString:krbtgt<br />
princ2 = GeneralString:${ENV::REALM}<br />
<br />
[ client_cert ]<br />
<br />
# These extensions are added when 'ca' signs a request.<br />
<br />
basicConstraints=CA:FALSE<br />
<br />
keyUsage = digitalSignature, keyEncipherment, keyAgreement<br />
<br />
extendedKeyUsage = 1.3.6.1.5.2.3.4<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name<br />
<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
[princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:principal_seq<br />
<br />
[principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:principals<br />
<br />
[principals]<br />
princ1 = GeneralString:${ENV::CLIENT}<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Users/SamHartman/Pkinit_configuration&diff=3100Users/SamHartman/Pkinit configuration2010-01-07T20:08:50Z<p>SamHartman: Users/SamHartman/Pkinit configuration moved to Pkinit configuration: promote out of user space</p>
<hr />
<div>#REDIRECT [[Pkinit configuration]]</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3098Pkinit configuration2010-01-07T20:07:17Z<p>SamHartman: /* Generating client certificates */</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert -CAcreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem<br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.<br />
==Extensions file==<br />
<pre><br />
[ kdc_cert ]<br />
basicConstraints=CA:FALSE<br />
<br />
# Here are some examples of the usage of nsCertType. If it is omitted<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement<br />
<br />
#Pkinit EKU<br />
extendedKeyUsage = 1.3.6.1.5.2.3.5<br />
<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
# Add id-pkinit-san (pkinit subjectAlternativeName)<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name<br />
<br />
[kdc_princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:kdc_principal_seq<br />
<br />
[kdc_principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:kdc_principals<br />
<br />
[kdc_principals]<br />
princ1 = GeneralString:krbtgt<br />
princ2 = GeneralString:${ENV::REALM}<br />
<br />
[ client_cert ]<br />
<br />
# These extensions are added when 'ca' signs a request.<br />
<br />
basicConstraints=CA:FALSE<br />
<br />
keyUsage = digitalSignature, keyEncipherment, keyAgreement<br />
<br />
extendedKeyUsage = 1.3.6.1.5.2.3.4<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name<br />
<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
[princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:principal_seq<br />
<br />
[principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:principals<br />
<br />
[principals]<br />
princ1 = GeneralString:${ENV::CLIENT}<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3097Pkinit configuration2010-01-07T20:03:34Z<p>SamHartman: /* Generating KDC certificate */</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert -CAcreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -req -in client.req -extensions client-cert -extfile pkinit_extensions <br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.<br />
==Extensions file==<br />
<pre><br />
[ kdc_cert ]<br />
basicConstraints=CA:FALSE<br />
<br />
# Here are some examples of the usage of nsCertType. If it is omitted<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement<br />
<br />
#Pkinit EKU<br />
extendedKeyUsage = 1.3.6.1.5.2.3.5<br />
<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
# Add id-pkinit-san (pkinit subjectAlternativeName)<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name<br />
<br />
[kdc_princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:kdc_principal_seq<br />
<br />
[kdc_principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:kdc_principals<br />
<br />
[kdc_principals]<br />
princ1 = GeneralString:krbtgt<br />
princ2 = GeneralString:${ENV::REALM}<br />
<br />
[ client_cert ]<br />
<br />
# These extensions are added when 'ca' signs a request.<br />
<br />
basicConstraints=CA:FALSE<br />
<br />
keyUsage = digitalSignature, keyEncipherment, keyAgreement<br />
<br />
extendedKeyUsage = 1.3.6.1.5.2.3.4<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name<br />
<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
[princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:principal_seq<br />
<br />
[principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:principals<br />
<br />
[principals]<br />
princ1 = GeneralString:${ENV::CLIENT}<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3096Pkinit configuration2010-01-07T19:52:45Z<p>SamHartman: add trailing </pre></p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc-cert -cacreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -req -in client.req -extensions client-cert -extfile pkinit_extensions <br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.<br />
==Extensions file==<br />
<pre><br />
[ kdc_cert ]<br />
basicConstraints=CA:FALSE<br />
<br />
# Here are some examples of the usage of nsCertType. If it is omitted<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement<br />
<br />
#Pkinit EKU<br />
extendedKeyUsage = 1.3.6.1.5.2.3.5<br />
<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
# Add id-pkinit-san (pkinit subjectAlternativeName)<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name<br />
<br />
[kdc_princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:kdc_principal_seq<br />
<br />
[kdc_principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:kdc_principals<br />
<br />
[kdc_principals]<br />
princ1 = GeneralString:krbtgt<br />
princ2 = GeneralString:${ENV::REALM}<br />
<br />
[ client_cert ]<br />
<br />
# These extensions are added when 'ca' signs a request.<br />
<br />
basicConstraints=CA:FALSE<br />
<br />
keyUsage = digitalSignature, keyEncipherment, keyAgreement<br />
<br />
extendedKeyUsage = 1.3.6.1.5.2.3.4<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name<br />
<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
[princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:principal_seq<br />
<br />
[principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:principals<br />
<br />
[principals]<br />
princ1 = GeneralString:${ENV::CLIENT}<br />
</pre></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3095Pkinit configuration2010-01-07T19:51:34Z<p>SamHartman: add pkinit_extensions</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc-cert -cacreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -req -in client.req -extensions client-cert -extfile pkinit_extensions <br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.<br />
==Extensions file==<br />
<pre><br />
[ kdc_cert ]<br />
basicConstraints=CA:FALSE<br />
<br />
# Here are some examples of the usage of nsCertType. If it is omitted<br />
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement<br />
<br />
#Pkinit EKU<br />
extendedKeyUsage = 1.3.6.1.5.2.3.5<br />
<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
# Add id-pkinit-san (pkinit subjectAlternativeName)<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name<br />
<br />
[kdc_princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:kdc_principal_seq<br />
<br />
[kdc_principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:kdc_principals<br />
<br />
[kdc_principals]<br />
princ1 = GeneralString:krbtgt<br />
princ2 = GeneralString:${ENV::REALM}<br />
<br />
[ client_cert ]<br />
<br />
# These extensions are added when 'ca' signs a request.<br />
<br />
basicConstraints=CA:FALSE<br />
<br />
keyUsage = digitalSignature, keyEncipherment, keyAgreement<br />
<br />
extendedKeyUsage = 1.3.6.1.5.2.3.4<br />
subjectKeyIdentifier=hash<br />
authorityKeyIdentifier=keyid,issuer<br />
<br />
<br />
subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name<br />
<br />
<br />
# Copy subject details<br />
<br />
issuerAltName=issuer:copy<br />
<br />
[princ_name]<br />
realm = EXP:0, GeneralString:${ENV::REALM}<br />
principal_name = EXP:1, SEQUENCE:principal_seq<br />
<br />
[principal_seq]<br />
name_type = EXP:0, INTEGER:1<br />
name_string = EXP:1, SEQUENCE:principals<br />
<br />
[principals]<br />
princ1 = GeneralString:${ENV::CLIENT}</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3094Pkinit configuration2010-01-07T18:51:05Z<p>SamHartman: more udpates</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certificate authority certificate ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see<br />
[[#Extensions file]]. Paste that section of the article into a filed called <tt>pkinit_extensions</tt>. That file uses environment variables to set the<br />
client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc-cert -cacreateserial<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.<br />
<br />
<br />
=== Generating client certificates ===<br />
<br />
For use with anonymous Kerberos, no additional certificates are needed. For other uses of Pkinit, generate a certificate for each client. Typically on the client machine, the private key is generated:<br />
<pre><br />
openssl genrsa -out clientkey.pem 2048<br />
</pre><br />
The certificate request is also typically generated on the client machine:<br />
<pre><br />
openssl req -new -key clientkey.pem -out client.req<br />
</pre><br />
The <tt>client.req</tt> file needs to be copied to the machine with the certificate authority key. Then, sign the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=alice; export CLIENT<br />
openssl x509 -CAkey cakey.pem -req -in client.req -extensions client-cert -extfile pkinit_extensions <br />
</pre><br />
That will sign a certificate for <tt>alice@EXAMPLE.COM</tt>. The resulting <tt>client.pem</tt> needs to bo copied back to the client.<br />
<br />
== Configuring a KDC ==<br />
Insert the following entries into the <i>kdcdefaults</i> or a <i>realms</i> section of the <tt>kdc.conf</tt> or <tt>krb5.conf</tt> used by the KDC:<br />
<pre><br />
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem<br />
pkinit_anchors = /var/lib/krb5kdc/ca.pem<br />
</pre><br />
Of course, adjust the directory to where the files are stored on your system.<br />
Then, for each client principal that uses pkinit, set the <i>requires_preauth</i> attribute from within <b>kadmin</b>:<br />
<pre><br />
modprinc +requires_preauth alice@EXAMPLE.COM<br />
</pre><br />
<br />
== Configuring a client ==<br />
Add the following to the appropriate realm section of <tt>krb5.conf</tt><br />
<pre><br />
[realms]<br />
EXAMPLE.COM = {<br />
pkinit_anchors = /etcFILE:/krb5/ca.pem<br />
<br />
pkinit_identity = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem<br />
}<br />
</pre><br />
Of course, <tt>clientkey.pem</tt> needs to be protected .<br />
After this point, using <b>kinit</b> as the appropriate client principal should not require a password.<br />
== Advanced Configuration ==<br />
=== Including pkinit options in a certificate request ===<br />
Note that in the above example, the client name was not actually set<br />
in the certificate request but was<br />
set when the certificate was<br />
generated. In a production<br />
situation, it would be desirable<br />
to include the client name in a<br />
certificate request. There is an<br />
option to do this: the<br />
<b>-extenios</b> option to the<br />
<b>openssl req</b> command is<br />
intended for this purpose.<br />
Unfortunately, the <b>openssl<br />
req</b> command does not have a<br />
<b>-extfile</b> option. It seems<br />
that a special file for input to<br />
the <b>-config</b> option could be<br />
constructed to accomplish this. <br />
<br />
In theory, if the options were included in the certificate request,<br />
then a traditional certificate authority could be used to issue the<br />
certificate. Common practice is not to copy the requested extensions<br />
into the issued certificate, so special configuration would probably<br />
be required on the part of the certificate authority.<br />
<br />
=== Client identity on the command line ===<br />
The <b>-X X509_USER_IDENTITY</b> option to <b>kinit</b> allows users<br />
to specify what Pkinit idenity and key should be used. It provides an<br />
alternative to specifying this information in <tt>krb5.conf</tt>.<br />
<br />
=== Smart card configuration ===<br />
The Kerberos administration manual describes how to configure Pkinit<br />
to use PKCS11 smart cards and how to configure the selection of the<br />
correct identity.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Pkinit_configuration&diff=3091Pkinit configuration2010-01-06T22:12:23Z<p>SamHartman: some initial thoughts</p>
<hr />
<div>'''Pkinit''' provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:<br />
# Using smart cards for Kerberos authentication<br />
# Authentication based on soft tokens (or certificates stored on a computer) instead of passwords<br />
# In conjunction with [[anonymous kerberos]] and [[Projects/FAST | FAST]] protecting password exchanges to remove the possibility of [[dictionary attacks]]<br />
<br />
This article describes minimal Pkinit configuration for a KDC and clients. It assumes you already have a Kerberos realm functioning and that you have the <tt>openssl</tt> command available.<br />
<br />
The following steps are involved:<br />
# Setting up a certificate authority<br />
# Generating a KDC certificate<br />
# Generating client certificates<br />
# Configuring the KDC and clients<br />
# Testing<br />
<br />
== Background ==<br />
<br />
Pkinit requires a public key infrastructure. The simplest use of<br />
Pkinit ([[anonymous kerberos]] requires a certificate authority (CA)<br />
certificate and a KDC certificate. The certificate authority<br />
certificate is known by all clients; any certificates signed by this<br />
certificate are trusted by the clients. The KDC certificate is signed<br />
by the certificate authority certificate (and thus trusted by the<br />
clients) and identifies the KDC.<br />
<br />
<br />
If Pkinit is used with smart cards or for other forms of user authentication, then each user will need a certificate as well.<br />
<br />
This document discusses how to set up Pkinit for the EXAMPLE.COM realm by hand. This sort of by-hand setup may be appropriate for anonymous usage. However if a realm is going to provide certificates to each client then some sort of automated certificate authority will be required to manage certificates. Configuring an automated certificate authority will depend on what certificate authority is chosen.<br />
<br />
== Generating the certifate authority certifitae ==<br />
<br />
In this document we will use Open SSL to generate a simple self-signed certificate to use for the certificate authority.<br />
<br />
<br />
First, generate a private key:<br />
<pre> openssl genrsa -out cakey.pem 2048 </pre><br />
This will generate a 2048-bit RSA key and write it to afile <ttcakey.pem</tt> In a production environment, this private key should be carefully protected.<br />
Now, generate the CA certificate:<br />
<pre><br />
openssl req -key cakey.pem -new -x509 -out cacert.pem<br />
</pre><br />
This command will ask for the name of the CA and output a CA certificate into <tt>cacert.pem</tt> using the previously generated key.<br />
<br />
== Generating Kerberos certificates ==<br />
<br />
Kerberos certificates take advantage of two uncommon features of<br />
certificates. First, an extended key usage is used to indicate that<br />
the certificate should be used with Pkinit. An extended key usage is<br />
an object identifier placed in a certificate to indicate what the<br />
public key should be used for. Secondly, an otherName form of a<br />
subjectAlternativeName is used to describe the Kerberos principal<br />
associated with the certificate. An otherName is a way of including<br />
types of names in certificates that were not part of the original<br />
X.509 architecture. Unfortunately, including these elements in a<br />
certificate requires the use of an Open SSL extensions file. This<br />
file provides configuration for the certificate generation process. However the mechanisms for providing user data such as the name of the realm and the client principal to the otherName component are primitive.<br />
<br />
This article includes a sample Open SSL extensions file; see [[#Extensions file]]. That file uses environment variables to set the client and realm name.<br />
<br />
=== Generating KDC certificate ===<br />
<br />
First, generate the KDC key:<br />
<pre><br />
openssl genrsa -out kdckey.pem 2048 <br />
</pre><br />
Then, generate a certificate request<br />
<pre><br />
openssl req -new -out kdc.req -key kdckey.pem<br />
</pre><br />
Enter in the KDC name information.<br />
To generate the certificate:<br />
<pre><br />
REALM=EXAMPLE.COM; export REALM<br />
CLIENT=krbtgt; export CLIENT<br />
openssl x509 -req -in kdc.req -CAkey cakey.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc-cert<br />
</pre><br />
This will generate <tt>kdc.pem</tt> a certificate for the KDC. The<br />
first two lines set environment variables used by the extensions<br />
file. The <i>REALM</i> variable should be set to the name of your<br />
realm.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Anonymous_pkinit&diff=3090Projects/Anonymous pkinit2010-01-04T20:40:19Z<p>SamHartman: updates based on what was done</p>
<hr />
<div>{{project-review|01/11/2010}}<br />
<br />
The ''Anonymous Pkinit'' project is an implementation of anonymous pkinit from {{idref|draft-ietf-krb-wg-anon-10}}. This project allows users to obtain Kerberos tickets even if they have no principal registered in a realm. Use cases include hiding identity of a user for privacy, using [[Projects/FAST|FAST]] without registering a host, or automated registration of hosts.<br />
<br />
==Functional Requirements==<br />
<br />
anonymous tickets are tickets with a special well-known realm and principal name for the client principal. This principal will never appear in the service principal.<br />
The primary use case that motivates this project now is support for using anonymous tickets in host registration. That means that kadmin needs to support anonymous tickets and that kadmind needs to be able to ACL operations to anonymous principals.<br />
<br />
The anonymous draft makes it optional whether KDCs are required to<br />
have certificates when anonymous pkinit is used. However if KDCs do<br />
not have certificates, authentication of KDCs becomes complicated.<br />
FAST permits an anonymous ticket corresponding to an unauthenticated<br />
KDC to be used in some circumstances. However authentication state<br />
needs to be maintained because some fast factors should not be used<br />
with an unauthenticated KDC. Most other uses of Kerberos are not<br />
appropriate with an anonymous KDC. So, implementing unauthenticated<br />
KDCs introduces significant code and policy complexity. It will not<br />
be included in this project but may be added in the future. Instead, for this project, we will implement support for anonymous clients using the traditional pkinit certificate verification rules.<br />
<br />
The following is required:<br />
* Administrative configuration to permit a realm to issue anonymous tickets<br />
* API for requesting anonymous tickets<br />
* Command line switches for kadmin and kinit <br />
* GSS-API changes to support anonymous name type<br />
<br />
== Confirming Client and KDC Contribution ==<br />
<br />
The anonymous draft requires that the client confirm that both the<br />
client and KDC contributed to the TGS session key. In draft 10 this<br />
is accomplished by including a KDC contribution key and confirming<br />
that the TGS session key is the combination of the KDC contribution<br />
key and the reply key. This mechanism has been implemented.<br />
<br />
<br />
== KDC Changes ==<br />
<br />
=== Authorization data minimization ===<br />
<br />
A new flag on authdata plugins is added to indicate that the plugin<br />
supports anonymous processing. This flag is only set on the plugin<br />
that copies TGT authorization data and the one that copies request<br />
authorization data. Other plugins are skipped in anonymous mode.<br />
<br />
=== Session keys ===<br />
<br />
The KDC chooses the session key before pre-authentication plugins are<br />
given a chance to run. A pre-authentication plugin can change the<br />
session key although if the session key has already been used this may<br />
cause trouble. The only case where a pre-authentication plugin is<br />
likely to use the session key is when generating authorization data to<br />
be included in an issued ticket. If a PAC or AD-KDC-ISSUED element is<br />
generated then it is likely that the session key will be used.<br />
However anonymous processing trims out authorization data so this is<br />
not an issue for anonymous. Also, the preauth framework on the KDC<br />
side runs plugins that may replace the reply key before other plugins<br />
so pkinit will always be the first preauth successful plugin when it<br />
succeeds.<br />
<br />
The pkinit plugin generates a PA_PKINIT_KX padata item so that the client can confirm both parties contributed to the session key.<br />
<br />
=== Enabling anonymous ===<br />
<br />
If the <tt>WELLKNOWN/ANONYMOUS@REALM</tt> principal exists then anonymous authentication is supported. No special considerations are made to prohibit changing the password of this principal. As a result, it may be possible for an attacker to change the password of this principal and perform anonymous authentication without actually using pkinit.<br />
<br />
== Pkinit Changes ==<br />
<br />
* Detect when anonymous is being used in the client and do not require key or sign the request<br />
* KDC side: if anonymous tickets are requested don't require signed data to be signed<br />
<br />
== Library Changes ==<br />
<br />
* Extend transited realm checking to deal with anonymous principals<br />
* Add GIC support for obtaining anonymous principals if the anonymous principal is the client<br />
<br />
A new API, krb5_get_init_creds_opt_set_anonymous is added to set the<br />
anonymous option. If this is turned on, then principals of the form<br />
<tt>@<i>REALM</i></tt> are mapped to the wellknown principal in a<br />
realm. In addition, <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt> is<br />
always treated as an anonymous authentication.<br />
<br />
The canonicalization logic is expanded to permit any realm to be mapped to the anonymous realm when fully anonymous authentication is in use.<br />
<br />
<br />
== GSS-API Changes ==<br />
<br />
* Display the anonymous principal name as GSS_NT_ANONYMOUS<br />
* In this version GSS-API will be able to use existing anonymous credentials but will not be able to obtain credentials on its own. The main problem with obtaining credentials is selection of a realm to contact.<br />
<br />
== Kadmin Changes ==<br />
<br />
* Add command line flag for requesting anonymous credentials<br />
* ACL handling requires no changes</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Anonymous_kerberos&diff=3089Anonymous kerberos2010-01-04T20:15:00Z<p>SamHartman: add host registration</p>
<hr />
<div>'''Anonymous kerberos''' provides a mechanism for<br />
[[Principal|principals]] to authenticate to a remote service without disclosing their identity.There are two primary use cases:<br />
<br />
# Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication<br />
# Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.<br />
<br />
There are two modes of anonymous Kerberos to meet these objectives: completely anonymous and realm-exposed.<br />
<br />
==Completely anonymous ==<br />
<br />
In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm. Diffie-Hellman key exchange is used to establish a shared secret.. To use completely anonymous Kerberos:<br />
<br />
# Configure the KDC to support pkinit, setting at least <tt>pkinit_identity</tt> on the KDC.<br />
# Set <tt>pkinit_anchors</tt> so that the client can verify the KDC certificate<br />
# Create the <tt>WELLKNOWN/ANONYMOUS</tt> principal in the realm to signal that fully anonymous Kerberos is enabled.<br />
<br />
On the client use <tt> kinit -n @<i>REALM</i></tt> or <tt> kadmin -n<br />
@<i>REALM</i></tt> to request anonymous tickets. In klist and in<br />
service ACLs the resulting authentication will use the<br />
<tt>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</tt> [[well known principal]].<br />
<br />
== Realm Exposed Anonymous ==<br />
<br />
Alternatively, clients can authenticate normally to the KDC but request that the KDC return a credential that only exposes the client's realm. The MIT Kerberos client is believed to support this mode as of Kerberos 1.8, although the KDC currently does not support this mode.<br />
<br />
On the client, use <tt>kinit -n <i>principal</i></tt> to authenticate. A password or other credential will be required just as if the <tt>-n</tt> flag is not included. However, the resulting principal will be <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt>.<br />
<br />
== Host registration ==<br />
<br />
One common use case for anonymous Kerberos is to permit any user to register a host in a realm even if they don't have a Kerberos identity. That way, these automated installation systems can register a host for Kerberos so that Kerberos services can be established. To permit this use case, configure fully anonymous Kerberos as described above. Then, add the following entry to <tt>kadm5.acl</tt><br />
<pre><br />
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS a host/*@YOUR_REALM Status ==<br />
</pre><br />
<br />
== Implementation status ==<br />
<br />
See [[Projects/Anonymous pkinit]] for implementation status.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Anonymous_kerberos&diff=3088Anonymous kerberos2010-01-04T20:09:42Z<p>SamHartman: fix formatting</p>
<hr />
<div>'''Anonymous kerberos''' provides a mechanism for<br />
[[Principal|principals]] to authenticate to a remote service without disclosing their identity.There are two primary use cases:<br />
<br />
# Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication<br />
# Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.<br />
<br />
There are two modes of anonymous Kerberos to meet these objectives: completely anonymous and realm-exposed.<br />
<br />
==Completely anonymous ==<br />
<br />
In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm. Diffie-Hellman key exchange is used to establish a shared secret.. To use completely anonymous Kerberos:<br />
<br />
# Configure the KDC to support pkinit, setting at least <tt>pkinit_identity</tt> on the KDC.<br />
# Set <tt>pkinit_anchors</tt> so that the client can verify the KDC certificate<br />
# Create the <tt>WELLKNOWN/ANONYMOUS</tt> principal in the realm to signal that fully anonymous Kerberos is enabled.<br />
<br />
On the client use <tt> kinit -n @<i>REALM</i></tt> or <tt> kadmin -n<br />
@<i>REALM</i></tt> to request anonymous tickets. In klist and in<br />
service ACLs the resulting authentication will use the<br />
<tt>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</tt> [[well known principal]].<br />
<br />
== Realm Exposed Anonymous ==<br />
<br />
Alternatively, clients can authenticate normally to the KDC but request that the KDC return a credential that only exposes the client's realm. The MIT Kerberos client is believed to support this mode as of Kerberos 1.8, although the KDC currently does not support this mode.<br />
<br />
On the client, use <tt>kinit -n <i>principal</i></tt> to authenticate. A password or other credential will be required just as if the <tt>-n</tt> flag is not included. However, the resulting principal will be <tt>WELLKNOWN/ANONYMOUS@<i>REALM</i></tt>.<br />
<br />
== Implementation Status ==<br />
<br />
See [[Projects/Anonymous pkinit]] for implementation status.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Anonymous_kerberos&diff=3084Anonymous kerberos2009-12-28T17:07:18Z<p>SamHartman: document anonymous</p>
<hr />
<div>'''Anonymous kerberos''' provides a mechanism for<br />
[[Principal|principals]] to authenticate to a remote service without disclosing their identity.There are two primary use cases:<br />
<br />
# Principals with no Kerberos identity at all authenticating to create an identity or to protect some communication<br />
# Principals authenticating to some external service, disclosing that they are affiliated with a particular realm but not disclosing their full identity.<br />
<br />
There are two modes of anonymous Kerberos to meet these objectives: completely anonymous and realm-exposed.<br />
<br />
==Completely anonymous ==<br />
<br />
In completely anonymous Kerberos, a principal can authenticate to a realm with no Kerberos identity in that realm. Diffie-Hellman key exchange is used to establish a shared secret.. To use completely anonymous Kerberos:<br />
<br />
# Configure the KDC to support pkinit, setting at least <t>pkinit_identity</t> on the KDC.<br />
# Set <t>pkinit_anchors</t> so that the client can verify the KDC certificate<br />
# Create the <t>WELLKNOWN/ANONYMOUS</t> principal in the realm to signal that fully anonymous Kerberos is enabled.<br />
<br />
On the client use <t> kinit -n @<i>REALM</i></t> or <t> kadmin -n<br />
@<i>REALM</i></t> to request anonymous tickets. In klist and in<br />
service ACLs the resulting authentication will use the<br />
<t>WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS</t> [[well known principal]].<br />
<br />
== Realm Exposed Anonymous ==<br />
<br />
Alternatively, clients can authenticate normally to the KDC but request that the KDC return a credential that only exposes the client's realm. The MIT Kerberos client is believed to support this mode as of Kerberos 1.8, although the KDC currently does not support this mode.<br />
<br />
On the client, use <t>kinit -n <i>principal</i></t> to authenticate. A password or other credential will be required just as if the <t>-n</t> flag is not included. However, the resulting principal will be <t>WELLKNOWN/ANONYMOUS@<i>REALM</i></t>.<br />
<br />
== Implementation Status ==<br />
xi<br />
See [[Projects/Anonymous pkinit]] for implementation status.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Anonymous_pkinit&diff=3081Projects/Anonymous pkinit2009-12-21T19:51:47Z<p>SamHartman: update progress</p>
<hr />
<div>{{project-early}}<br />
<br />
The ''Anonymous Pkinit'' project is an implementation of anonymous pkinit from {{idref|draft-ietf-krb-wg-anon-10}}. This project allows users to obtain Kerberos tickets even if they have no principal registered in a realm. Use cases include hiding identity of a user for privacy, using [[Projects/FAST|FAST]] without registering a host, or automated registration of hosts.<br />
<br />
==Functional Requirements==<br />
<br />
anonymous tickets are tickets with a special well-known realm and principal name for the client principal. This principal will never appear in the service principal.<br />
The primary use case that motivates this project now is support for using anonymous tickets in host registration. That means that kadmin needs to support anonymous tickets and that kadmind needs to be able to ACL operations to anonymous principals.<br />
<br />
The anonymous draft makes it optional whether KDCs are required to<br />
have certificates when anonymous pkinit is used. However if KDCs do<br />
not have certificates, authentication of KDCs becomes complicated.<br />
FAST permits an anonymous ticket corresponding to an unauthenticated<br />
KDC to be used in some circumstances. However authentication state<br />
needs to be maintained because some fast factors should not be used<br />
with an unauthenticated KDC. Most other uses of Kerberos are not<br />
appropriate with an anonymous KDC. So, implementing unauthenticated<br />
KDCs introduces significant code and policy complexity. It will not<br />
be included in this project but may be added in the future. Instead, for this project, we will implement support for anonymous clients using the traditional pkinit certificate verification rules.<br />
<br />
The following is required:<br />
* Administrative configuration to permit a realm to issue anonymous tickets<br />
* API for requesting anonymous tickets<br />
* Command line switches for kadmin and kinit <br />
* GSS-API changes to support anonymous name type<br />
<br />
== Confirming Client and KDC Contribution ==<br />
<br />
The anonymous draft requires that the client confirm that both the<br />
client and KDC contributed to the TGS session key. In draft 10 this<br />
is accomplished by including a KDC contribution key and confirming<br />
that the TGS session key is the combination of the KDC contribution<br />
key and the reply key. Discussion in the working group may simplify<br />
this procedure somewhat.<br />
<br />
Regardless, the KDC does not currently have a mechanism for a pre-authentication plugin to influence the session key that is chosen.<br />
There are two approaches:<br />
* Add support for this behavior to the main body of the KDC <br />
* Add support for a more general mechanism for plugins to frob the session key <br />
<br />
While the first approach does involve the main body of the KDC learning a bit about anonymous pkinit, it is probably desirable because it will be less complex and because it will avoid other plugins affecting critical security parameters.<br />
<br />
== KDC Changes ==<br />
<br />
* Implement authorization data minimization for anonymous requests<br />
* Add support for anonymous principal <br />
* Add config option to enable anonymous for a realm<br />
* Handle session key derivation<br />
<br />
== Pkinit Changes ==<br />
<br />
* Detect when anonymous is being used in the client and do not require key or sign the request<br />
* Verify session key form<br />
* KDC side: if anonymous tickets are requested don't require signed data to be signed<br />
* Give KDC information it needs to construct session key<br />
== Library Changes ==<br />
<br />
* Extend transited realm checking to deal with anonymous principals<br />
* Add GIC support for obtaining anonymous principals if the anonymous principal is the client<br />
<br />
<br />
== GSS-API Changes ==<br />
<br />
* Display the anonymous principal name as GSS_NT_ANONYMOUS<br />
* In this version GSS-API will be able to use existing anonymous credentials but will not be able to obtain credentials on its own. The main problem with obtaining credentials is selection of a realm to contact.<br />
<br />
== Kadmin Changes ==<br />
<br />
* Add command line flag for requesting anonymous credentials<br />
* ACL handling requires no changes<br />
<br />
== Still Todo ==<br />
<br />
* Handle session key derivation<br />
* Handle transited policy checking<br />
* Kadmin deals poorly with the realm changing from what is requested<br />
* Kadmin command line flag</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Fast_negotiation&diff=3024Projects/Fast negotiation2009-11-30T21:08:14Z<p>SamHartman: add api notes, send for review</p>
<hr />
<div>{{project-review|2009-12-07}}<br />
<br />
The ''FAST negotiation'' project builds on [[Projects/FAST]]. That project defines an interface that a client can use to make an armor ticket available to the library. Currently, that interface mandates the use of FAST; if a client supplies an armor ticket then the library requires the KDC to support FAST.<br />
<br />
In many situations, it is desirable to use FAST when it is available but to fall back to not using FAST if FAST is unavailable. This project proposes to implement a secure mechanism for accomplishing that goal.<br />
<br />
Larry Zhu proposed<br />
[https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007593.html] a<br />
mechanism for negotiating FAST. The client includes a padata in its<br />
request indicating it supports the negotiation mechanism. If the KDC<br />
receives this padata, it returns a modified as-rep including a<br />
checksum of the client's as-req along with an indication of whether<br />
FAST is supported.<br />
<br />
== Functional Requirements ==<br />
<br />
* A mechanism to request an armor ticket and during the process of requesting that armor ticket securely determine whether the KDC supports FAST.<br />
* A mechanism to store the result of FAST negotiation <br />
* Enhancements of the FAST API to require/use FAST only when it is supported<br />
<br />
In addition, the following would be strongly desirable:<br />
<br />
* A mechanism to use Anonymous pkinit to obtain an armor ticket for a given set of realms if no armor ticket is provided<br />
<br />
== Encrypted Padata ==<br />
<br />
[[Projects/Aliases]] added support for the encrypted padata field in<br />
[[MIT Kerberos]]. This field is currently a Microsoft extension<br />
introduced in Windows 2000. The KDC reply may contain a second set of<br />
padata encrypted in the reply key of the request. This field would<br />
not be useful for solving the same problems that FAST solves; among<br />
other reasons, the client must know the reply key before it can decrypt. However, this facility is sufficient for securely negotiating FAST.<br />
<br />
Larry proposes to standardize this field and to standardize a<br />
mechanism for FAST negotiation. At the interop event, Larry's<br />
proposal was prototyped for MIT Kerberos. This included the necessary<br />
work to send the padata and to verify results.<br />
<br />
== Storing Negotiation results ==<br />
<br />
Currently, armor tickets are stored in a credentials cache. In order to effectively use the negotiation mechanism, the client needs to be able to look at a given armor ticket and determine whether fast is available. {{bug|6206}} provides a way to store configuration information in a ticket cache.<br />
This API shall be used to store information on whether FAST is available.<br />
<br />
The current approach is to store state based on what is returned from the AS request. The pre-authentication framework does permit a cross-realm armor ticket to be used; for example, if a host key is used to obtain an armor ticket and the client and host are registered in different realms, then a cross-realm armor ticket will be used. The assumption of this project is that whether FAST is used will be determined based on what the KDC against which the AS request to get the armor ticket supports. This can be expanded in the future to store more fine-grained negotiation state if needed. Options would include:<br />
* Constructing configuration keys that include the realm name and using the negotiation procedure recursively <br />
* Using the negotiation procedure recursively and storing per-realm state with some new mechanism--possibly associated with the TGT for that realm<br />
<br />
Another complexity is handling of renewed and validated credentials. Currently, the APIs for handling renewal and credential validation take a ccache, but do not write credentials out to the ccache. Since there is no API documentation it's not clear what behavior changes are acceptable. For a program today that runs the renewal and then replaces the credentials in the cache, writing out the credentials would be a no-op. For a program that expects credentials unrelated to the renewal to remain in the cache and be undisturbed, that behavior change would be significant. Another approach might be to preserve set_config state across calls to krb5_cc_initialize. That should not affect existing code, although it would make it difficult to unset configuration state in a ccache.<br />
<br />
<br />
== Unexpected preauth handling ==<br />
<br />
Prior to {{bug|6480}}, included in Krb5 1.7, if the KDC received unknown padata it would return KDC_ERR_PREAUTH_FAILED rather than KDC_ERR_PREAUTH_REQUIRED. Also, prior to 1.7, the KDC did not include the set of pre-authentication types to try with the PREAUTH_FAILED error.<br />
The FAST negotiation code needs to handle this situation. The proposal is that if PREAUTH_FAILED is received as the first error and no pre-authentication types were forced, then try again without including the request for negotiation. If the KDC ends up supporting negotiation, the ticket flag will be set and we will correctly fail. When standardizing this we will need to require that KDCs implementing this negotiation ignore unknown padata and return PREAUTH_REQUIRED not PREAUTH_FAILED.<br />
<br />
<br />
== API Changes ==<br />
===FAST API===<br />
The current FAST API requires that if a client specifies a FAST armor<br />
ticket, then FAST will be required. However comments in the header file make it clear that this is not a guaranteed interface. the API contract is that the client is providing an armor ticket for the library. The library may either interpret this as "must use FAST," as it does today or "should use fast."<br />
<br />
This project changes the behavior from "must use fast," to "should use fast." and provides an additional API to force FAST be required.<br />
<br />
The following APIs are introduced:<br />
<pre><br />
<br />
/**Set a ccache where resulting credentials will be stored. If set, then the<br />
* krb5_get_init_creds family of APIs will write out credentials to the given<br />
* ccache. Setting an output ccache is desirable both because it simplifies<br />
* calling code and because it permits the krb5_get_init_creds APIs to write<br />
* out configuration information about the realm to the ccache.<br />
*/<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_get_init_creds_opt_set_out_ccache<br />
(krb5_context context, krb5_get_init_creds_opt *opt, krb5_ccache ccache);<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_get_init_creds_opt_set_fast_flags<br />
(krb5_context context, krb5_get_init_creds_opt *opt, krb5_flags flags);<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_get_init_creds_opt_get_fast_flags<br />
(krb5_context context, krb5_get_init_creds_opt *opt, krb5_flags *out_flags);<br />
<br />
/* Fast flags*/<br />
#define KRB5_FAST_REQUIRED 1l<<0 /*!< Require KDC to support FAST*/<br />
</pre><br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
(hash mark followed by four tilde characters) on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Fast_negotiation&diff=2979Projects/Fast negotiation2009-11-20T17:17:48Z<p>SamHartman: renewal and validation</p>
<hr />
<div>{{project-early}}<br />
<br />
The ''FAST negotiation'' project builds on [[Projects/FAST]]. That project defines an interface that a client can use to make an armor ticket available to the library. Currently, that interface mandates the use of FAST; if a client supplies an armor ticket then the library requires the KDC to support FAST.<br />
<br />
In many situations, it is desirable to use FAST when it is available but to fall back to not using FAST if FAST is unavailable. This project proposes to implement a secure mechanism for accomplishing that goal.<br />
<br />
Larry Zhu proposed<br />
[https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007593.html] a<br />
mechanism for negotiating FAST. The client includes a padata in its<br />
request indicating it supports the negotiation mechanism. If the KDC<br />
receives this padata, it returns a modified as-rep including a<br />
checksum of the client's as-req along with an indication of whether<br />
FAST is supported.<br />
<br />
== Functional Requirements ==<br />
<br />
* A mechanism to request an armor ticket and during the process of requesting that armor ticket securely determine whether the KDC supports FAST.<br />
* A mechanism to store the result of FAST negotiation <br />
* Enhancements of the FAST API to require/use FAST only when it is supported<br />
<br />
In addition, the following would be strongly desirable:<br />
<br />
* A mechanism to use Anonymous pkinit to obtain an armor ticket for a given set of realms if no armor ticket is provided<br />
<br />
== Encrypted Padata ==<br />
<br />
[[Projects/Aliases]] added support for the encrypted padata field in<br />
[[MIT Kerberos]]. This field is currently a Microsoft extension<br />
introduced in Windows 2000. The KDC reply may contain a second set of<br />
padata encrypted in the reply key of the request. This field would<br />
not be useful for solving the same problems that FAST solves; among<br />
other reasons, the client must know the reply key before it can decrypt. However, this facility is sufficient for securely negotiating FAST.<br />
<br />
Larry proposes to standardize this field and to standardize a<br />
mechanism for FAST negotiation. At the interop event, Larry's<br />
proposal was prototyped for MIT Kerberos. This included the necessary<br />
work to send the padata and to verify results.<br />
<br />
== Storing Negotiation results ==<br />
<br />
Currently, armor tickets are stored in a credentials cache. In order to effectively use the negotiation mechanism, the client needs to be able to look at a given armor ticket and determine whether fast is available. {{bug|6206}} provides a way to store configuration information in a ticket cache.<br />
This API shall be used to store information on whether FAST is available.<br />
<br />
The current approach is to store state based on what is returned from the AS request. The pre-authentication framework does permit a cross-realm armor ticket to be used; for example, if a host key is used to obtain an armor ticket and the client and host are registered in different realms, then a cross-realm armor ticket will be used. The assumption of this project is that whether FAST is used will be determined based on what the KDC against which the AS request to get the armor ticket supports. This can be expanded in the future to store more fine-grained negotiation state if needed. Options would include:<br />
* Constructing configuration keys that include the realm name and using the negotiation procedure recursively <br />
* Using the negotiation procedure recursively and storing per-realm state with some new mechanism--possibly associated with the TGT for that realm<br />
<br />
Another complexity is handling of renewed and validated credentials. Currently, the APIs for handling renewal and credential validation take a ccache, but do not write credentials out to the ccache. Since there is no API documentation it's not clear what behavior changes are acceptable. For a program today that runs the renewal and then replaces the credentials in the cache, writing out the credentials would be a no-op. For a program that expects credentials unrelated to the renewal to remain in the cache and be undisturbed, that behavior change would be significant. Another approach might be to preserve set_config state across calls to krb5_cc_initialize. That should not affect existing code, although it would make it difficult to unset configuration state in a ccache.<br />
<br />
<br />
== Unexpected preauth handling ==<br />
<br />
Prior to {{bug|6480}}, included in Krb5 1.7, if the KDC received unknown padata it would return KDC_ERR_PREAUTH_FAILED rather than KDC_ERR_PREAUTH_REQUIRED. Also, prior to 1.7, the KDC did not include the set of pre-authentication types to try with the PREAUTH_FAILED error.<br />
The FAST negotiation code needs to handle this situation. The proposal is that if PREAUTH_FAILED is received as the first error and no pre-authentication types were forced, then try again without including the request for negotiation. If the KDC ends up supporting negotiation, the ticket flag will be set and we will correctly fail. When standardizing this we will need to require that KDCs implementing this negotiation ignore unknown padata and return PREAUTH_REQUIRED not PREAUTH_FAILED.<br />
<br />
<br />
== API Changes ==<br />
===FAST API===<br />
The current FAST API requires that if a client specifies a FAST armor<br />
ticket, then FAST will be required. However comments in the header file make it clear that this is not a guaranteed interface. the API contract is that the client is providing an armor ticket for the library. The library may either interpret this as "must use FAST," as it does today or "should use fast."<br />
<br />
This project changes the behavior from "must use fast," to "should use fast." and provides an additional API to force FAST be required.<br />
<br />
<br />
=== Ccache to <tt>krb5_get_init_creds</tt> ===<br />
<br />
In order to store negotiation state in the ccache, <tt>krb5_get_init_creds</tt> needs to actually write the ticket to the ccache. To do that, a new API will be added to use the get_init_creds options structure to store the target ccache.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Fast_negotiation&diff=2977Projects/Fast negotiation2009-11-17T21:26:22Z<p>SamHartman: store ccache, preauth_required, cross-realm armor</p>
<hr />
<div>{{project-early}}<br />
<br />
The ''FAST negotiation'' project builds on [[Projects/FAST]]. That project defines an interface that a client can use to make an armor ticket available to the library. Currently, that interface mandates the use of FAST; if a client supplies an armor ticket then the library requires the KDC to support FAST.<br />
<br />
In many situations, it is desirable to use FAST when it is available but to fall back to not using FAST if FAST is unavailable. This project proposes to implement a secure mechanism for accomplishing that goal.<br />
<br />
Larry Zhu proposed<br />
[https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007593.html] a<br />
mechanism for negotiating FAST. The client includes a padata in its<br />
request indicating it supports the negotiation mechanism. If the KDC<br />
receives this padata, it returns a modified as-rep including a<br />
checksum of the client's as-req along with an indication of whether<br />
FAST is supported.<br />
<br />
== Functional Requirements ==<br />
<br />
* A mechanism to request an armor ticket and during the process of requesting that armor ticket securely determine whether the KDC supports FAST.<br />
* A mechanism to store the result of FAST negotiation <br />
* Enhancements of the FAST API to require/use FAST only when it is supported<br />
<br />
In addition, the following would be strongly desirable:<br />
<br />
* A mechanism to use Anonymous pkinit to obtain an armor ticket for a given set of realms if no armor ticket is provided<br />
<br />
== Encrypted Padata ==<br />
<br />
[[Projects/Aliases]] added support for the encrypted padata field in<br />
[[MIT Kerberos]]. This field is currently a Microsoft extension<br />
introduced in Windows 2000. The KDC reply may contain a second set of<br />
padata encrypted in the reply key of the request. This field would<br />
not be useful for solving the same problems that FAST solves; among<br />
other reasons, the client must know the reply key before it can decrypt. However, this facility is sufficient for securely negotiating FAST.<br />
<br />
Larry proposes to standardize this field and to standardize a<br />
mechanism for FAST negotiation. At the interop event, Larry's<br />
proposal was prototyped for MIT Kerberos. This included the necessary<br />
work to send the padata and to verify results.<br />
<br />
== Storing Negotiation results ==<br />
<br />
Currently, armor tickets are stored in a credentials cache. In order to effectively use the negotiation mechanism, the client needs to be able to look at a given armor ticket and determine whether fast is available. {{bug|6206}} provides a way to store configuration information in a ticket cache.<br />
This API shall be used to store information on whether FAST is available.<br />
<br />
The current approach is to store state based on what is returned from the AS request. The pre-authentication framework does permit a cross-realm armor ticket to be used; for example, if a host key is used to obtain an armor ticket and the client and host are registered in different realms, then a cross-realm armor ticket will be used. The assumption of this project is that whether FAST is used will be determined based on what the KDC against which the AS request to get the armor ticket supports. This can be expanded in the future to store more fine-grained negotiation state if needed. Options would include:<br />
* Constructing configuration keys that include the realm name and using the negotiation procedure recursively <br />
* Using the negotiation procedure recursively and storing per-realm state with some new mechanism--possibly associated with the TGT for that realm<br />
<br />
== Unexpected preauth handling ==<br />
<br />
Prior to {{bug|6480}}, included in Krb5 1.7, if the KDC received unknown padata it would return KDC_ERR_PREAUTH_FAILED rather than KDC_ERR_PREAUTH_REQUIRED. Also, prior to 1.7, the KDC did not include the set of pre-authentication types to try with the PREAUTH_FAILED error.<br />
The FAST negotiation code needs to handle this situation. The proposal is that if PREAUTH_FAILED is received as the first error and no pre-authentication types were forced, then try again without including the request for negotiation. If the KDC ends up supporting negotiation, the ticket flag will be set and we will correctly fail. When standardizing this we will need to require that KDCs implementing this negotiation ignore unknown padata and return PREAUTH_REQUIRED not PREAUTH_FAILED.<br />
<br />
<br />
== API Changes ==<br />
===FAST API===<br />
The current FAST API requires that if a client specifies a FAST armor<br />
ticket, then FAST will be required. However comments in the header file make it clear that this is not a guaranteed interface. the API contract is that the client is providing an armor ticket for the library. The library may either interpret this as "must use FAST," as it does today or "should use fast."<br />
<br />
This project changes the behavior from "must use fast," to "should use fast." and provides an additional API to force FAST be required.<br />
<br />
<br />
=== Ccache to <tt>krb5_get_init_creds</tt> ===<br />
<br />
In order to store negotiation state in the ccache, <tt>krb5_get_init_creds</tt> needs to actually write the ticket to the ccache. To do that, a new API will be added to use the get_init_creds options structure to store the target ccache.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Template:Bug&diff=2902Template:Bug2009-11-04T20:49:59Z<p>SamHartman: New page: <includeonly><nowiki>[krbdev.mit.edu #</nowiki>[http://krbdev.mit.edu/rt/ticket/display.html?id={{{1}}} #{{{1}}}]<nowiki>]</nowiki></includeonly> <noinclude> == Documentation == Use this t...</p>
<hr />
<div><includeonly><nowiki>[krbdev.mit.edu #</nowiki>[http://krbdev.mit.edu/rt/ticket/display.html?id={{{1}}} #{{{1}}}]<nowiki>]</nowiki></includeonly><br />
<noinclude><br />
== Documentation ==<br />
Use this template to refer to a bug. For example: <nowiki>{{bug|1234}}</nowiki></div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Fast_negotiation&diff=2901Projects/Fast negotiation2009-11-04T20:42:11Z<p>SamHartman: New page: {{project-early}} The ''FAST negotiation'' project builds on Projects/FAST. That project defines an interface that a client can use to make an armor ticket available to the library. ...</p>
<hr />
<div>{{project-early}}<br />
<br />
The ''FAST negotiation'' project builds on [[Projects/FAST]]. That project defines an interface that a client can use to make an armor ticket available to the library. Currently, that interface mandates the use of FAST; if a client supplies an armor ticket then the library requires the KDC to support FAST.<br />
<br />
In many situations, it is desirable to use FAST when it is available but to fall back to not using FAST if FAST is unavailable. This project proposes to implement a secure mechanism for accomplishing that goal.<br />
<br />
Larry Zhu proposed<br />
[https://lists.anl.gov/pipermail/ietf-krb-wg/2009-April/007593.html] a<br />
mechanism for negotiating FAST. The client includes a padata in its<br />
request indicating it supports the negotiation mechanism. If the KDC<br />
receives this padata, it returns a modified as-rep including a<br />
checksum of the client's as-req along with an indication of whether<br />
FAST is supported.<br />
<br />
== Functional Requirements ==<br />
<br />
* A mechanism to request an armor ticket and during the process of requesting that armor ticket securely determine whether the KDC supports FAST.<br />
* A mechanism to store the result of FAST negotiation <br />
* Enhancements of the FAST API to require/use FAST only when it is supported<br />
<br />
In addition, the following would be strongly desirable:<br />
<br />
* A mechanism to use Anonymous pkinit to obtain an armor ticket for a given set of realms if no armor ticket is provided<br />
<br />
== Encrypted Padata ==<br />
<br />
[[Projects/Aliases]] added support for the encrypted padata field in<br />
[[MIT Kerberos]]. This field is currently a Microsoft extension<br />
introduced in Windows 2000. The KDC reply may contain a second set of<br />
padata encrypted in the reply key of the request. This field would<br />
not be useful for solving the same problems that FAST solves; among<br />
other reasons, the client must know the reply key before it can decrypt. However, this facility is sufficient for securely negotiating FAST.<br />
<br />
Larry proposes to standardize this field and to standardize a<br />
mechanism for FAST negotiation. At the interop event, Larry's<br />
proposal was prototyped for MIT Kerberos. This included the necessary<br />
work to send the padata and to verify results.<br />
<br />
== Storing Negotiation results ==<br />
<br />
Currently, armor tickets are stored in a credentials cache. In order to effectively use the negotiation mechanism, the client needs to be able to look at a given armor ticket and determine whether fast is available. {{bug|6206}} provides a way to store configuration information in a ticket cache.<br />
This API shall be used to store information on whether FAST is available.<br />
<br />
== API Changes ==<br />
<br />
The current FAST API requires that if a client specifies a FAST armor<br />
ticket, then FAST will be required. However comments in the header file make it clear that this is not a guaranteed interface. the API contract is that the client is providing an armor ticket for the library. The library may either interpret this as "must use FAST," as it does today or "should use fast."<br />
<br />
This project changes the behavior from "must use fast," to "should use fast." and provides an additional API to force FAST be required.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Anonymous_pkinit&diff=2887Projects/Anonymous pkinit2009-11-02T23:32:53Z<p>SamHartman: New page: {{project-early}} The ''Anonymous Pkinit'' project is an implementation of anonymous pkinit from {{idref|draft-ietf-krb-wg-anon-10}}. This project allows users to obtain Kerberos tickets...</p>
<hr />
<div>{{project-early}}<br />
<br />
The ''Anonymous Pkinit'' project is an implementation of anonymous pkinit from {{idref|draft-ietf-krb-wg-anon-10}}. This project allows users to obtain Kerberos tickets even if they have no principal registered in a realm. Use cases include hiding identity of a user for privacy, using [[Projects/FAST|FAST]] without registering a host, or automated registration of hosts.<br />
<br />
==Functional Requirements==<br />
<br />
anonymous tickets are tickets with a special well-known realm and principal name for the client principal. This principal will never appear in the service principal.<br />
The primary use case that motivates this project now is support for using anonymous tickets in host registration. That means that kadmin needs to support anonymous tickets and that kadmind needs to be able to ACL operations to anonymous principals.<br />
<br />
The anonymous draft makes it optional whether KDCs are required to<br />
have certificates when anonymous pkinit is used. However if KDCs do<br />
not have certificates, authentication of KDCs becomes complicated.<br />
FAST permits an anonymous ticket corresponding to an unauthenticated<br />
KDC to be used in some circumstances. However authentication state<br />
needs to be maintained because some fast factors should not be used<br />
with an unauthenticated KDC. Most other uses of Kerberos are not<br />
appropriate with an anonymous KDC. So, implementing unauthenticated<br />
KDCs introduces significant code and policy complexity. It will not<br />
be included in this project but may be added in the future. Instead, for this project, we will implement support for anonymous clients using the traditional pkinit certificate verification rules.<br />
<br />
The following is required:<br />
* Administrative configuration to permit a realm to issue anonymous tickets<br />
* API for requesting anonymous tickets<br />
* Command line switches for kadmin and kinit <br />
* GSS-API changes to support anonymous name type<br />
<br />
== Confirming Client and KDC Contribution ==<br />
<br />
The anonymous draft requires that the client confirm that both the<br />
client and KDC contributed to the TGS session key. In draft 10 this<br />
is accomplished by including a KDC contribution key and confirming<br />
that the TGS session key is the combination of the KDC contribution<br />
key and the reply key. Discussion in the working group may simplify<br />
this procedure somewhat.<br />
<br />
Regardless, the KDC does not currently have a mechanism for a pre-authentication plugin to influence the session key that is chosen.<br />
There are two approaches:<br />
* Add support for this behavior to the main body of the KDC <br />
* Add support for a more general mechanism for plugins to frob the session key <br />
<br />
While the first approach does involve the main body of the KDC learning a bit about anonymous pkinit, it is probably desirable because it will be less complex and because it will avoid other plugins affecting critical security parameters.<br />
<br />
== KDC Changes ==<br />
<br />
* Implement authorization data minimization for anonymous requests<br />
* Add support for anonymous principal <br />
* Add config option to enable anonymous for a realm<br />
* Handle session key derivation<br />
<br />
== Pkinit Changes ==<br />
<br />
* Detect when anonymous is being used in the client and do not require key or sign the request<br />
* Verify session key form<br />
* KDC side: if anonymous tickets are requested don't require signed data to be signed<br />
* Give KDC information it needs to construct session key<br />
== Library Changes ==<br />
<br />
* Extend transited realm checking to deal with anonymous principals<br />
* Add GIC support for obtaining anonymous principals<br />
* Add convenience API for obtaining anonymous principals<br />
<br />
== GSS-API Changes ==<br />
<br />
* Display the anonymous principal name as GSS_NT_ANONYMOUS<br />
* Add support for obtaining anonymous credentials and anonymous context establishment<br />
<br />
== Kadmin Changes ==<br />
<br />
* Add command line flag for requesting anonymous credentials<br />
* confirm ACL handling can work with anonymous</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Encryption_performance&diff=1810Projects/Encryption performance2009-08-05T19:27:12Z<p>SamHartman: /* Approvals */</p>
<hr />
<div>{{project-review|August 3, 2009}}<br />
<br />
==Desired Changes==<br />
<br />
This project follows after [[Projects/Crypto modularity]] and intends to improve encryption performance by allowing cached information to be added to keys. It also creates API concepts which can be later used for supporting cryptographic tokens.<br />
<br />
The current API uses an exposed structure, krb5_keyblock, to convey key information to the encryption functions. Because the keyblock type is not opaque, we cannot add fields to it without breaking the ABI. If encryption is performed repeatedly with the same key and usage, the derived key must be re-computed each time. If the encryption back end library associates a handle with the key, the handle must be re-initialized each time the key is used.<br />
<br />
Keyblocks are used within several other exposed krb5 structures, including credentials and keytab entries, which would make it difficult to revise the entire API to use a new type. However, in most cases where keyblocks are used within other API structures, the key contents alone are sufficient; such keys are generally either being readied for transmission over the network, or will be used for only a single encryption with a particular key usage. Keys used for repeated encryptions are stored within auth context structures--either krb5_auth_context or krb5_gss_ctx_id_rec--which are opaque and can be modified.<br />
<br />
==API Proposal==<br />
<br />
The keyblock structure retains its current meaning as the exposed data of a cryptographic key. For keys which may be used repeatedly or which may be an external reference, we define a new opaque type krb5_key:<br />
<br />
struct krb5_key_st;<br />
typedef struct krb5_key_st *krb5_key;<br />
<br />
The prefix krb5_k_ will distinguish functions operating on keys from similar functions operating on keyblocks. Opaque keys have the following initializers and accessors:<br />
<br />
krb5_error_code krb5_k_create_key(krb5_context context, krb5_keyblock *key_data,<br />
krb5_key *out);<br />
krb5_error_code krb5_k_free_key(krb5_context context, krb5_key key);<br />
krb5_error_code krb5_k_key_keyblock(krb5_context context, krb5_key key,<br />
krb5_keyblock **key_data);<br />
krb5_enctype krb5_k_key_enctype(krb5_context context, krb5_key key);<br />
<br />
The following new functions encrypt, decrypt, checksum, or verify data using opaque keys.<br />
<br />
krb5_error_code krb5_k_encrypt(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
const krb5_data *input, krb5_enc_data *output);<br />
krb5_error_code krb5_k_encrypt_iov(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
krb5_crypto_iov *data, size_t num_data);<br />
krb5_error_code krb5_k_decrypt(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
const krb5_enc_data *input, krb5_data *output);<br />
krb5_error_code krb5_k_decrypt_iov(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
krb5_crypto_iov *data, size_t num_data);<br />
krb5_error_code krb5_k_make_checksum(krb5_context context,<br />
krb5_cksumtype cksumtype, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *input,<br />
krb5_checksum *cksum);<br />
krb5_error_code krb5_k_make_checksum_iov(krb5_context context,<br />
krb5_cksumtype cksumtype,<br />
krb5_key key, krb5_keyusage usage,<br />
krb5_crypto_iov *data,<br />
size_t num_data);<br />
krb5_error_code krb5_k_verify_checksum(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *data,<br />
const krb5_checksum *cksum,<br />
krb5_boolean *valid);<br />
krb5_error_code krb5_k_verify_checksum_iov(krb5_context context,<br />
krb5_cksumtype cksumtype,<br />
krb5_key key, krb5_keyusage usage,<br />
const krb5_crypto_iov *data,<br />
size_t num_data,<br />
krb5_boolean *valid);<br />
<br />
These functions do not define a new and complete crypto layer; there are other crypto functions which refer to keyblocks, such as krb5_c_prf and krb5_c_string_to_key, for which there will be no parallel function using krb5_key. Furthermore, the keyblock-using parallels to the above functions will not be deprecated, but they will be documented as being less efficient for repeated operations with the same key usage.<br />
<br />
==Implementation Design==<br />
<br />
The existing krb5_c versions of the new functions will be reimplemented in terms of the krb5_k functions. Internal functions and the enc_provider, hash_providers, and enctype vtables will be redefined using krb5_key so that back ends only need to implement one version of the interface.<br />
<br />
The krb5_key_st structure will initially contain a linked list of derived keys, mapping a derivation constant (krb5_data) to a krb5_key. krb5_derive_key will cache derived keys in this list. The krb5_key_st structure will contain a flag to disable caching so that we don't waste the time allocating and copying such information for keyblock-using functions like krb5_c_encrypt which wouldn't preserve the cache.<br />
<br />
In krb5_auth_context and krb5_gss_ctx_id_rec, all keyblock fields will be replaced with krb5_keys, and all usages of those fields changed to use the krb5_k APIs.<br />
<br />
==Testing==<br />
<br />
The existing t_encrypt.c will be expanded to test the krb5_k APIs as well as the krb5_c APIs where applicable.<br />
<br />
To help measure the performance improvement from caching derived keys, a testing harness will be written to encrypt and decrypt, or hash and verify, a specified number of blocks of a specified size with the same usage, using both the krb5_c and krb5_k APIs, and compare the time taken with each.<br />
<br />
The existing test suite should adequately test the changes to the code paths associated with the auth_context and id_rec structures.<br />
<br />
==Future Work==<br />
<br />
A follow-on project to support cryptographic tokens can define a new krb5_key initializer which creates an external reference, and a new error code for krb5_key_keyblock which indicates that the keyblock data is unavailable.<br />
<br />
==Milestones==<br />
<br />
Implementation work on this project will not begin until work on [[Projects/Crypto modularity]] is substantially completed, so no dates will be specified at this time. The probable order of work will be:<br />
<br />
# Define the krb5_key type (without the derived key list) and its constructors, destructors, and accessors.<br />
# Re-specify the internal crypto functions in terms of krb5_key and make the krb5_c APIs using keyblocks do the appropriate translation when necessary.<br />
# Define the new krb5_k APIs.<br />
# Write the expanded test cases in t_encrypt.c.<br />
# Modify the auth_context and id_rec structures to use krb5_keys and change the relevant code appropriately.<br />
# Implement derived key caching.<br />
# Implement the test harness for measuring the performance improvement from derived key caching.<br />
<br />
==Rationale==<br />
<br />
Several other approaches were considered (see http://mailman.mit.edu/pipermail/krbdev/2009-June/007780.html). The most plausible was to create a cache within the krb5_context structure mapping keyblocks to derived key lists or other information. However, this might not have performed as well, and would have allowed for the possibility of subtle memory leaks if cache entries were not cleaned up properly.<br />
<br />
The naming of the new APIs is problematic, since it is not possible to intuitively capture the notion of "encrypt using a new, different, opaque key type" within a concise name. The krb5_k names were chosen to be distinctive and consistent, if not immediately clear.<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
#[[User:SamHartman|SamHartman]] 15:27, 5 August 2009 (EDT)<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Encryption_performance&diff=1808Projects/Encryption performance2009-08-05T19:23:52Z<p>SamHartman: Projects/Encryption Performance moved to Projects/Encryption performance: wikipedia style has only first word in title caps</p>
<hr />
<div>{{project-review|August 3, 2009}}<br />
<br />
==Desired Changes==<br />
<br />
This project follows after [[Projects/Crypto modularity]] and intends to improve encryption performance by allowing cached information to be added to keys. It also creates API concepts which can be later used for supporting cryptographic tokens.<br />
<br />
The current API uses an exposed structure, krb5_keyblock, to convey key information to the encryption functions. Because the keyblock type is not opaque, we cannot add fields to it without breaking the ABI. If encryption is performed repeatedly with the same key and usage, the derived key must be re-computed each time. If the encryption back end library associates a handle with the key, the handle must be re-initialized each time the key is used.<br />
<br />
Keyblocks are used within several other exposed krb5 structures, including credentials and keytab entries, which would make it difficult to revise the entire API to use a new type. However, in most cases where keyblocks are used within other API structures, the key contents alone are sufficient; such keys are generally either being readied for transmission over the network, or will be used for only a single encryption with a particular key usage. Keys used for repeated encryptions are stored within auth context structures--either krb5_auth_context or krb5_gss_ctx_id_rec--which are opaque and can be modified.<br />
<br />
==API Proposal==<br />
<br />
The keyblock structure retains its current meaning as the exposed data of a cryptographic key. For keys which may be used repeatedly or which may be an external reference, we define a new opaque type krb5_key:<br />
<br />
struct krb5_key_st;<br />
typedef struct krb5_key_st *krb5_key;<br />
<br />
The prefix krb5_k_ will distinguish functions operating on keys from similar functions operating on keyblocks. Opaque keys have the following initializers and accessors:<br />
<br />
krb5_error_code krb5_k_create_key(krb5_context context, krb5_keyblock *key_data,<br />
krb5_key *out);<br />
krb5_error_code krb5_k_free_key(krb5_context context, krb5_key key);<br />
krb5_error_code krb5_k_key_keyblock(krb5_context context, krb5_key key,<br />
krb5_keyblock **key_data);<br />
krb5_enctype krb5_k_key_enctype(krb5_context context, krb5_key key);<br />
<br />
The following new functions encrypt, decrypt, checksum, or verify data using opaque keys.<br />
<br />
krb5_error_code krb5_k_encrypt(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
const krb5_data *input, krb5_enc_data *output);<br />
krb5_error_code krb5_k_encrypt_iov(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
krb5_crypto_iov *data, size_t num_data);<br />
krb5_error_code krb5_k_decrypt(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
const krb5_enc_data *input, krb5_data *output);<br />
krb5_error_code krb5_k_decrypt_iov(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *cipher_state,<br />
krb5_crypto_iov *data, size_t num_data);<br />
krb5_error_code krb5_k_make_checksum(krb5_context context,<br />
krb5_cksumtype cksumtype, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *input,<br />
krb5_checksum *cksum);<br />
krb5_error_code krb5_k_make_checksum_iov(krb5_context context,<br />
krb5_cksumtype cksumtype,<br />
krb5_key key, krb5_keyusage usage,<br />
krb5_crypto_iov *data,<br />
size_t num_data);<br />
krb5_error_code krb5_k_verify_checksum(krb5_context context, krb5_key key,<br />
krb5_keyusage usage,<br />
const krb5_data *data,<br />
const krb5_checksum *cksum,<br />
krb5_boolean *valid);<br />
krb5_error_code krb5_k_verify_checksum_iov(krb5_context context,<br />
krb5_cksumtype cksumtype,<br />
krb5_key key, krb5_keyusage usage,<br />
const krb5_crypto_iov *data,<br />
size_t num_data,<br />
krb5_boolean *valid);<br />
<br />
These functions do not define a new and complete crypto layer; there are other crypto functions which refer to keyblocks, such as krb5_c_prf and krb5_c_string_to_key, for which there will be no parallel function using krb5_key. Furthermore, the keyblock-using parallels to the above functions will not be deprecated, but they will be documented as being less efficient for repeated operations with the same key usage.<br />
<br />
==Implementation Design==<br />
<br />
The existing krb5_c versions of the new functions will be reimplemented in terms of the krb5_k functions. Internal functions and the enc_provider, hash_providers, and enctype vtables will be redefined using krb5_key so that back ends only need to implement one version of the interface.<br />
<br />
The krb5_key_st structure will initially contain a linked list of derived keys, mapping a derivation constant (krb5_data) to a krb5_key. krb5_derive_key will cache derived keys in this list. The krb5_key_st structure will contain a flag to disable caching so that we don't waste the time allocating and copying such information for keyblock-using functions like krb5_c_encrypt which wouldn't preserve the cache.<br />
<br />
In krb5_auth_context and krb5_gss_ctx_id_rec, all keyblock fields will be replaced with krb5_keys, and all usages of those fields changed to use the krb5_k APIs.<br />
<br />
==Testing==<br />
<br />
The existing t_encrypt.c will be expanded to test the krb5_k APIs as well as the krb5_c APIs where applicable.<br />
<br />
To help measure the performance improvement from caching derived keys, a testing harness will be written to encrypt and decrypt, or hash and verify, a specified number of blocks of a specified size with the same usage, using both the krb5_c and krb5_k APIs, and compare the time taken with each.<br />
<br />
The existing test suite should adequately test the changes to the code paths associated with the auth_context and id_rec structures.<br />
<br />
==Future Work==<br />
<br />
A follow-on project to support cryptographic tokens can define a new krb5_key initializer which creates an external reference, and a new error code for krb5_key_keyblock which indicates that the keyblock data is unavailable.<br />
<br />
==Milestones==<br />
<br />
Implementation work on this project will not begin until work on [[Projects/Crypto modularity]] is substantially completed, so no dates will be specified at this time. The probable order of work will be:<br />
<br />
# Define the krb5_key type (without the derived key list) and its constructors, destructors, and accessors.<br />
# Re-specify the internal crypto functions in terms of krb5_key and make the krb5_c APIs using keyblocks do the appropriate translation when necessary.<br />
# Define the new krb5_k APIs.<br />
# Write the expanded test cases in t_encrypt.c.<br />
# Modify the auth_context and id_rec structures to use krb5_keys and change the relevant code appropriately.<br />
# Implement derived key caching.<br />
# Implement the test harness for measuring the performance improvement from derived key caching.<br />
<br />
==Rationale==<br />
<br />
Several other approaches were considered (see http://mailman.mit.edu/pipermail/krbdev/2009-June/007780.html). The most plausible was to create a cache within the krb5_context structure mapping keyblocks to derived key lists or other information. However, this might not have performed as well, and would have allowed for the possibility of subtle memory leaks if cache entries were not cleaned up properly.<br />
<br />
The naming of the new APIs is problematic, since it is not possible to intuitively capture the notion of "encrypt using a new, different, opaque key type" within a concise name. The krb5_k names were chosen to be distinctive and consistent, if not immediately clear.<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Encryption_Performance&diff=1809Projects/Encryption Performance2009-08-05T19:23:52Z<p>SamHartman: Projects/Encryption Performance moved to Projects/Encryption performance: wikipedia style has only first word in title caps</p>
<hr />
<div>#REDIRECT [[Projects/Encryption performance]]</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1201Projects/FAST2009-01-30T21:19:10Z<p>SamHartman: Note that we need client subkey support</p>
<hr />
<div>{{project-review|2009-02-13}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
* Write support for finding ad-fx-fast-armor<br />
* Write support for encrypted challenge<br />
<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write support for encrypted challenge<br />
<br />
* Write FAST TGS support<br />
* Add cookie support<br />
* Add TGS support for authenticator subkeys<br />
<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Write utility to find authorization data in a ticket or authenticator or if-relevant<br />
<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
* add kinit support for testing<br />
<br />
<br />
===Documentation===<br />
<br />
A brief description of the functionality for the admin guide would be useful.<br />
In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.<br />
<br />
==Out of scope==<br />
<br />
* Support for authentication sets<br />
* Support for multi-round-trip mechanisms and KDC_ERR_MORE_PREAUTH_DATA_NEEDED<br />
* Support for anonymous pkinit<br />
* Support for authentication strength indication<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.<br />
<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1200Projects/FAST2009-01-29T19:45:30Z<p>SamHartman: /* Tasks */ add encrypted challenge and authz data</p>
<hr />
<div>{{project-review|2009-02-13}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
* Write support for finding ad-fx-fast-armor<br />
* Write support for encrypted challenge<br />
<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write support for encrypted challenge<br />
<br />
* Write FAST TGS support<br />
* Add cookie support<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Write utility to find authorization data in a ticket or authenticator or if-relevant<br />
<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
* add kinit support for testing<br />
<br />
<br />
===Documentation===<br />
<br />
A brief description of the functionality for the admin guide would be useful.<br />
In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.<br />
<br />
==Out of scope==<br />
<br />
* Support for authentication sets<br />
* Support for multi-round-trip mechanisms and KDC_ERR_MORE_PREAUTH_DATA_NEEDED<br />
* Support for anonymous pkinit<br />
* Support for authentication strength indication<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.<br />
<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1199Projects/FAST2009-01-29T19:36:05Z<p>SamHartman: add out of scope section</p>
<hr />
<div>{{project-review|2009-02-13}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write FAST TGS support<br />
* Add cookie support<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
* add kinit support for testing<br />
<br />
<br />
===Documentation===<br />
<br />
A brief description of the functionality for the admin guide would be useful.<br />
In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.<br />
<br />
<br />
==Out of scope==<br />
<br />
* Support for authentication sets<br />
* Support for multi-round-trip mechanisms and KDC_ERR_MORE_PREAUTH_DATA_NEEDED<br />
* Support for anonymous pkinit<br />
* Support for authentication strength indication<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.<br />
<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1198Projects/FAST2009-01-29T19:32:38Z<p>SamHartman: subst:project-vote</p>
<hr />
<div>{{project-review|2009-02-13}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write FAST TGS support<br />
* Add cookie support<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
* add kinit support for testing<br />
<br />
<br />
===Documentation===<br />
<br />
A brief description of the functionality for the admin guide would be useful.<br />
In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.<br />
<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.<br />
<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1197Projects/FAST2009-01-29T19:31:34Z<p>SamHartman: send out for review</p>
<hr />
<div>{{project-review|2009-02-13}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write FAST TGS support<br />
* Add cookie support<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
* add kinit support for testing<br />
<br />
<br />
===Documentation===<br />
<br />
A brief description of the functionality for the admin guide would be useful.<br />
In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.<br />
<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1196Projects/FAST2009-01-29T19:30:18Z<p>SamHartman: Add docs</p>
<hr />
<div>{{project-early}}><br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write FAST TGS support<br />
* Add cookie support<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
* add kinit support for testing<br />
<br />
<br />
===Documentation===<br />
<br />
A brief description of the functionality for the admin guide would be useful.<br />
In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.<br />
<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1195Projects/FAST2009-01-29T19:27:01Z<p>SamHartman: Tasks for FAST project</p>
<hr />
<div>{{project-early}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
<br />
==Tasks==<br />
<br />
===KDC===<br />
<br />
* Modify KDC to maintain required state and to make available to the calls for processing a request<br />
* Write code to look for FAST, preserve the cookie and process the inner request<br />
* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR<br />
* Write support for generating the cookie and generating a finish sequence<br />
* Write support for fast factors<br />
<br />
===Client changes===<br />
<br />
* Write GIC option for fast armor ticket<br />
* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish<br />
* Write support for PA-FX-ERROR<br />
* Add support for fast factor only pre-auth<br />
* Write support for constructing the fast request<br />
* Write FAST TGS support<br />
* Add cookie support<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1190Projects/FAST2009-01-28T21:41:03Z<p>SamHartman: Proposed initial design</p>
<hr />
<div>{{project-early}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
===KDC Changes===<br />
<br />
In the AS request, things are relatively simple. Find the KRBFastArmoredReq in the padata. If it is present, then decode the request, ignore the outer request and process the FAST request. The cookie from the outer request needs to be saved along with the encoding of the entire request so that the checksum can be computed in a finish message.<br />
The TGS is similar. There is an open question about what ticket is used. It will either be a ticket in the PA-FX-FAST armor or it will be the ticket in PA-TGS-REQ. Either way, the ticket will be in the outer request.<br />
<br />
To construct an error, include an error padata and then package up all the padata into a KRBFastResponse. Then need to construct the cookie. Minimally the cookie will need to include the previous message (minus the cookie). When constructing the finish message , construct the previous message by adding the cookie to it and re-encoding. This assumes the encoders are deterministic, but DER already guarantees this. If the KDC supports multi-round-trip conversations in the future, the cookie will probably also include a checksum state. The previous message cannot be included in this state because it is very difficult to account for the cookie that way. However the current requirements do not involve support for multi-round-trip messages at the current time. Supporting multi-round-trip messages also requires that checksums be extended to support incremental use. For constructing a<br />
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.<br />
<br />
====Needed state====<br />
* armor key<br />
* encoded outer request<br />
* cookie<br />
* inner request and padata<br />
* Reply key used<br />
* kdc verified<br />
* reply key replaced<br />
<br />
===Client changes===<br />
<br />
Extending the client AS logic to support fast seems relatively simple. Before calling into preauth2.c, pull out PA-FX-FAST and PA-FX-COOKIE; ignore other outer pre-authentication. It makes more sense to special case FAST rather than treating it as a normal entry in the pre-authentication list. Managing the finish message and calling into the pre-authentication loop are sufficiently unusual that it does not make sense to go through two levels of the pre-authentication loop.<br />
<br />
The pre-authentication loop needs to support mechanisms that are only used as FAST factors. Support is also required for FAST factors retrieving the armor key, indicating that the reply key has been used, indicating that the reply key is replaced and indicating that the KDC is verified independent of the long-term key.<br />
<br />
<br />
It is desirable that the FAST processing on the client be sufficiently modular it can be reused for the TGS. In that case we currently do not anticipate there being any padata carried by FAST.<br />
<br />
===Utilities needed===<br />
<br />
* encode KRBFastArmoredReq<br />
* Encode KRBFastResponse<br />
* Encode KRBFastReq<br />
* Implement krb_fx_cf2<br />
* Implement PRF for all enctypes<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/FAST&diff=1189Projects/FAST2009-01-28T21:14:37Z<p>SamHartman: update functional requirements</p>
<hr />
<div>{{project-early}}<br />
<br />
[http://tools.ietf.org/internet-drafts/draft-ietf-krb-wg-preauth-fw.txt FAST] is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.<br />
<br />
==Functional requirements==<br />
<br />
* Support for FAST in the AS and TGS in clients and KDCs<br />
* Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST.<br />
* Support for PA-FX-COOKIE<br />
* Support for Encrypted Challenge<br />
* Support for ad-fx-fast-armor in the TGS<br />
* Support for FAST factors in the existing plugin interface<br />
* Support for KRB_FX_CF2<br />
<br />
<br />
===Plugin interface===<br />
<br />
The plugin interface needs to be suitable to be a public API. It seems like small extensions to retrieve the armor key and possibly a few other things to the existing pre-authentication plugin interface would be sufficient.<br />
<br />
The big question is how should fast factors that are not pre-auth methods be handled. There are two approaches. First, define a new version of the function table so that old libraries will not recognize them. Alternatively treat them as normal pre-authentication methods and require that they fail (in a manner that causes them to be ignored) if they are called and the implementation does not support armor.<br />
<br />
<br />
==Design==<br />
<br />
{{project-stub}}<br />
<br />
This design would need to cover the following elements:<br />
<br />
How are host tickets obtained? Do we just use anonymous pkinit all the time or do we cache host tickets to use? If so, how is privilege separation handled?<br />
<br />
<br />
<br />
===API for plugin interface===<br />
<br />
<br />
==External Dependencies==<br />
<br />
The FAST proposal has not yet been approved by the IETF.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Template:Idref&diff=1188Template:Idref2009-01-28T20:57:43Z<p>SamHartman: a template for internet draft references</p>
<hr />
<div>[http://tools.ietf.org/id/{{{1}}} {{{1}}}]</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Aliases&diff=1165Projects/Aliases2009-01-12T18:58:38Z<p>SamHartman: update security concerns; send to review</p>
<hr />
<div>{{project-review|January 16, 2009}}<br />
<br />
This project proposes to add two features. The first is support for '''Unicode principal names and case insensitive principal search'''. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope.<br />
The second feature is generalized support for name canonicalization and server principal aliases.<br />
<br />
==Functional Requirements==<br />
<br />
* If a user logs into a workstation using a case representation of their principal different than that stored in the [[Kerberos database]], then they should be successful.<br />
* A user can use an enterprise name [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-referrals] to log into a workstation.<br />
* Certain accent rules and normalization will be applied to principals for comparison when looking up principals in the kerberos database. The specific rules for what strings will be equal may be database backend specific and will be decided as an implementation matter.<br />
* Servers may have multiple aliases stored in the Kerberos database; users may request any of these aliases and get a ticket.<br />
* Users may log in with an alternate form of their username that is site or realm specific and receive tickets<br />
* Name based authorization for client names will continue to work: the name presented in an AP-REQ needs to be the canonical form of the principal name, not some other form equal to that form.<br />
* The same rules for finding client principals will also apply to lookups for service principals.<br />
* Servers need not keep the implementation of normalization and case folding rules strictly in sync with clients.<br />
<br />
==Case insensitive and international friendly search==<br />
<br />
===Client principals===<br />
<br />
One approach would be to return the principal the client asked for even if the database entry differed from this. The problem is that many Kerberos applications use name based authorization and will do a comparison of the client name in the authenticator against an access control list. Microsoft avoids this with the PAC. However it is not reasonable to assume that applications can be modified to compare principals the same way that the KDC does. Also doing so would break several requirements.<br />
<br />
So, the KDC must only change the client principal when name canonicalization is enabled and only in a manner compatible with client expectations so that the client gets the modified principal.<br />
<br />
<br />
===Server principals===<br />
<br />
Server principals need to be handled differently. The problem is that the KDC cannot generally change the name of the server principal. So, instead, we must return the principal name exactly as the client asked for it. However we need to come up with a solution so that the server doesn't need to know the comparison function the KDC is using.<br />
<br />
We do this by ignoring the server name in the ticket (except in the KDB keytab) and finding a key in the keytab that can decrypt the ticket. If the application passes in constraints about what principal names are used, we use these constraints. If not, we accept any key in the keytab. We update the context claiming that the client authenticated to whatever principal is we found in the keytab.<br />
<br />
==Canonicalization and aliases==<br />
<br />
* Implement an option to kinit to request canonicalization<br />
* Implement a '''canonicalize''' option in krb5.conf to request canonicalization by default<br />
* Add get_init_creds API to request canonicalization<br />
* Implement ability of KDB backends to request that the server or client principal name change<br />
* Canonicalization support is implied either by an enterprise name type or the canonicalize flag.<br />
<br />
===Client principals===<br />
<br />
When the KDC is looking up a client principal, it sets a canonicalize flag in the call to the KDB if canonicalization is desired. If this flag is set, the KDB may return a different alias for the client principal name. This may result from finding a canonical principal of a different case, or by finding an explicit alias. In the case of case mismatch or normalization, it is strongly desired that the KDB backend return the canonical name rather than the name requested by the user. This differs from AD behavior, but is much less likely to break name-based authorization. The KDC will generate a wrong_realm error or a AS reply with a different client name as appropriate.<br />
<br />
If the client sets the canonicalize flag or uses an enterprise name, it will permit the client name to change in an AS reply and will process wrong_realm errors.<br />
===Server aliases===<br />
<br />
For the TGS, the KDC always returns the name of the service that the client requested. However the KDB backend may search using the supplied principal either as the canonical name for the server or as an alias.<br />
<br />
For the AS, if the canonicalize flag is set, the KDB may change the name of the server. Unless the server is a password changing service, this will be reflected back to the client.<br />
<br />
The service is modified to ignore the name in the ticket in krb5_rd_req.<br />
===What is not included===<br />
<br />
The KDC support includes no KDB changes to actually take advantage of the new functionality. The functionality has been tested against a proprietary KDB backend that is not being contributed to MIT Kerberos. So, there will be no way without writing a KDB backend or otherwise changing a KDB backend to take advantage of the KDC changes.<br />
<br />
A simple approach might be to write a KDB backend that interposed itself between the KDC and the DB2 backend and looked up aliases in an alias database.<br />
<br />
There are no changes even to the LDAP backend to support case insensitive or Unicode searches.<br />
<br />
===Security issues===<br />
<br />
Concerns have been raised regarding the security of AS canonicalization as implemented in the current code. In particular, it seems that the approach is vulnerable to phishing attacks. We are attempting to understand whether Windows is vulnerable and if not, how these concerns are addressed.<br />
<br />
In order to address these concerns, the client has been modified to only allow the server name to change from one TGS to another in the AS. That supports the case of Windows short realm names, but does not seem to open significant phishing opportunities. This should be studied in more detail.<br />
<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/PAC_and_principal_APIs&diff=1163Projects/PAC and principal APIs2009-01-12T18:32:13Z<p>SamHartman: approve</p>
<hr />
<div>{{project-approved}}<br />
<br />
<br />
The '''PAC and principal APIs''' project defines some APIs that are useful in an active-directory enviroment.<br />
<br />
==PAC API==<br />
<br />
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.<br />
<br />
<pre><br />
/*<br />
* Windows PAC<br />
*/<br />
struct krb5_pac_data;<br />
typedef struct krb5_pac_data *krb5_pac;<br />
<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_pac_add_buffer<br />
(krb5_context context,<br />
krb5_pac pac,<br />
krb5_ui_4 type,<br />
const krb5_data *data);<br />
<br />
void KRB5_CALLCONV<br />
krb5_pac_free<br />
(krb5_context context,<br />
krb5_pac pac);<br />
<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_pac_get_buffer<br />
(krb5_context context,<br />
krb5_pac pac,<br />
krb5_ui_4 type,<br />
krb5_data *data);<br />
<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_pac_get_types<br />
(krb5_context context,<br />
krb5_pac pac,<br />
size_t *len,<br />
krb5_ui_4 **types);<br />
<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_pac_init<br />
(krb5_context context,<br />
krb5_pac *pac);<br />
<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_pac_parse<br />
(krb5_context context,<br />
const void *ptr,<br />
size_t len,<br />
krb5_pac *pac);<br />
<br />
krb5_error_code KRB5_CALLCONV<br />
krb5_pac_verify<br />
(krb5_context context,<br />
const krb5_pac pac,<br />
krb5_timestamp authtime,<br />
krb5_const_principal principal,<br />
const krb5_keyblock *server,<br />
const krb5_keyblock *privsvr);<br />
</pre><br />
<br />
The ''krb5_pac_parse'' function will allocate a new PAC.<br />
<br />
<br />
In addition, the following internal API is defined:<br />
<pre><br />
krb5_error_code KRB5_CALLCONV<br />
krb5int_pac_sign(krb5_context context,<br />
krb5_pac pac,<br />
krb5_timestamp authtime,<br />
krb5_const_principal principal,<br />
const krb5_keyblock *server_key,<br />
const krb5_keyblock *privsvr_key,<br />
krb5_data *data);<br />
</pre><br />
This function signs and outputs a PAC.<br />
It is internal because it is only useful in the KDC.<br />
<br />
==Principal parsing and comparison==<br />
<br />
Several principal parsing and comparison functions are introduced. Several of these are Heimdal compatible.<br />
<pre><br />
#define KRB5_PRINCIPAL_UNPARSE_SHORT 1 /* Omit realm if it is the local realm */<br />
#define KRB5_PRINCIPAL_UNPARSE_NO_REALM 2 /* Omit realm always */<br />
#define KRB5_PRINCIPAL_UNPARSE_DISPLAY 4 /* Don't escape special characters */<br />
krb5_error_code KRB5_CALLCONV krb5_unparse_name_flags<br />
(krb5_context,<br />
krb5_const_principal,<br />
int,<br />
char **);<br />
krb5_error_code KRB5_CALLCONV krb5_unparse_name_flags_ext<br />
(krb5_context,<br />
krb5_const_principal,<br />
int,<br />
char **,<br />
unsigned int *);<br />
#define KRB5_PRINCIPAL_PARSE_NO_REALM 1 /* Error if realm is present */<br />
#define KRB5_PRINCIPAL_PARSE_REQUIRE_REALM 2 /* Error if realm is not present */<br />
#define KRB5_PRINCIPAL_PARSE_ENTERPRISE 4 /* Create single-component enterprise principle */<br />
krb5_error_code KRB5_CALLCONV krb5_parse_name_flags<br />
(krb5_context,<br />
const char *,<br />
int,<br />
krb5_principal * );<br />
<br />
krb5_boolean KRB5_CALLCONV krb5_principal_compare_any_realm<br />
(krb5_context,<br />
krb5_const_principal,<br />
krb5_const_principal);<br />
#define KRB5_PRINCIPAL_COMPARE_IGNORE_REALM 1<br />
#define KRB5_PRINCIPAL_COMPARE_ENTERPRISE 2 /* compare UPNs as real principals */<br />
#define KRB5_PRINCIPAL_COMPARE_CASEFOLD 4 /* case-insensitive comparison */<br />
#define KRB5_PRINCIPAL_COMPARE_UTF8 8 /* treat principals as UTF-8 */<br />
<br />
krb5_boolean KRB5_CALLCONV krb5_principal_compare_flags<br />
(krb5_context,<br />
krb5_const_principal,<br />
krb5_const_principal,<br />
int);<br />
</pre><br />
<br />
==User to User tickets==<br />
<br />
The following flag is defined for ''krb5_get_credentials'':<br />
<pre><br />
#define KRB5_GC_USER_USER 1 /* want user-user ticket */<br />
#define KRB5_GC_CANONICALIZE 4 /* set canonicalize KDC option */<br />
</pre><br />
The user_user flag searches the ccache for a credential encrypted in the right TGT.<br />
<br />
==Constants==<br />
<pre><br />
/* Name in form of SMTP email name */<br />
#define KRB5_NT_SMTP_NAME 7<br />
/* Windows 2000 UPN */<br />
#define KRB5_NT_ENTERPRISE_PRINCIPAL 10<br />
/* Windows 2000 UPN and SID */<br />
#define KRB5_NT_MS_PRINCIPAL -128<br />
/* NT 4 style name */<br />
#define KRB5_NT_MS_PRINCIPAL_AND_ID -129<br />
/* NT 4 style name and SID */<br />
#define KRB5_NT_ENT_PRINCIPAL_AND_ID -130<br />
#define ADDRTYPE_NETBIOS 0x0014<br />
#define KDC_OPT_CNAME_IN_ADDL_TKT 0x00020000<br />
#define CKSUMTYPE_MD5_HMAC_ARCFOUR -137 /*Microsoft netlogon cksumtype*/<br />
#define KRB5_PADATA_SVR_REFERRAL_INFO 20 /* Windows 2000 referrals */<br />
#define KRB5_PADATA_PAC_REQUEST 128 /* include Windows PAC */<br />
#define KRB5_PADATA_FOR_USER 129 /* username protocol transition request */<br />
#define KRB5_PADATA_S4U_X509_USER 130 /* certificate protocol transition request */<br />
#define KRB5_AUTHDATA_WIN2K_PAC 128<br />
#define KRB5_AUTHDATA_ETYPE_NEGOTIATION 129 /* RFC 4537 */<br />
</pre><br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
Greg Hudson, December 30, 2008<br />
<br />
===Discussion===</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/RFC_4537&diff=1150Projects/RFC 45372009-01-06T17:24:02Z<p>SamHartman: Project for enctype negotiation</p>
<hr />
<div>{{project-review|January 10, 2009}}<br />
<br />
RFC 4537 defines an ''encryption type negotiation'' extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.<br />
<br />
==New krb5_mk_req option==<br />
<br />
The '''AP_OPTS_ETYPE_NEGOTIATION''' option is introduced. If this option is passed into '''krb5_mk_req''', then the RFC 4537 authorization data is included in the AP-REQ. If this data is included and mutual authentication is used, then the server will see if any of the enctypes included in this option are preferred to the ticket session key enctype. If so, one of these enctypes is used to propose a subkey in the ap-rep.<br />
<br />
==GSS-API Integration==<br />
<br />
The GSS-API mechanism uses the AP_OPTS_ETYPE_NEGOTIATION option in gss_init_sec_context. If the acceptor returns a subkey of a different encryption type, it is used.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/domain_realm_referrals&diff=1144Projects/domain realm referrals2008-12-29T17:50:38Z<p>SamHartman: propose new test</p>
<hr />
<div>{{project-review|2008-07-17}}<br />
<br />
== Desired Changes ==<br />
<br />
Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
== Functional Requirements ==<br />
<br />
Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).<br />
<br />
The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.<br />
<br />
== Design ==<br />
<br />
Use a new function, with most of the body of the current krb5_get_host_realm:<br />
<br />
krb5_error_code<br />
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)<br />
<br />
Add a field to the accessor structure, to export it.<br />
<br />
In the KDC code, in TGS processing, if:<br />
* the request is not a user-to-user authentication request<br />
* the server principal name is unknown<br />
* the canonicalize flag is set in the request<br />
* the requested server principal has exactly two components<br />
* either:<br />
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or<br />
** the name type is NT-SRV-HST<br />
* the first component is not in a list configured in the KDC config file under "no_host_referral"<br />
* the second component looks like a fully-qualified domain name<br />
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.<br />
<br />
If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.<br />
<br />
A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".<br />
<br />
The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.<br />
<br />
The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.<br />
<br />
With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.<br />
<br />
== Tasks/Milestones ==<br />
<br />
* Library changes<br />
* Library change test case<br />
* KDC detection of the relevant cases<br />
* KDC implementation of change of principal name<br />
<br />
== Testing Plan ==<br />
<br />
Unit test for the new library routine.<br />
<br />
Manual test of cross-realm case with kvno.<br />
<br />
Manual test of unknown name that maps to the local realm.<br />
<br />
<br />
Test a case involving at least one intermediate realm (referral from a through b to c) where the realm names do not follow the hierarchy; that is where the client would not have chosen any path components on its own. We have some complaints that this does not work on the client side.<br />
<br />
== Notes ==<br />
<br />
Caching the lists of service names isn't in the plan; that can be added later if there's a performance concern.<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
#[[User:SamHartman|SamHartman]] 12:44, 29 December 2008 (EST)<br />
<br />
===Discussion===<br />
<br />
I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.<br />
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)<br />
<br />
: I think today's new version should address Jeff's comments. Posting a new message asking for review.... --[[User:KenRaeburn|KenRaeburn]] 16:17, 3 July 2008 (EDT)</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/domain_realm_referrals&diff=1143Projects/domain realm referrals2008-12-29T17:44:57Z<p>SamHartman: /* Approvals */</p>
<hr />
<div>{{project-review|2008-07-17}}<br />
<br />
== Desired Changes ==<br />
<br />
Eliminate the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral ([https://datatracker.ietf.org/drafts/draft-ietf-krb-wg-kerberos-referrals/ draft-ietf-krb-wg-kerberos-referrals]) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.<br />
<br />
== Functional Requirements ==<br />
<br />
Clients should be able to function with no domain_realm mapping table, by sending requests for the service principal name ''service/canonical-fqdn@LOCAL.REALM'' to the local KDC and requesting referrals. This may be limited to service principal names with specific name types or in specific forms (''e.g.,'' two components where first is in the set {host,ftp,...}).<br />
<br />
The KDC should use only its domain_realm mapping table. No blocking queries to DNS may be introduced.<br />
<br />
== Design ==<br />
<br />
Use a new function, with most of the body of the current krb5_get_host_realm:<br />
<br />
krb5_error_code<br />
krb5int_get_domain_realm_mapping(krb5_context, const char *host, char ***realmsp)<br />
<br />
Add a field to the accessor structure, to export it.<br />
<br />
In the KDC code, in TGS processing, if:<br />
* the request is not a user-to-user authentication request<br />
* the server principal name is unknown<br />
* the canonicalize flag is set in the request<br />
* the requested server principal has exactly two components<br />
* either:<br />
** the name type is NT-UNKNOWN and the first component is listed in the config file under "host_based_services"; or<br />
** the name type is NT-SRV-HST<br />
* the first component is not in a list configured in the KDC config file under "no_host_referral"<br />
* the second component looks like a fully-qualified domain name<br />
then try mapping the FQDN after forcing it to lowercase, or if that mapping fails, the containing domains. If a match is found, then re-process the request as if the client had asked for a cross-realm TGT for the indicated realm, including possibly determining an intermediate realm to return a TGT for instead.<br />
<br />
If the target realm is the local realm, the request should simply fail, since by this point we've already checked the database.<br />
<br />
A listing in "no_host_referral" means no referral processing will be done, even if the client uses NT-SRV-HST or the service is also listed in "host_based_services".<br />
<br />
The special service name "*" in the config file will match any service. So "host_based_services = *" means all NT-UNKNOWN principals will be treated like NT-SRV-HST, that is, referral processing will be done if they actually look like host-based principal names; and "no_host_referral = *" will disable referral processing altogether, regardless of the "host_based_services" setting or the client-supplied name type.<br />
<br />
The config file entries used, from the per-realm data or from libdefaults, are "host_based_services" and "no_host_referral". They may be specified multiple times, and each string value contains one or more (space- or comma-separated) service names.<br />
<br />
With support for "no_host_referral = *" and the expectation that few sites will want to disable this processing completely, I don't see a special need for a separate config file flag for enabling and disabling referral processing explicitly.<br />
<br />
== Tasks/Milestones ==<br />
<br />
* Library changes<br />
* Library change test case<br />
* KDC detection of the relevant cases<br />
* KDC implementation of change of principal name<br />
<br />
== Testing Plan ==<br />
<br />
Unit test for the new library routine.<br />
<br />
Manual test of cross-realm case with kvno.<br />
<br />
Manual test of unknown name that maps to the local realm.<br />
<br />
== Notes ==<br />
<br />
Caching the lists of service names isn't in the plan; that can be added later if there's a performance concern.<br />
<br />
==Review==<br />
<br />
This section documents the review of the project according to [[Project policy]].<br />
It is divided into multiple sections. First, approvals should be listed. To list an approval type<br />
:<nowiki>#~~~~</nowiki><br />
on its own line.<br />
The next section is for discussion. Use standard [http://en.wikipedia.org/wiki/Wikipedia:Tutorial_%28Talk_pages%29 talk page conventions]. In particular, sign comments with <br />
:<nowiki>--~~~~</nowiki><br />
and indent replies.<br />
<br />
Members of Krbcore raising Blocking objections should preface their comment with <nowiki>{{project-block}}</nowiki>. The member who raised the objection should remove this markup when their objection is handled.<br />
<br />
===Approvals===<br />
<br />
#[[User:SamHartman|SamHartman]] 12:44, 29 December 2008 (EST)<br />
<br />
===Discussion===<br />
<br />
I believe that name type needs to be considered and that Jeff Hutzelman's proposal on krbdev should be adopted.; this is not quite a blocking objection but I'd appreciate explicit closure before you go forward with another option.<br />
--[[User:SamHartman|SamHartman]] 13:45, 10 May 2008 (EDT)<br />
<br />
: I think today's new version should address Jeff's comments. Posting a new message asking for review.... --[[User:KenRaeburn|KenRaeburn]] 16:17, 3 July 2008 (EDT)</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Unicode_and_case_folding&diff=1138Projects/Unicode and case folding2008-12-23T20:18:57Z<p>SamHartman: Redirecting to Projects/Aliases</p>
<hr />
<div>#REDIRECT [[Projects/Aliases]]</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Aliases&diff=1136Projects/Aliases2008-12-23T20:02:17Z<p>SamHartman: Projects/Aliasesunicode and case folding moved to Projects/Aliases: oops typo in rename</p>
<hr />
<div>{{project-early}}<br />
<br />
This project proposes to add two features. The first is support for '''Unicode principal names and case insensitive principal search'''. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope.<br />
The second feature is generalized support for name canonicalization and server principal aliases.<br />
<br />
==Functional Requirements==<br />
<br />
* If a user logs into a workstation using a case representation of their principal different than that stored in the [[Kerberos database]], then they should be successful.<br />
* A user can use an enterprise name [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-referrals] to log into a workstation.<br />
* Certain accent rules and normalization will be applied to principals for comparison when looking up principals in the kerberos database. The specific rules for what strings will be equal may be database backend specific and will be decided as an implementation matter.<br />
* Servers may have multiple aliases stored in the Kerberos database; users may request any of these aliases and get a ticket.<br />
* Users may log in with an alternate form of their username that is site or realm specific and receive tickets<br />
* Name based authorization for client names will continue to work: the name presented in an AP-REQ needs to be the canonical form of the principal name, not some other form equal to that form.<br />
* The same rules for finding client principals will also apply to lookups for service principals.<br />
* Servers need not keep the implementation of normalization and case folding rules strictly in sync with clients.<br />
<br />
==Case insensitive and international friendly search==<br />
<br />
===Client principals===<br />
<br />
One approach would be to return the principal the client asked for even if the database entry differed from this. The problem is that many Kerberos applications use name based authorization and will do a comparison of the client name in the authenticator against an access control list. Microsoft avoids this with the PAC. However it is not reasonable to assume that applications can be modified to compare principals the same way that the KDC does. Also doing so would break several requirements.<br />
<br />
So, the KDC must only change the client principal when name canonicalization is enabled and only in a manner compatible with client expectations so that the client gets the modified principal.<br />
<br />
<br />
===Server principals===<br />
<br />
Server principals need to be handled differently. The problem is that the KDC cannot generally change the name of the server principal. So, instead, we must return the principal name exactly as the client asked for it. However we need to come up with a solution so that the server doesn't need to know the comparison function the KDC is using.<br />
<br />
We do this by ignoring the server name in the ticket (except in the KDB keytab) and finding a key in the keytab that can decrypt the ticket. If the application passes in constraints about what principal names are used, we use these constraints. If not, we accept any key in the keytab. We update the context claiming that the client authenticated to whatever principal is we found in the keytab.<br />
<br />
==Canonicalization and aliases==<br />
<br />
* Implement an option to kinit to request canonicalization<br />
* Implement a '''canonicalize''' option in krb5.conf to request canonicalization by default<br />
* Add get_init_creds API to request canonicalization<br />
* Implement ability of KDB backends to request that the server or client principal name change<br />
* Canonicalization support is implied either by an enterprise name type or the canonicalize flag.<br />
<br />
===Client principals===<br />
<br />
When the KDC is looking up a client principal, it sets a canonicalize flag in the call to the KDB if canonicalization is desired. If this flag is set, the KDB may return a different alias for the client principal name. This may result from finding a canonical principal of a different case, or by finding an explicit alias. In the case of case mismatch or normalization, it is strongly desired that the KDB backend return the canonical name rather than the name requested by the user. This differs from AD behavior, but is much less likely to break name-based authorization. The KDC will generate a wrong_realm error or a AS reply with a different client name as appropriate.<br />
<br />
If the client sets the canonicalize flag or uses an enterprise name, it will permit the client name to change in an AS reply and will process wrong_realm errors.<br />
===Server aliases===<br />
<br />
For the TGS, the KDC always returns the name of the service that the client requested. However the KDB backend may search using the supplied principal either as the canonical name for the server or as an alias.<br />
<br />
For the AS, if the canonicalize flag is set, the KDB may change the name of the server. Unless the server is a password changing service, this will be reflected back to the client.<br />
<br />
The service is modified to ignore the name in the ticket in krb5_rd_req.<br />
===What is not included===<br />
<br />
The KDC support includes no KDB changes to actually take advantage of the new functionality. The functionality has been tested against a proprietary KDB backend that is not being contributed to MIT Kerberos. So, there will be no way without writing a KDB backend or otherwise changing a KDB backend to take advantage of the KDC changes.<br />
<br />
A simple approach might be to write a KDB backend that interposed itself between the KDC and the DB2 backend and looked up aliases in an alias database.<br />
<br />
There are no changes even to the LDAP backend to support case insensitive or Unicode searches.<br />
<br />
===Blocking security issues===<br />
<br />
Concerns have been raised regarding the security of AS canonicalization as implemented in the current code. In particular, it seems that the approach is vulnerable to phishing attacks. We are attempting to understand whether Windows is vulnerable and if not, how these concerns are addressed.</div>SamHartmanhttps://k5wiki.kerberos.org/wiki?title=Projects/Aliases&diff=1134Projects/Aliases2008-12-23T20:00:24Z<p>SamHartman: Projects/Unicode and case folding moved to Projects/Aliasesunicode and case folding: Expanded scope to cover all aliasing issues</p>
<hr />
<div>{{project-early}}<br />
<br />
This project proposes to add two features. The first is support for '''Unicode principal names and case insensitive principal search'''. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.<br />
<br />
Protocol extensions for general internationalization or character set conversion are specifically out of scope.<br />
The second feature is generalized support for name canonicalization and server principal aliases.<br />
<br />
==Functional Requirements==<br />
<br />
* If a user logs into a workstation using a case representation of their principal different than that stored in the [[Kerberos database]], then they should be successful.<br />
* A user can use an enterprise name [http://tools.ietf.org/id/draft-ietf-krb-wg-kerberos-referrals] to log into a workstation.<br />
* Certain accent rules and normalization will be applied to principals for comparison when looking up principals in the kerberos database. The specific rules for what strings will be equal may be database backend specific and will be decided as an implementation matter.<br />
* Servers may have multiple aliases stored in the Kerberos database; users may request any of these aliases and get a ticket.<br />
* Users may log in with an alternate form of their username that is site or realm specific and receive tickets<br />
* Name based authorization for client names will continue to work: the name presented in an AP-REQ needs to be the canonical form of the principal name, not some other form equal to that form.<br />
* The same rules for finding client principals will also apply to lookups for service principals.<br />
* Servers need not keep the implementation of normalization and case folding rules strictly in sync with clients.<br />
<br />
==Case insensitive and international friendly search==<br />
<br />
===Client principals===<br />
<br />
One approach would be to return the principal the client asked for even if the database entry differed from this. The problem is that many Kerberos applications use name based authorization and will do a comparison of the client name in the authenticator against an access control list. Microsoft avoids this with the PAC. However it is not reasonable to assume that applications can be modified to compare principals the same way that the KDC does. Also doing so would break several requirements.<br />
<br />
So, the KDC must only change the client principal when name canonicalization is enabled and only in a manner compatible with client expectations so that the client gets the modified principal.<br />
<br />
<br />
===Server principals===<br />
<br />
Server principals need to be handled differently. The problem is that the KDC cannot generally change the name of the server principal. So, instead, we must return the principal name exactly as the client asked for it. However we need to come up with a solution so that the server doesn't need to know the comparison function the KDC is using.<br />
<br />
We do this by ignoring the server name in the ticket (except in the KDB keytab) and finding a key in the keytab that can decrypt the ticket. If the application passes in constraints about what principal names are used, we use these constraints. If not, we accept any key in the keytab. We update the context claiming that the client authenticated to whatever principal is we found in the keytab.<br />
<br />
==Canonicalization and aliases==<br />
<br />
* Implement an option to kinit to request canonicalization<br />
* Implement a '''canonicalize''' option in krb5.conf to request canonicalization by default<br />
* Add get_init_creds API to request canonicalization<br />
* Implement ability of KDB backends to request that the server or client principal name change<br />
* Canonicalization support is implied either by an enterprise name type or the canonicalize flag.<br />
<br />
===Client principals===<br />
<br />
When the KDC is looking up a client principal, it sets a canonicalize flag in the call to the KDB if canonicalization is desired. If this flag is set, the KDB may return a different alias for the client principal name. This may result from finding a canonical principal of a different case, or by finding an explicit alias. In the case of case mismatch or normalization, it is strongly desired that the KDB backend return the canonical name rather than the name requested by the user. This differs from AD behavior, but is much less likely to break name-based authorization. The KDC will generate a wrong_realm error or a AS reply with a different client name as appropriate.<br />
<br />
If the client sets the canonicalize flag or uses an enterprise name, it will permit the client name to change in an AS reply and will process wrong_realm errors.<br />
===Server aliases===<br />
<br />
For the TGS, the KDC always returns the name of the service that the client requested. However the KDB backend may search using the supplied principal either as the canonical name for the server or as an alias.<br />
<br />
For the AS, if the canonicalize flag is set, the KDB may change the name of the server. Unless the server is a password changing service, this will be reflected back to the client.<br />
<br />
The service is modified to ignore the name in the ticket in krb5_rd_req.<br />
===What is not included===<br />
<br />
The KDC support includes no KDB changes to actually take advantage of the new functionality. The functionality has been tested against a proprietary KDB backend that is not being contributed to MIT Kerberos. So, there will be no way without writing a KDB backend or otherwise changing a KDB backend to take advantage of the KDC changes.<br />
<br />
A simple approach might be to write a KDB backend that interposed itself between the KDC and the DB2 backend and looked up aliases in an alias database.<br />
<br />
There are no changes even to the LDAP backend to support case insensitive or Unicode searches.<br />
<br />
===Blocking security issues===<br />
<br />
Concerns have been raised regarding the security of AS canonicalization as implemented in the current code. In particular, it seems that the approach is vulnerable to phishing attacks. We are attempting to understand whether Windows is vulnerable and if not, how these concerns are addressed.</div>SamHartman