Projects/VerifyAuthData

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

Background

The goals of this project are to:

• change the behaviour of krb5_rd_req() to always verify known authorization data types
• provide an interface to indicate which authorization data types have been verified
• potentially add a plug-in interface for new authorization data verification functions

This is a first step towards supporting draft-ietf-kitten-gssapi-naming-exts.

Architecture

Verification of known authorization data types will be performed by krb5_rd_req_decoded_opt() (which assures that the auth data will always be verified, and avoids the potential expense of scanning the keytab twice).

We will add an argument to krb5_rd_req_decoded_opt() to indicate whether auth data should be verified, and perhaps another to indicate which types were verified (although the extent to which that is exposed at higher levels is undecided).

There will also be an API for enumerating the auth data types for which verification is supported, and potentially for registering new verification functions (although it's more likely that this will be done via a plugin interface, as for preauth plugins).

Note: we don't wish to (yet) change the behaviour of krb5_rd_req() in the KDC, when handling a TGS-REQ. The authorization data interface in the KDC has been designed on the presumption that plugins and/or the backend will manage authorization data. To avoid API changes, we may overload krb5_rd_req_decoded_anyflag() (used by the KDC) to imply that the authorization data is not verified.