Re: Proposal to export gssapi context

[Kevin Coffman <kwc@citi.umich.edu>]

> Ken Raeburn <raeburn@MIT.EDU> writes:
>
> (Sorry for the delay in my reviewing this.)


Sorry for my delay in my responding.


> > "Kevin Coffman" <kwc@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?

I don't think it should be allowed.  We're assuming that cred is
what is returned from acquire_cred and I don't think GSS_C_NO_CREDENTAIL
is a valid (successful) return from acquire_cred, correct?

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

Yes.

> 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"?)

Yes, I think this is the right answer.  

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

Agreed.  I'll make some changes as suggested and re-send a new version.

Meanwhile, I don't see any 64-bit data types defined for gssapi.
We should define one for the sequence number?
  
> 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