Serialization framework future

[Nico Williams]

On Wed, May 30, 2012 at 4:31 PM,  <ghudson at mit.edu> wrote:
> I'm working on implementing gss_import_cred/gss_export_cred, and for
> that I'll need a way to serialize a credential (the TGT credential
> from a memory ccache).

Well, the obvious solution for *ticket* credentials is to use a
KRB-CRED with the null enctype for the encrypted part.

The only problem is that you might also want to be able to
export/import keytab entries.  If so then I recommend using a
structure that has an optional KRB-CRED for tickets (see above) and an
optional keytab file's contents.

> This leads me to think about the state of our serialization framework,
> which I'm not fond of for a number of reasons: the coding style is
> rather divergent from our current practices, it uses krb5_* symbol
> names even though it's not part of the public API, and everything goes
> through a table lookup of KV5M_* values for no reason (which adds
> artificial exception cases for sizing and serializing).

I've never liked the serialization code in MIT.

> 1. Leave it alone (just add a cred serializer without changing
> anything about the code).

Reusing KRB-CRED strikes me as better.

> 2. Alter the coding style and symbol names without changing the
> design.

That'd be OK, but still not very satisfying.

> 3. Rewrite it more aggresively (eliminate the magic number table and
> just having size/serialize/unserialize functions for each type).
>
> 4. Borrow the krb5_storage framework from Heimdal.
>
> Heimdal's krb5_storage is a readable/writable buffer with a few
> different back ends (fixed memory, resizable memory, and file
> descriptor; it has an internal vtable with fetch/store/seek/trunc/free
> operations), along with some functions for marshalling and
> unmarshalling krb5 data types to or from a buffer.  It's maybe a
> little over-engineered for this specific purpose, but it could come in
> handy for other purposes, and could perhaps replace k5buf and asn1buf
> in the future.  We would have to alter the code somewhat to fit, so it
> wouldn't be a simple drop-in.

The Heimdal krb5_storage stuff is actually quite useful.  It's used
for a number of purposes, including for XDR (for MIT kadmin protocol
compatibility), the Heimdal kadmin protocol, and iprop, among other
things.  The nice thing about it is that it takes care of buffer
management.  But it's very low-level...  Compare to an ASN.1 compiler.
 Reusing KRB-CRED is where the ASN.1 angle comes in.  Having an ASN.1
compiler makes it easy to argue for using DER to serialize various
things.

For example, for exported composite name tokens I'd say the ideal
thing to do is to serialize the Ticket from the AP-REQ (on the
acceptor side) as well as the unencrypted enc-part of that Ticket.

OTOH, serializing auth_context with krb5_storage is much simpler than
using an ASN.1 compiler since you can't re-design the
krb5_auth_context structure.

> Opinions?

Reuse KRB-CRED for tickets, use an ASN.1 compiler wherever you can,
use krb5_storage in all other cases.

Nico
--