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.

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.

+

+

+

==Tasks==

+

+

===KDC===

+

+

* Modify KDC to maintain required state and to make available to the calls for processing a request

+

* Write code to look for FAST, preserve the cookie and process the inner request

+

* Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR

+

* Write support for generating the cookie and generating a finish sequence

+

* Write support for fast factors

+

+

===Client changes===

+

+

* Write GIC option for fast armor ticket

+

* Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish

+

* Write support for PA-FX-ERROR

+

* Add support for fast factor only pre-auth

+

* Write support for constructing the fast request

+

* Write FAST TGS support

+

* Add cookie support

===Utilities needed===

===Utilities needed===

Line 56:

Line 77:

* Implement krb_fx_cf2

* Implement krb_fx_cf2

* Implement PRF for all enctypes

* Implement PRF for all enctypes

+

==External Dependencies==

==External Dependencies==

Revision as of 15:27, 29 January 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

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

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

KDC Changes

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.
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.

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
reply, construct everything. Move any padata into a constructed FAST. Then construct the finish message.

Needed state

armor key

encoded outer request

cookie

inner request and padata

Reply key used

kdc verified

reply key replaced

Client changes

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.

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.

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.

Tasks

KDC

Modify KDC to maintain required state and to make available to the calls for processing a request

Write code to look for FAST, preserve the cookie and process the inner request

Rewrite error generation to support pa-data for all errors, generate FAST and include PA_FX_ERROR

Write support for generating the cookie and generating a finish sequence

Write support for fast factors

Client changes

Write GIC option for fast armor ticket

Write support for routines to pull out PA-FX-FAST, PA-FX-COOKIE, and verify finish