1 files changed, 79 insertions, 0 deletions
diff --git a/roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5/doc/plugindev/kdcpreauth.rst b/roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5/doc/plugindev/kdcpreauth.rst
new file mode 100644
index 000000000..ab7f3a902
--- /dev/null
+++ b/roms/edk2/CryptoPkg/Library/OpensslLib/openssl/krb5/doc/plugindev/kdcpreauth.rst
@@ -0,0 +1,79 @@
+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/