From: "J. Bruce Fields" <bfields@fieldses.org>
To: Kevin Coffman <kwc@citi.umich.edu>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>, linux-nfs@vger.kernel.org
Subject: Re: [enctypes round 2: PATCH 05/26] rpc: gss: Add oid values to the gss_api mechanism structures
Date: Mon, 5 May 2008 11:22:51 -0400 [thread overview]
Message-ID: <20080505152251.GD8259@fieldses.org> (raw)
In-Reply-To: <4d569c330805050728yf7040f3lb55bc08d4046e85e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, May 05, 2008 at 10:28:18AM -0400, Kevin Coffman wrote:
> On Fri, May 2, 2008 at 5:39 PM, Trond Myklebust
> <trond.myklebust@fys.uio.no> wrote:
> >
> > On Fri, 2008-05-02 at 17:36 -0400, J. Bruce Fields wrote:
> > > On Wed, Apr 30, 2008 at 12:46:14PM -0400, Kevin Coffman wrote:
> > > > From: Usha Ketineni <uketinen@us.ibm.com>
> > > >
> > > > On NFSV4 server side, these are required as part of the security
> > > > triple(oid,qop,service) information being sent in the response of the
> > > > SECINFO operation.
> > >
> > > Remind me why me need to do this?
>
> The new downcall interface does not include the OID, so a static copy
> is eventually needed.
Before the patch you can get e.g. the krb5 oid from
gss_kerberos_mech->gm_oid; afterwards it's also available as krb5_oid.
If anything the former seems more useful to the downcall code, as it can
be used without requiring some particular knowledge of the krb5 code (it
only needs to know the gss-level gss_api_mech structure).
I have a feeling this patch is just a relic from a time before we had
any oid's here at all?
--b.
> I agree this description doesn't indicate that.
> This was one of the encryption patches I started with. Not an
> excuse, though.
>
> > ...and why we need to let NFSd have intimate knowledge of the gss_api
> > mechanism structures. It would be _very_ nice to wrap all this up into
> > some helper at the SUNRPC level with no dependencies on the RPCSEC_GSS
> > code.
>
> Agreed. Should we have a generic definition for an OID structure, or
> continue to use xdr_netobj? (It is generally assumed in GSS-API that
> upper-level software is aware of the OID structure.)
>
> The gssapi spec (rfc2744) defines an oid as:
>
> typedef struct gss_OID_desc_struct {
> OM_uint32 length;
> void *elements;
> } gss_OID_desc, *gss_OID;
>
> So a kernel definition might look like:
>
> struct gss_oid {
> u32 length;
> void *data; /* or keep the name "elements" */
> };
>
> So the new interface would look something like one of the following?
>
> int gss_mech_get_oid(struct gss_api_mech *gm, struct xdr_netobj **oid);
>
> or
>
> int gss_mech_get_oid(struct gss_api_mech *gm, struct gss_oid **oid);
next prev parent reply other threads:[~2008-05-05 15:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-30 16:45 [enctypes round 2: PATCH 00/26] Implement more encryption for gss_krb5 Kevin Coffman
[not found] ` <20080430164306.16010.44650.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-04-30 16:45 ` [enctypes round 2: PATCH 01/26] gss_krb5: create a define for token header size and clean up ptr location Kevin Coffman
[not found] ` <20080430164553.16010.32928.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-05-02 20:15 ` J. Bruce Fields
2008-04-30 16:45 ` [enctypes round 2: PATCH 02/26] gss_krb5: move gss_krb5_crypto into the krb5 module Kevin Coffman
[not found] ` <20080430164558.16010.1610.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-05-02 20:15 ` J. Bruce Fields
2008-04-30 16:46 ` [enctypes round 2: PATCH 03/26] rpcauth: update and document available space in xdr_buf when doing privacy Kevin Coffman
[not found] ` <20080430164603.16010.25894.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-05-02 21:28 ` J. Bruce Fields
2008-04-30 16:46 ` [enctypes round 2: PATCH 04/26] gss_krb5: Use random value to initialize confounder Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 05/26] rpc: gss: Add oid values to the gss_api mechanism structures Kevin Coffman
[not found] ` <20080430164613.16010.22760.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2008-05-02 21:36 ` J. Bruce Fields
2008-05-02 21:39 ` Trond Myklebust
[not found] ` <1209764379.26234.11.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-05-05 14:28 ` Kevin Coffman
[not found] ` <4d569c330805050728yf7040f3lb55bc08d4046e85e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-05-05 15:22 ` J. Bruce Fields [this message]
2008-04-30 16:46 ` [enctypes round 2: PATCH 06/26] Don't expect blocksize to always be 8 when calculating padding Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 07/26] gss_krb5: split up functions in preparation of adding new enctypes Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 08/26] gss_krb5: prepare for new context format Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 09/26] gss_krb5: introduce encryption type framework Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 10/26] gss_krb5: add ability to have a keyed checksum (hmac) Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 11/26] gss_krb5: import functionality to derive keys into the kernel Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 12/26] gss_krb5: use a global static OID value for krb5 Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 13/26] gss_krb5: handle new context format from gssd Kevin Coffman
2008-04-30 16:46 ` [enctypes round 2: PATCH 14/26] gss_krb5: add support for triple-des encryption Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 15/26] Add new pipefs file indicating which Kerberos enctypes the kernel supports Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 16/26] gss_krb5: add DES3 to the list of supported enctypes Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 17/26] sunrpc: Export function write_bytes_to_xdr_buf Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 18/26] gss_krb5: add support for new token formats in rfc4121 Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 19/26] gss_krb5: add remaining pieces to enable AES encryption support Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 20/26] gss_krb5: add AES to the list of supported enctypes Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 21/26] gss_krb5: add a usage parameter to the make_checksum function Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 22/26] gss_krb5: add "raw" session key to context to be used for deriving keys Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 23/26] gss_krb5: pass struct krb5_ctx pointer to sequence number functions Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 24/26] gss_krb5: add confounder length to kerberos enctype framework Kevin Coffman
2008-04-30 16:47 ` [enctypes round 2: PATCH 25/26] gss_krb5: Add support for rc4-hmac encryption type described in rfc4757 Kevin Coffman
2008-04-30 16:48 ` [enctypes round 2: PATCH 26/26] gss_krb5: add RC4 to the list of supported enctypes Kevin Coffman
2008-05-02 21:38 ` [enctypes round 2: PATCH 00/26] Implement more encryption for gss_krb5 J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080505152251.GD8259@fieldses.org \
--to=bfields@fieldses.org \
--cc=kwc@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox