On Thu, Jan 25, 2007 at 02:56:18AM -0500, Marcus Watts wrote: > Nicolas Williams <[EMAIL PROTECTED]> 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 -- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
