Projects/VerifyAuthData
Contents
Background
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
Architecture
A new opaque type, an authorization data context (krb5_authdata_context) provides an attribute-based accessor onto a set of authorization data elements. The operations which one can perform on this context roughly mirror those specified in draft-ietf-kitten-gssapi-naming-exts.
An authorization data context is always created and authenticated by krb5_rd_req(). Access to it is provided via the krb5_auth_con_get_authdata_context() API. The public interface is provided via draft-ietf-kitten-gssapi-naming-exts.
The authorization data context encapsulates a set of authorization data systems, each which provide support for one or more authorization data types. Each system is instantiated as a module, one for each authorization data type. This is modelled closely on the client-side preauthentication SPI. The set of systems is extensible at runtime through a plug-in interface.
Windows PAC
An authorization data system for the Windows 2000 PAC is built into libkrb5, as a wrapper around the krb5_pac APIs introduced in MIT Kerberos 1.7. A vendor that wished to expose inner PAC fields (such as SIDs) as attributes could do so by registering the appropriate plug-in, avoiding the overhead of building a NDR parser into libkrb5.
Initiator/acceptor data
Systems that implement the AD_USAGE_AP_REQ usage can serialize attributes for inclusion in an AP-REQ. The "greet_client" plugin is one such system: it conveys a single string from initiator to acceptor in the authorization data of the AP-REQ authenticator. (Later, we may implement AD_USAGE_AS_REQ and AD_USAGE_TGS_REQ.) Plugins that only need to verify and inquiry about KDC issued authorization data, such as the Windows 2000 PAC, implement the AD_USAGE_KDC_ISSUED usage.
Unfortunately due to some bugs in the MIT mechglue, this is not presently useable with pseudo-mechanisms such as SPNEGO.
Limitations
This interface is not designed to be used for authorization data construction or verification within the KDC, at least at this stage. The existing authorization data SPI contributed by Apple and Novell should be used for this.
Implementation
libkrb5
GSS
Example
Note the "greet:greeting" attribute; rather than being issued by the KDC, this was set by the initiator on the target name using gss_set_name_attribute(), and conveyed in the AP-REQ. The acceptor retrieves it like any other attribute, but note it is not marked "Authenticated".
% ./t_namingexts test.keytab init module "greet", ad_type -42, flags 00000014 init module "mspac", ad_type 128, flags 00000008 Source name: host/test.de.padl.com@DE.PADL.COM Attribute mspac: Authenticated Complete 050000000000000001000000b001000058000000000000000a00000034000000 ... Attribute mspac:logon-info Authenticated Complete 01100800cccccccca001000000000000000002006ed28d68cd25ca01ffffffff ... Attribute mspac:client-info Authenticated Complete 802862d64026ca012a0068006f00730074002f00720061006e0064002e006400 ... Attribute mspac:upn-dns-info Authenticated Complete 2a00100016004000000000000000000068006f00730074002f00720061006e00 ... Attribute mspac:server-checksum Authenticated Complete 100000004b12be9500319e6fb731cb07 Attribute mspac:privsvr-checksum Authenticated Complete 76ffffff812d7a725e999ca41dd6e51fdc64d501 Attribute greet:greeting Complete 48656c6c6f2c206163636570746f7220776f726c6421 Exported name: 0402000b06092a864886f71201020200000021686f73742f72616e642e64652e ...
Open issues
- Should we refactor the server side auth data plugin interface to more closely mirror this one?
Status
Code is in the users/lhoward/authdata branch.
