KDC preauthentication interface (kdcpreauth)

============================================

The kdcpreauth interface allows the addition of KDC support for

preauthentication mechanisms beyond those included in the core MIT

krb5 code base.  For a detailed description of the kdcpreauth

interface, see the header file ``<krb5/kdcpreauth_plugin.h>`` (or

``<krb5/preauth_plugin.h>`` before release 1.12).

A kdcpreauth module is generally responsible for:

* Supplying a list of preauth type numbers used by the module in the

  **pa_type_list** field of the vtable structure.

* Indicating what kind of preauthentication mechanism it implements,

  with the **flags** method.  If the mechanism computes a new reply

  key, it must specify the ``PA_REPLACES_KEY`` flag.  If the mechanism

  is generally only used with hardware tokens, the ``PA_HARDWARE``

  flag allows the mechanism to work with principals which have the

  **requires_hwauth** flag set.

* Producing a padata value to be sent with a preauth_required error,

  with the **edata** method.

* Examining a padata value sent by a client and verifying that it

  proves knowledge of the appropriate client credential information.

  This is done with the **verify** method.

* Producing a padata response value for the client, and possibly

  computing a reply key.  This is done with the **return_padata**

  method.

A module can create and destroy per-KDC state objects by implementing

the **init** and **fini** methods.  Per-KDC state objects have the

type krb5_kdcpreauth_moddata, which is an abstract pointer types.  A

module should typically cast this to an internal type for the state

object.

A module can create a per-request state object by returning one in the

**verify** method, receiving it in the **return_padata** method, and

destroying it in the **free_modreq** method.  Note that these state

objects only apply to the processing of a single AS request packet,

not to an entire authentication exchange (since an authentication

exchange may remain unfinished by the client or may involve multiple

different KDC hosts).  Per-request state objects have the type

krb5_kdcpreauth_modreq, which is an abstract pointer type.

The **edata**, **verify**, and **return_padata** methods have access

to a callback function and handle (called a "rock") which can be used

to get additional information about the current request, including the

maximum allowable clock skew, the client's long-term keys, the

DER-encoded request body, the FAST armor key, string attributes on the

client's database entry, and the client's database entry itself.  The

**verify** method can assert one or more authentication indicators to

be included in the issued ticket using the ``add_auth_indicator``

callback (new in release 1.14).

A module can generate state information to be included with the next

client request using the ``set_cookie`` callback (new in release

1.14).  On the next request, the module can read this state

information using the ``get_cookie`` callback.  Cookie information is

encrypted, timestamped, and transmitted to the client in a

``PA-FX-COOKIE`` pa-data item.  Older clients may not support cookies

and therefore may not transmit the cookie in the next request; in this

case, ``get_cookie`` will not yield the saved information.

If a module implements a mechanism which requires multiple round

trips, its **verify** method can respond with the code

``KRB5KDC_ERR_MORE_PREAUTH_DATA_REQUIRED`` and a list of pa-data in

the *e_data* parameter to be processed by the client.

The **edata** and **verify** methods can be implemented

asynchronously.  Because of this, they do not return values directly

to the caller, but must instead invoke responder functions with their

results.  A synchronous implementation can invoke the responder

function immediately.  An asynchronous implementation can use the

callback to get an event context for use with the libverto_ API.

.. _libverto: https://fedorahosted.org/libverto/