[OpenAFS-devel] Re: configurable cryptosystem support

[Marcus Watts]

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.

...
> > 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.

> >
> > 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.

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.  :-)

> >
> > 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
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.
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 ?

> >
> > 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.  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.

> >
> > If you need more info feel free to ask on security- 
> > discuss@opensolaris.org.
> >
> > Cheers,
> >
> > Nico
> > -- 
> 
> 
> --
> Dale Ghent
> UNIX Systems Specialist
> UMBC - Office of Information Technology
> ECS 201 - x51705

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.)

					-Marcus