logo_kerberos.gif

Difference between revisions of "Projects/FAST"

From K5Wiki
Jump to: navigation, search
(update functional requirements)
(Proposed initial design)
Line 23: Line 23:
 
==Design==
  
==Design==
   
−
{{project-stub}}
  
  +
===KDC Changes===
   
−
This design would need to cover the following elements:
  
  +
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.
   
−
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?
  
  +
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===
   
−
===API for plugin interface===
  
  +
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.
  +
  +
===Utilities needed===
  +
  +
* encode KRBFastArmoredReq
  +
* Encode KRBFastResponse
  +
* Encode KRBFastReq
  +
* Implement krb_fx_cf2
  +
* Implement PRF for all enctypes
   
 
==External Dependencies==
  
==External Dependencies==

Revision as of 16:41, 28 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 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.

Utilities needed

  • encode KRBFastArmoredReq
  • Encode KRBFastResponse
  • Encode KRBFastReq
  • Implement krb_fx_cf2
  • Implement PRF for all enctypes

External Dependencies

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

Retrieved from "https://k5wiki.kerberos.org/wiki?title=Projects/FAST&oldid=1190"