The Microsoft SSPI provides an interface for in-place encryption of messages (see MS-KILE section 188.8.131.52ff). This interface also permits additional data to be included in the checksum generated to protect integrity. Such a facility is called authenticated encryption with additional data (AEAD). The SSPI works at the GSS-API layer, rather than the raw Kerberos layer.
This project proposes to extend the raw Kerberos cryptographic API (krb5_c_*) in order to make it possible to implement these SSPI facilities in an extension to the GSS-API. The ultimate consumer of these applications is typically DCE-style RPC, although the facilities could be used by other applications.
This project proposes to add two features. The first is support for Unicode principal names and case insensitive principal search. The goal of this project is to get behavior more similar to Microsoft and to search for principals in a manner that supports international use somewhat better. This includes case insensitive search and support for ignoring accents in search.
Protocol extensions for general internationalization or character set conversion are specifically out of scope. The second feature is generalized support for name canonicalization and server principal aliases.
FAST is a pre-authentication framework for Kerberos. It includes a mechanism for tunneling pre-authentication exchanges using armoured KDC messages. FAST provides increased resistance to passive password guessing attacks.
The GSS-API DCE project proposes to add functionality found in SSPI to MIT Kerberos; this functionality includes support for AEAD and support sufficient to implement DCE RPC on top of MIT Kerberos. This project depends on and is a companion to Projects/AEAD encryption API.
This project will provide the ability to add a new master key (with an enctype differing from the current master key) to the master key principal and stash file and then migrate the encryption of existing principals long term keys to use the new master key. In addition deletion of master keys will be provided.
The point of this small project is to change the format of the master key stash file to that of a keytab type file. This will allow the master key's KVNO to be stored along with its enctype and key data which in turn will enable an efficient implementation of master key updating.
Microsoft Windows uses a data structure called the PAC in order to convey authorization information. See the expired draft-brezak-win2k-krb-authz-00 for documentation. The PAC is logically a set of type-length-value elements. That is, it is a collection of typed data items, and lengths are associated with each type. Typically the data items are NDR encoded. This API provides facilities to create and sign a PAC and to extract a given typed buffer from a PAC. NDR encoders and decoders are not provided.
The RFC 3244 project adds support for the Microsoft set password protocol server to MIT Kerberos. In addition, it adds support for both that protocol and the traditional kpasswd protocol over TCP. This protocol is added for better compatibility with Microsoft Windows.
RFC 4537 defines an encryption type negotiation extension to Kerberos. This option allows clients and servers to use a stronger or faster bulk encryption mechanism even if the KDC does not support it. The client indicates a set of supported encryption types in the ap-req. If the server chooses one of these encryption types then it proposes a subkey in the ap-rep with an encryption type different than that selected by the client.
The goal of this project is to remove most of the krb4 code from the Kerberos source code base.
The goals of this project are to:
- change the behaviour of krb5_rd_req() to always verify known authorization data elements
- provide an attribute-based GSS interface for inquiry and submission of authorization information (draft-ietf-kitten-gssapi-naming-exts)
- provide an attribute-based plugin interface for verification and serialization of authorization information
- encourage the use of positive authorization data by providing sample KDC and application plugins
Eliminates the need for the domain_realm mapping table on the client side, in the common case, by implementing minimal referral (draft-ietf-krb-wg-kerberos-referrals) support in the KDC and providing the mapping information to clients through that protocol. Modern client code (MIT, Heimdal, and Microsoft, at least) should contain all the support needed to take advantage of this.
In order to avoid false positives we require that the replay cache data structure store sufficient data to be able to distinguish between two authenticators while at the same time maintaining compatibility with existing deployments.