Re: [Kevin Coffman] Proposal to export gssapi context

[Love <lha@stacken.kth.se>]

Sam Hartman <hartmans@mit.edu> writes:

> Umich has approached MIT asking for a private API for their in-kernel
> GSSAPI implementation to use.
>
> Ideally we'd like to get to a point where Heimdal could implement the
> same API.
>
> As such we're seeking comments from the Heimdal community.
>
>
> From: "Kevin Coffman" <kwc@citi.umich.edu>
> Subject: Proposal to export gssapi context
> To: <krbdev@mit.edu>
> Cc: nfsv4-wg@citi.umich.edu
> Date: Tue, 9 Mar 2004 18:00:42 -0500
> X-Mailer: Microsoft Outlook, Build 10.0.4510
> X-Spam-Level: 
>
> Brought to krbdev...

And by Sam Hartmans to heimdal-discuss...

> The kernel implementation of rpcsec_gss used for NFSv4 requires context
> information be negotiated in user-land and then passed down for use in the
> kernel.  gss_export_context() exports the context as an opaque object which
> cannot be used for this purpose.  We are proposing three new APIs.  One is
> to restrict the encryption types negotiated in user-land to the set that the
> kernel can use.  The other two are to export context information into a
> usable structure, and then free that structure.
>
> Comments, suggestions, welcome.

I read this over real quick on the train and will surely have more comments
when I try to implement it.

Why is cksumtype and acceptor_subkey_cksumtype included, they are implied
by the key's enctype.

Is this really not kerberos specific ? Then why send oid ?

What is the format of sign_alg/seal_alg ? They are defined as octet data in
rfc1964 not integers.

How will you deal with SPKM/LIPKEY ? Have anyone updated the spec so its
possible to implement now ?

Love

PGP signature