Adding utility function to construct e_data sequences of padata

Sam Hartman hartmans at MIT.EDU
Wed Sep 1 20:17:21 EDT 2010



As a refresher, there's an e_data field in Kerberos errors that is an
opaque untyped hole.

For PREAUTH_REQUIRED, RFC 4120 makes it clear this takes a sequence of
MethodData (padata).
However for different error types it could conceptually take other
things.

In practice  the only other thing it took in our code was TypedData.
That is particularly used by pkinit.

However, in order to provide full flexibility, the verify callback in
the preauth interface passes in a place for the method to fill in the
full e_data (as a krb5_data **).

We decided this was kind of a mess when we worked on the preauth
framework.
There,  we decided that everything within a FAST factor--even things
specified to be TypedData would actually be specified to be TypedData
would actually be sent as MethodData.


The SAM2 mechanism is a multi-round-trip mechanism at least sometimes.
However it does things differently than the preauth framework.  It sends
back a fake PREAUTH_REQUIRED error rather than a MORE_PREAUTH_NEEDED
error.

>From an implementation standpoint that means I need to actually cause a
PREAUTH_REQUIRED error. I also need to populate the padata in that error
with some things I learn in the verify callback.
I'll explain how the code currently does this in a bit; we won't take
that approach.

The right solution here is to generate a new version of the preauth
plugin interface where the verify entry point takes an array of pa_data
rather than an single e_data.

That's more work than I'd prefer to do now.  So, instead, I propose to
create a utility function in libkrb5 that will be intended for KDC side
preauth plugins to use that will generate an encoded ASN.1 structure to
fit into a krb5_data from an array of padata.  This will be an exported
symbol but its prototype should probably live in the preauth plugin
header because only preauth plugins should need this.

Objections?

For reference, the current behavior of the code is to store per-request
information in a special tl_data that is stored in the client db_entry
(but never written out to disk) in the verify callback.  The verify
callback does not set the hw_auth bit in the ticket, so check_padata
fails and generates a preauth_required error.  The get_e_data entry
point in the preauth method finds this special tl_data and does
something with it.  Given that I have all the information I need in the
verify entry point and that I can return an error right there, I'd
rather avoid the special tl_data.  Another option that is also wrong is
to use the per-request preauth context.  That context is not available
to the get_e_data entry point because that entry point is not intended
to be called after the verify callback.  The code as it exists was a
reasonable design for when it was written back in 2002 well before the
try_again client entry point existed and the verify entry point gained
e_data.



More information about the krbdev mailing list