diff options
Diffstat (limited to 'crypto/krb5/doc/plugindev/kdcpreauth.rst')
| -rw-r--r-- | crypto/krb5/doc/plugindev/kdcpreauth.rst | 79 |
1 files changed, 0 insertions, 79 deletions
diff --git a/crypto/krb5/doc/plugindev/kdcpreauth.rst b/crypto/krb5/doc/plugindev/kdcpreauth.rst deleted file mode 100644 index ab7f3a9022b1..000000000000 --- a/crypto/krb5/doc/plugindev/kdcpreauth.rst +++ /dev/null @@ -1,79 +0,0 @@ -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/ |