- Summary

  The FAST-OTP project proposes the implementation of a FAST factor
  for one-time password pre-authentication as described in
  [draft-ietf-krb-wg-otp-preauth].  In short, a user will be able to
  use an OTP to get a ticket.

  Project URL:
  https://portal.nordu.net/display/KRBFASTOTP/Passwords+should+not+be+reused


- Functionality

  A plugin framework will provide for deployment and configuration of
  different OTP systems both for clients (like kinit) and the KDC.

  The goal is to support time-based, event-based and challenge-based
  OTP schemes.

  Three FAST facilities will be provided, namely
  client-authentication, replacing-reply-key and, for some OTP
  schemes, KDC-authentication.

  Both the 4-pass and the 2-pass version of the protocol will be
  implemented.

  Support for connected OTP tokens will not be implemented.

  Support for OTP systems using PIN in the generating of the OTP will
  [XXX probably] not be implemented.

  Support for change of PIN will [XXX probably] not be implemented.


- Preconditions

  A functional FAST framework with debug and trace.


- Design

  The design of parts specific to the FAST framework is described in
  [draft-ietf-krb-wg-otp-preauth].

  A preauth plugin module will be implemented for use by clients and
  the KDC.  This module will itself implement a plugin framework for
  different kind of OTP systems.

  The client plugin will be responsible for [XXX].

  The server plugin will be responsible of contacting an external OTP
  authentication service for retrieving an authentication decision
  (yes/no) based on a user id, a one-time password and possibly more
  depending on the OTP authentication service.  Specification of the
  protocol between the KDC server side plugin and the OTP
  authentication service is outside the scope of this document.

  The KDC will have to be able to decide whether a given principal in
  the KDC database should be able to (or even _have_to_) authenticate
  using a one-time password.  [To extend the kdb or to not, that's the
  fine question.]  The information stored regarding OTP for a
  principal will include i) OTP mechanism [like vendor or "OATH"], ii)
  OTP authentication server endpoint and iii) mapping between a
  Kerberos principal and some token used to identify a user with the
  OTP authentication server.

  In order to avoid certain replay attacks, availability of the 2-pass
  version of the protocol can be disabled.


- Tasks

  - implement an OTP plugin framework, client side

  - implement an OTP plugin framework, server side (KDC)

  - extend the KDC database to accommodate the new OTP policy section

  - protocol, common to client and server

    - construct otp-preauth client and reply keys
      [draft-ietf-krb-wg-otp-preauth sect. 3.6]

  - protocol, client side

    - handle a KRB-ERROR with a PA-FX-FAST-REPLY containing a
      PA-OTP-CHALLENGE

    - send a PA-OTP-REQUEST in an AS-REQ

  - protocol, server side

    - construct otp-keyInfo element to indicate to client which token
      should be used

    - send a PA-OTP-CHALLENGE in a KrbFastResponse

  - implement a dummy OTP plugin using a static password
    
  - implement an OATH OTP plugin


- UI

  kinit -X ATTRIBUTE=VALUE [XXX name valid ATTRIBUTE's]

  
- Documentation

  XXX


- Dependencies

  draft-ietf-krb-wg-otp-preauth stability.


- Testing

  XXX


- Integration and relase

  XXX