xref: /freebsd/crypto/krb5/doc/html/_sources/plugindev/kdcpreauth.rst.txt (revision 7f2fe78b9dd5f51c821d771b63d2e096f6fd49e9)
1KDC preauthentication interface (kdcpreauth)
2============================================
3
4The kdcpreauth interface allows the addition of KDC support for
5preauthentication mechanisms beyond those included in the core MIT
6krb5 code base.  For a detailed description of the kdcpreauth
7interface, see the header file ``<krb5/kdcpreauth_plugin.h>`` (or
8``<krb5/preauth_plugin.h>`` before release 1.12).
9
10A kdcpreauth module is generally responsible for:
11
12* Supplying a list of preauth type numbers used by the module in the
13  **pa_type_list** field of the vtable structure.
14
15* Indicating what kind of preauthentication mechanism it implements,
16  with the **flags** method.  If the mechanism computes a new reply
17  key, it must specify the ``PA_REPLACES_KEY`` flag.  If the mechanism
18  is generally only used with hardware tokens, the ``PA_HARDWARE``
19  flag allows the mechanism to work with principals which have the
20  **requires_hwauth** flag set.
21
22* Producing a padata value to be sent with a preauth_required error,
23  with the **edata** method.
24
25* Examining a padata value sent by a client and verifying that it
26  proves knowledge of the appropriate client credential information.
27  This is done with the **verify** method.
28
29* Producing a padata response value for the client, and possibly
30  computing a reply key.  This is done with the **return_padata**
31  method.
32
33A module can create and destroy per-KDC state objects by implementing
34the **init** and **fini** methods.  Per-KDC state objects have the
35type krb5_kdcpreauth_moddata, which is an abstract pointer types.  A
36module should typically cast this to an internal type for the state
37object.
38
39A module can create a per-request state object by returning one in the
40**verify** method, receiving it in the **return_padata** method, and
41destroying it in the **free_modreq** method.  Note that these state
42objects only apply to the processing of a single AS request packet,
43not to an entire authentication exchange (since an authentication
44exchange may remain unfinished by the client or may involve multiple
45different KDC hosts).  Per-request state objects have the type
46krb5_kdcpreauth_modreq, which is an abstract pointer type.
47
48The **edata**, **verify**, and **return_padata** methods have access
49to a callback function and handle (called a "rock") which can be used
50to get additional information about the current request, including the
51maximum allowable clock skew, the client's long-term keys, the
52DER-encoded request body, the FAST armor key, string attributes on the
53client's database entry, and the client's database entry itself.  The
54**verify** method can assert one or more authentication indicators to
55be included in the issued ticket using the ``add_auth_indicator``
56callback (new in release 1.14).
57
58A module can generate state information to be included with the next
59client request using the ``set_cookie`` callback (new in release
601.14).  On the next request, the module can read this state
61information using the ``get_cookie`` callback.  Cookie information is
62encrypted, timestamped, and transmitted to the client in a
63``PA-FX-COOKIE`` pa-data item.  Older clients may not support cookies
64and therefore may not transmit the cookie in the next request; in this
65case, ``get_cookie`` will not yield the saved information.
66
67If a module implements a mechanism which requires multiple round
68trips, its **verify** method can respond with the code
69``KRB5KDC_ERR_MORE_PREAUTH_DATA_REQUIRED`` and a list of pa-data in
70the *e_data* parameter to be processed by the client.
71
72The **edata** and **verify** methods can be implemented
73asynchronously.  Because of this, they do not return values directly
74to the caller, but must instead invoke responder functions with their
75results.  A synchronous implementation can invoke the responder
76function immediately.  An asynchronous implementation can use the
77callback to get an event context for use with the libverto_ API.
78
79.. _libverto: https://fedorahosted.org/libverto/
80