Difference between revisions of "Projects/FAST"
KenRaeburn (talk | contribs) m (fix case) |
SamHartman (talk | contribs) (update functional requirements) |
||
Line 1: | Line 1: | ||
{{project-early}} |
{{project-early}} |
||
− | [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 |
+ | [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. |
==Functional requirements== |
==Functional requirements== |
||
− | * Implement FAST and the appropriate timestamp mechanism that is standardardized by the working group. |
||
+ | * Support for FAST in the AS and TGS in clients and KDCs |
||
− | * Provide a plugin interface so that third parties can write FAST factors. |
||
+ | * Support for armor tickets obtained from host TGTs sufficient for [[pam_krb5 ]] to use FAST. |
||
− | * Implement Anonymous Pkinit |
||
+ | * Support for PA-FX-COOKIE |
||
+ | * Support for Encrypted Challenge |
||
+ | * Support for ad-fx-fast-armor in the TGS |
||
+ | * Support for FAST factors in the existing plugin interface |
||
+ | * Support for KRB_FX_CF2 |
||
+ | |||
===Plugin interface=== |
===Plugin interface=== |
||
− | The plugin interface needs to be suitable to be a public API. |
+ | 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. |
+ | |||
+ | 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. |
||
+ | |||
==Design== |
==Design== |
Revision as of 16:14, 28 January 2009
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.
Contents
Functional requirements
- Support for FAST in the AS and TGS in clients and KDCs
- Support for armor tickets obtained from host TGTs sufficient for pam_krb5 to use FAST.
- Support for PA-FX-COOKIE
- Support for Encrypted Challenge
- Support for ad-fx-fast-armor in the TGS
- Support for FAST factors in the existing plugin interface
- Support for KRB_FX_CF2
Plugin interface
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.
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.
Design
This design would need to cover the following elements:
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?
API for plugin interface
External Dependencies
The FAST proposal has not yet been approved by the IETF.