Re: Mechanism extensions and the GSSAPI

[Jonathan Stone <jonathan@dsg.stanford.edu>]

I'm reading this solely on heimdal-discuss, and its becoming
increasingly incomprehensible. What are these "shim" and "ioctl"
layers? Do they have anything to do with actual exposed APIs, or are
they merely Linux/MIT-internal details? What does it all mean for a
Heimdal user?

If a comparison data-point helps:

I use Heimdal on various *BSD flavours, all of which have the
crypto(9) API.

Recent (~last-yearish) Heimdal code requests crypto operations using
the OpenSSL crypto libraries. On all the recent *BSD platforms, where
hardware acceleration is available, the OpenSSL crypto libraries map
those requests onto /dev/crypto(4) ioctls, and thus to hardware
crypto(9).  (Non-accelerated requests are done in userspace, to avoid
paying the costs of crossing the kernel protection-boundary.)

I can't for the life of me tell whether that's anything like the
ioctl/shim layers being discussed here.

I'm also interested in hardware acceleration of GSSAPI calls for
NFSv4/NFSv3, with GSSAPI RPC creds.

On *BSD, with crypto(9) the simplest high-performance implementation
is for the kernel to pass GSS-API blobs to and from a user-space
daemon. When that daemon completes the GSSAPI exchanges, it passes the
transform-type and session keys into the kernel which creates
crypto(9) context for the given keys and privacy/integrity checks.

Mechanism extension that lets someone glue new mechanisms (AES-CBC?
AES in Galois counter mode?) in would be great. OTOH, it does assume a
standard public API for leaking algorithm-plus-session keys from an
established context, so the keys can be passed into the kernel;
without the (shim?) layer needing to know the internal details of all
the algorithms and types.  In that sense of "shim", the shim is
OS-dependent; and the algorihm/key info shoul be passed across the
shim as an opaque object (i.e,. via something like oids).  Particuarly
given the poor (and RPC-protocol dependent) specifications on bindings
between GSSAPI protection, and underlying cryptographic algorithms.

Or am I missing the point of the discussion completely?