[OpenAFS-devel] Re: configurable cryptosystem support

[Nicolas Williams]

On Thu, Jan 25, 2007 at 02:56:18AM -0500, Marcus Watts wrote:
> 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.

Well, Solaris only needs the GSS per-msg token functions in the kernel,
and those don't have anything to do with any RFC4120 PDU, thus no need
to have those functions, nor any of the ASN.1 encoder in the kernel.

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

I'm not up on all those details.  RTFS?  Ask on an OpenSolaris list?

> Does "krb5_c_valid_enctype" exist (I don't see it...?)

The Solaris krb5 code right now isn't aware of what algorithms are
enabled/disabled.  Because the negotiation of enctypes used between a
client and a server happens in the TGS exchange between the client and
the TGS it's hard to make local algorithm availability decisions on a
server without breaking things.

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

Here's the output of nm(1) on the Solaris kernel krb5 module (which,
BTW, does NOT mean these functions are exported interfaces):

% nm /kernel/misc/kgss/kmech_krb5|grep GLOB|grep -v UNDEF|cut -d\| -f8|grep ^krb5_
krb5_arcfour_decrypt
krb5_arcfour_encrypt
krb5_arcfour_encrypt_length
krb5_c_block_size
krb5_c_checksum_length
krb5_c_decrypt
krb5_c_encrypt
krb5_c_encrypt_length
krb5_c_make_checksum
krb5_c_random_make_octets
krb5_c_verify_checksum
krb5_cksumtypes_length
krb5_cksumtypes_list
krb5_copy_keyblock
krb5_copy_keyblock_data
krb5_create_derived_keyblock
krb5_crypto_us_timeofday
krb5_derive_key
krb5_dk_decrypt
krb5_dk_encrypt
krb5_dk_encrypt_length
krb5_dk_make_checksum
krb5_enc_des
krb5_enc_des3
krb5_enctypes_length
krb5_enctypes_list
krb5_externalize_data
krb5_externalize_opaque
krb5_find_serializer
krb5_free_address
krb5_free_authdata
krb5_free_authenticator
krb5_free_authenticator_contents
krb5_free_checksum
krb5_free_checksum_contents
krb5_free_context
krb5_free_data_contents
krb5_free_error
krb5_free_keyblock
krb5_free_keyblock_contents
krb5_free_principal
krb5_get_time_offsets
krb5_gss_delete_sec_context
krb5_gss_delete_sec_context_no_lock
krb5_gss_get_context
krb5_gss_get_mic
krb5_gss_import_sec_context
krb5_gss_oid_array
krb5_gss_seal
krb5_gss_sign
krb5_gss_unseal
krb5_gss_unwrap
krb5_gss_verify
krb5_gss_verify_mic
krb5_gss_wrap
krb5_gss_wrap_size_limit
krb5_hash_crc32
krb5_hash_sha1
krb5_hmac
krb5_init_context
krb5_init_ef_handle
krb5_init_secure_context
krb5_internalize_opaque
krb5_keyhash_descbc
krb5_keyhash_md5des
krb5_log
krb5_mutex
krb5_nfold
krb5_old_decrypt
krb5_old_encrypt
krb5_old_encrypt_length
krb5_os_free_context
krb5_os_init_context
krb5_parse_name
krb5_raw_decrypt
krb5_raw_encrypt
krb5_raw_encrypt_length
krb5_register_serializer
krb5_ser_address_init
krb5_ser_auth_context_init
krb5_ser_authdata_init
krb5_ser_authenticator_init
krb5_ser_checksum_init
krb5_ser_keyblock_init
krb5_ser_pack_bytes
krb5_ser_pack_int32
krb5_ser_pack_int64
krb5_ser_principal_init
krb5_ser_unpack_bytes
krb5_ser_unpack_int32
krb5_ser_unpack_int64
krb5_set_debugging_time
krb5_set_real_time
krb5_set_time_offsets
krb5_size_opaque
krb5_timeofday
krb5_unparse_name
krb5_unparse_name_ext
krb5_use_natural_time
% 

And local symbols:

krb5_address_externalize
krb5_address_internalize
krb5_address_ser_entry
krb5_address_size
krb5_auth_context_externalize
krb5_auth_context_internalize
krb5_auth_context_ser_entry
krb5_auth_context_size
krb5_authdata_externalize
krb5_authdata_internalize
krb5_authdata_ser_entry
krb5_authdata_size
krb5_authenticator_externalize
krb5_authenticator_internalize
krb5_authenticator_ser_entry
krb5_authenticator_size
krb5_checksum_esize
krb5_checksum_externalize
krb5_checksum_internalize
krb5_checksum_ser_entry
krb5_dk_decrypt_maybe_trunc_hmac
krb5_fini_code
krb5_keyblock_externalize
krb5_keyblock_internalize
krb5_keyblock_ser_entry
krb5_keyblock_size
krb5_mechanism
krb5_principal_externalize
krb5_principal_internalize
krb5_principal_ser_entry
krb5_principal_size

Clearly we should rationalize this if we want to open/contract any part
of the krb5 API in the kernel.

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

Seems reasonable, and yes, a heads up to the relevant communities would
be nice.

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

No actual signatures are needed in the physical sense.  An interface
contract is signed by e-mail, and the legal metaphor only goes so far.

Nico
--