[OpenAFS-devel] Re: configurable cryptosystem support

[Nicolas Williams]

On Wed, Jan 24, 2007 at 03:23:28PM -0500, Marcus Watts wrote:
> Dale Ghent <daleg@umbc.edu> had replied to Nico:
> > To add to this discussion, the Crypto project just opened up on  
> > opensolaris.org:
> > 
> > http://opensolaris.org/os/project/crypto/
> 
> Yes, this is interesting.  It sounds like openafs on solaris might
> just really rock, with a bit of work.

Good.

> ...
> > > The kernel-land bits of it are not, IIRC, a part of the DDI yet, but
> > > that doesn't mean that OpenAFS couldn't get a contract to use them, if
> > > desired.  (A contract meaning that OpenAFS would get suitable warning
> > > prior to any backwards incompatible releases; this should have come up
> > > in the context of VOP interfaces.)
> 
> OK.  I'm not sure what needs to happen here but presumably once
> we get code that works we can go through that.

Basically, you should consider asking on the OpenSolaris security and
arc discuss lists about contracting these interfaces or promoting their
stability.  A contract should be good enough for you in that it would be
a commitment on the part of the team responsible for these interfaces
that you'd get a heads up about any backwards-incompatible changes.
Promoting the interface stability would be even better for you, but
that's up to the crypto team.

> > > No, support for CTS mode is not included in the SCF, so the caller has
> > > to fashion CTS out of CBC or ECB mode.  And yes, the Solaris krb5 code
> > > currently implements CTS mode fairly inefficiently (with as many calls
> > > into the SCF as there are blocks to encrypt/decrypt; it should really
> > > never do more than two calls into the SCF, and, really, with the  
> > > benefit
> > > of hindsight I'm starting to wonder at the wisdom of CTS).
> 
> Well, as the person that's in part responsible for CTS happening --
> cts has several positives; it takes care of the length encoding
> problem, and it does so in a way that does not increase size even for
> small or odd-sized pieces of data.  With the larger blocksize of AES,
> and especially for parts of kerberos that deal with small odd sized
> bits of data (such as MIT's kdb), this is a significant issue.
> Security-wise, CTS is practically identical to CBC.  Indeed, if CTS is
> done right, it's exactly equivalent to CBC when handed even sized blocks
> of data.  For Kerberos/AES, the implementation rounds the wrong way so
> the last 2 blocks are effectively swapped.  The implementation of cts
> that's in k5ssl (part of openafs+rxk5) can do either mode; so the code
> complexity for either (or even both ways) is no big deal.

I understand.  Counter modes tend to have similar properties, and are
easier to layer atop crypto hardware that provide ECB mode (but not all
do).

> For large sized data elements, with hardware that wants to do straight
> CBC and/or a hardware/software implementation that can't do some form of
> reasonably efficient scatter/gather I/O, CTS is more of a handicap.
> And, of course, CTS takes a lot more explaining.  I think those are its
> largest drawbacks.  :-)

Exactly.  Two trips to a hardware crypto accelerator are going to be a
lot slower than one, so one would like to implement the second (one
block) operation in software, but then you have to get things like the
Solaris kernel crypto API details right (actually, I think it might
currently do the right thing and do small operations [few blocks] in
software).

> > > OpenSolaris' krb5 crypto bits use the SCF, and the same source (MIT +
> > > CDDL licensed) (with #ifdef KERNELs all over) is used to build the  
> > > user-
> > > land and kernel-land bits of the GSS-API Kerberos V mechanism.  The
> > > kernel-land mechanism only includes the per-msg token functions and
> > > everything needed to make that work (i.e., the krb5 crypto framework),
> > > but none of the raw krb5 PDUs.
> 
> Sounds like there's more there than I thought, but might still need work on

Yes, all of the MIT krb5 RFC3961-like API is there in the kernel.

That would be private, but we're now making this API public in
user-land, and we might be able to make the same commitment for the
kernel side (or sign contracts for it).

> its own to make it useful or truely efficient.  The original krb5 gssapi
> work that MIT did used "raw" krb5 crypto and did its own variant confounder
> and checksum logic.  The current gssapi work should be using stock krb5 crypto.

The Solaris krb5 code tracks MIT krb5, currently at 1.4 in OpenSolaris.

> I'm not entirely sure what you mean by "krb5 PDU", but it has something that
> produces results equivalent to MIT's krb5_c_encrypt and krb5_c_make_checksum,
> that's a real good start on what rxk5 needs.  Does this support
> CKSUMTYPE_RSA_MD5 == 7 ?

I meant PDUs as defined inRFC4120, like KRB-PRIV and KRB-SAFE.

> > >
> > > http://docs.sun.com/app/docs/doc/816-4863
> > > http://opensolaris.org/os/community/security/projects/ef/
> > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/ 
> > > common/gssapi/mechs/krb5/
> 
> Gosh.  I have a copy of that code.  I see krb5_c_encrypt().  And, yes,
> "#ifdef KERNEL" around the string-to-key functions, and even
> CKSUMTYPE_RSA_MD5 .  Wow.  Looks a lot like MIT.  That means getting
> rxk5 to work with this could be nearly trivial.  Anyway, guess that
> answers my question.

Yes.

>                       I'm not sure this will exactly answer Jeff
> Altman's concern that it "not do des".  But I guess figuring out what
> goes into a "krb5_context" inside the kernel will start answering
> that.

Not "doing DES" is up to the caller with the krb5_c_encrypt() API and
friends.  And up to the administrator (who can disable 1DES providers
with cryptoadm(1M)).

> This is definitely way interesting.  There's a number of other rxk5
> issues that are going to occupy me for a bit before I can get to
> this, so it's possible Dale or somebody else will beat me to
> working on this.  Then again, this sounds like a fun project, so
> I'd certainly like to get to it (but that shouldn't stop anybody
> else from doing so first.)

You might want to talk to CITI about what bits of krb5 they have
in-kernel.  If you could assume the MIT krb5 crypto API then you could
code to that portably.

DO, DO use the OpenSolaris lists for any interface stability issues,
contracts, RFEs, to contribute code :) (e.g., if you need additional
bits of krb5 in the kernel and are willing to do that work), etcetera.

(I don't recall if OpenAFS has signed any contracts for VFS related
interfaces.)

DON'T use interfaces that aren't public without discussing contracts or
interface promotion first, unless you're willing to risk breaking on
update/patch.

Nico
--