>>>>> "kwc" == Kevin Coffman <kwc@citi.umich.edu> writes:
kwc> Brought to krbdev...
kwc> The kernel implementation of rpcsec_gss used for NFSv4 requires context
kwc> information be negotiated in user-land and then passed down for use in the
kwc> kernel. gss_export_context() exports the context as an opaque object which
kwc> cannot be used for this purpose. We are proposing three new APIs. One is
kwc> to restrict the encryption types negotiated in user-land to the set that the
kwc> kernel can use. The other two are to export context information into a
kwc> usable structure, and then free that structure.
kwc> Comments, suggestions, welcome.
#define GSS_C_LUCID_CONTEXT_CURRENT_VERSION GSS_C_LUCID_CONTEXT_VERSION_1
I don't think having a macro for the current version in a public
header is a good idea. People might use it and failing to think of a
way of using it that would be correct.
typedef struct gss_krb5_lucid_context {
The version number should be in the structure name.
It seems like you actually only need two keys: the context key and the
server subkey. You can determine the sequence key from the context
key. As Ken pointed out you don't need both enctypes and keys; the
key contains the enctype.
Presumably the return from krb5_gss_export_lucid_context should be a
void * and cast by the caller after looking at the version numbers.
--Sam
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev