[OpenAFS-devel] Re: configurable cryptosystem support

[Marcus Watts]

Nicolas Williams <Nicolas.Williams@sun.com> writes:
...
> > 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.

rxk5 intentionally does not use those, because that requires asn.1
which ups kernel code requirements.  Sounds like the solaris folks
made a very similar decision.

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

Ah.  How does kernel code determine if that's enabled at runtime?
Does "krb5_c_valid_enctype" exist (I don't see it...?)

Here's a more complete list of what rxk5 currently uses in the kernel
(as provided by k5ssl):
	krb5_c_block_size		    krb5_c_valid_cksumtype
	krb5_c_checksum_length		    krb5_c_verify_checksum
	krb5_c_decrypt			    krb5_copy_keyblock_contents
	krb5_c_encrypt			    krb5_free_checksum_contents
	krb5_c_encrypt			    krb5_free_creds
	krb5_c_encrypt_length		    krb5_free_keyblock_contents
	krb5_c_is_coll_proof_cksum          krb5_init_context
	krb5_c_is_keyed_cksum	    	    krb5_parse_name
	krb5_c_make_checksum		    krb5_unparse_name
	krb5_c_make_random_key		    krb5i_iterate_enctypes [1]
	krb5_c_random_make_octets	    krb5i_nfold		   [2]
	krb5_c_random_os_entropy

[1] this is used to see what encryption types are available.
	PGetCapabilities -- which in turn gets used by aklog &etc.
[2] used because rfc 3961 "prf" support wasn't readily available.
	This is basically mit's krb5_nfold except with byte sizes.

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

I've talked very briefly with CITI on this & looked at (probably old)
source that they had.  We'll need to talk more.  They have better linux
specific crypto support, but support fewer crypto types.

rxk5 has code for 2.5 k5 api's: heimdal+mit(+shishi).  k5ssl intentionally
looks nearly but not exactly like mit.  heimdal looks enough like mit
to occasionally work with (nearly) the same code.

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

I think for any initial work, I'll take that risk.  Things look close
enough that this may not be any big deal.  Once I have something that
works (ie, I know what I need) then I (or someone) can formalize that list
(or work out alternatives if what I used wasn't acceptable.)
I suppose it would be kind to let them know this is coming first.

I don't know anything about VFS related interface contracts.  Dale
might know more, I believe he was working to come up with a list of
things that needed either contracts or replacements.  I am vaguely
curious as to whether you want actual signatures from somebody.

> 
> Nico
> -- 
> 

				-Marcus