Proposal to export gssapi context

[Ken Raeburn]

(Sorry for the delay in my reviewing this.)

"Kevin Coffman" <kwc at citi.umich.edu> writes:
> /*
>  * krb5_gss-set_allowable_enctypes can be called after
>  * gss_acquire_cred(), but before gss_init_sec_context(),
>  * to restrict the set of enctypes which will be negotiated
>  * to those in the provided array.
>  */
> OM_uint32
> krb5_gss_set_allowable_enctypes(OM_uint32 *minor_status, 
> 				gss_cred_id_t cred,
> 				int num_ktypes,
> 				krb5_enctype *ktypes);

1) Is "cred" allowed to be GSS_C_NO_CREDENTIAL?  If so, what does that
   mean?

2) I assume it applies whether the credentials in question are used as
   initiator or acceptor, and thus could make init_sec_context or
   accept_sec_context fail?

3) Which keys does it actually apply to?

   If the client Kerberos code has some knowledge about the server
   implementation, it could (at least in theory) choose a subkey type
   supported by the kernel code while the session key and long-term
   server key are both stronger types not in the list supported by the
   kernel.  The specification of this function should indicate whether
   that is permitted.

   If the session key type is not in the list specified with
   set_allowable_enctypes on the acceptor side, but the subkey is in
   the list, is that okay or should the session be rejected?

   (Perhaps the right answer is "any keys that will be needed after
   the security context has been established"?)

> typedef struct gss_krb5_lucid_context {
> 	OM_int32	version;	/* Structure version number */
> 	OM_int32	initiate;	/* Are we the initiator? */
> 	int		sign_alg;	/* signing algorthm */
> 	int		seal_alg;	/* seal/encrypt algorthm */
> 	OM_int32	endtime;	/* expiration time of context */
> 	OM_uint64 (?)	sequence;	/* local (sender) sequence number */
> 	gss_OID		mech_used;	/* Mechanism */	
> 	gss_krb5_lucid_key_t	enc_key;	/* Encrypting key info */
> 	gss_krb5_lucid_key_t	seq_key;	/* Subkey info */
>
> 	/*
> 	 * The following are added in the MIT 1.3.2 code for CFX,
> 	 * I assume we'll want/need them eventually
> 	 */
>
> 	OM_int32	protocol;
> 			/* 0 = rfc1964, 1 = draft-ietf-krb-wg-gssapi-cfx-01 */
> 	OM_int32	cksumtype;	/* "main" subkey checksum type */
> 	gss_krb5_lucid_key_t	acceptor_subkey;
> 	OM_int32	acceptor_subkey_cksumtype;	
> } gss_krb5_lucid_context_t;

Looks like you've copied some sloppiness from the MIT code. :-)
If protocol == 0, sign_alg and seal_alg matter but the subkey stuff
does not.  If protocol == 1, the reverse is true.

A union would be more compact, and wouldn't require filling in fields
that have no meaning.  (In other words, a discriminated union with
'protocol' as the discriminant.)

Otherwise, it should be specified whether, for example,
acceptor_subkey needs to be filled in with some magic value or if its
fields may be garbage, in the case where protocol is 0 and thus
acceptor_subkey is supposed to be irrelevant.

Ken