Difference between revisions of "Projects/FAST"

Latest revision as of 23:13, 15 February 2010

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

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
• Write support for finding ad-fx-fast-armor
• Write support for encrypted challenge

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 support for encrypted challenge

• Write FAST TGS support
• Add cookie support
• Add TGS support for authenticator subkeys

Utilities needed

• encode KRBFastArmoredReq
• Encode KRBFastResponse
• Write utility to find authorization data in a ticket or authenticator or if-relevant

• Encode KRBFastReq
• Implement krb_fx_cf2
• Implement PRF for all enctypes
• add kinit support for testing

Documentation

A brief description of the functionality for the admin guide would be useful. In addition, a description of the API introduced with the GIC options and updating the comments for the plugin interface will be required.

Out of scope

• Support for authentication sets
• Support for multi-round-trip mechanisms and KDC_ERR_MORE_PREAUTH_DATA_NEEDED
• Support for anonymous pkinit
• Support for authentication strength indication

External Dependencies

The FAST proposal has not yet been approved by the IETF.

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

on its own line. The next section is for discussion. Use standard talk page conventions. In particular, sign comments with

--~~~~

and indent replies.

Members of Krbcore raising Blocking objections should preface their comment with {{project-block}}. The member who raised the objection should remove this markup when their objection is handled.

Approvals

ghudson, 2009-03-23

Discussion