[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mechanism extensions and the GSSAPI
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
If a comparison data-point helps:
I use Heimdal on various *BSD flavours, all of which have the
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?