Subject: Re: [kitten] GSS_GetMIC and iovs

From: Greg Hudson <[email-masked]>
Date: Mon, 02 Sep 2013 00:01:52 -0400

On 08/28/2013 06:03 PM, Luke Howard wrote:
> Unfortunately this interface doesn't exist.

We've had an independent request for it and were planning to try to
implement it for 1.12, though I'm not sure yet whether time will permit.

Do people have opinions among these options:

1. gss_wrap_iov can produce a MIC token using new constants in the iov list.

1a. A new buffer type (GSS_IOV_BUFFER_TYPE_MIC).  If the
iov list contains one or more DATA buffers and a MIC buffer, we do a MIC
computation and put it in the MIC buffer.  We could perhaps support
MICing and wrapping at the same time with this scheme, although that
might not be easy to implement.

2a. A new flag (GSS_IOV_BUFFER_FLAG_MIC_TOKEN).  If the iov list
contains a TRAILER|MIC_TOKEN buffer, then we do a MIC computation and
put it in the trailer (a header buffer is not needed or used).

2. New APIs gss_get_mic_iov, gss_get_mic_iov_length, and gss_verify_mic_iov.

2a. With a new buffer type for the MIC token as in 1a.

2b. Reusing an existing buffer type (like TRAILER).

2c. With the MIC token as a separate parameter from the iov list (so the
iov list just contains DATA buffers, and any other buffer types are
ignored).

---

From: Luke Howard <[email-masked]>
Date: Mon, 2 Sep 2013 14:09:27 +1000

Hi Greg,

I think these are all pretty reasonable proposals. I think I like 1a/2a.

2c I might avoid because there's an extra copy (although not a big deal really for a MIC).

Nico will probably have the most coherent arguments.

-- Luke

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Chris Newman <[email-masked]>
Date: Tue, 03 Sep 2013 11:26:47 -0700

I would recommend not adding any iovec-related APIs to a security 
interface. My experience with such APIs in real-world SSL usage is that 
they are a common source of serious and hard to diagnose bugs. These APIs 
tend to be rarely used interfaces so they get inadequate testing, code 
review and real-world use. I inherited and maintain code that made heavy 
use of iovecs and I'm busy removing them whenever I can. My experience is 
that the maintenance, complexity and associated negative security cost of 
these interfaces far exceeds any potential performance benefit.

		- Chris

--On September 2, 2013 0:01:52 -0400 Greg Hudson <[email-masked]> wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: "Matt W. Benjamin" <[email-masked]>
Date: Tue, 3 Sep 2013 15:18:59 -0400 (EDT)

Thanks Luke and Greg,

2a seems like a minor extension of the (not exported) interface in recent MITk5, which
might be an argument in its favor.

Matt

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel.  734-761-4689 
fax.  734-769-8938 
cel.  734-216-5309

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Sep 2013 15:17:03 -0500

> I think these are all pretty reasonable proposals. I think I like 1a/2a.

Me too.  If we were only just designing gss_wrap_iov() I'd rather have
new functions for MICs instead, but as it is I think this will do, but
first we should think about ABI issues: it's not uncommon to use LD_*
env vars to force a GSS application to use a different libgss (I've
seen it done numerous times).  And some apps just do this as a matter
of course (e.g., the JGSS JNI shim, PuTTY, and probably others).

Thinking of ABI safety I would rather have new functions.  Otherwise
if we think existing gss_[un]wrap_iov() implementations will fail safe
when faced with new buffer types then I'll be fine with that approach.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Sep 2013 15:19:46 -0500

On Tue, Sep 3, 2013 at 1:26 PM, Chris Newman <[email-masked]> wrote:
> I would recommend not adding any iovec-related APIs to a security interface.
> My experience with such APIs in real-world SSL usage is that they are a
> common source of serious and hard to diagnose bugs. These APIs tend to be
> rarely used interfaces so they get inadequate testing, code review and
> real-world use. I inherited and maintain code that made heavy use of iovecs
> and I'm busy removing them whenever I can. My experience is that the
> maintenance, complexity and associated negative security cost of these
> interfaces far exceeds any potential performance benefit.

But there really are apps that care about performance...  NFS (the app
in question here, via RPCSEC_GSS) is one such app.

Mind you, RPCSEC_GSS if a bit of a performance disaster anyways
because it requires two per-message token function calls per-RPC (when
protecting the data, not just the RPC header), and should be re-done
(maybe) so it at most does one GSS per-message token call per-RPC.
But that wouldn't make RPCSEC_GSS not need iovec GSS calls.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Thu, 19 Sep 2013 00:24:56 -0400

> I think these are all pretty reasonable proposals. I think I like 1a/2a.

I went with 2a.  The new interfaces are:

     #define GSS_IOV_BUFFER_TYPE_MIC_TOKEN 12

     OM_uint32 gss_get_mic_iov(OM_uint32 *minor_status, 

                               gss_ctx_id_t context_handle, 

                               gss_qop_t qop_req, 

                               gss_iov_buffer_desc *iov, 

                               int iov_count); 

     OM_uint32 gss_get_mic_iov_length(OM_uint32 *minor_status, 

                                      gss_ctx_id_t context_handle, 

                                      gss_qop_t qop_req, 

                                      gss_iov_buffer_desc *iov, 

                                      iov_count); 

     OM_uint32 gss_verify_mic_iov(OM_uint32 *minor_status, 

                                  gss_ctx_id_t context_handle, 

                                  gss_qop_t *qop_state, 

                                  gss_iov_buffer_desc *iov, 

                                  int iov_count); 

DATA and SIGN_ONLY buffers are signed, with the token going into the 
MIC_TOKEN buffer.  As usual, we use the __stdcall convention on Windows.

---

From: Luke Howard <[email-masked]>
Date: Thu, 19 Sep 2013 14:46:32 +1000

Great. I look forward to adding support for this to Moonshot and gss_browserid. Should be able to do that in early October.

-- Luke

On 19/09/2013, at 2:24 PM, Greg Hudson <[email-masked]> wrote:

> DATA and SIGN_ONLY buffers are signed, with the token going into the MIC_TOKEN buffer.  As usual, we use the __stdcall convention on Windows.
>

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Sep 2013 06:57:41 +0200 (CEST)

> MIC_TOKEN buffer.  As usual, we use the __stdcall convention on Windows.

__stdcall is specific to 32-bit (x86), it does not exist on 64-bit (x64).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 19 Sep 2013 07:08:27 +0200 (CEST)

> __stdcall is specific to 32-bit (x86), it does not exist on 64-bit (x64).

Btw. Windows' own type for the purpose of attaching calling conventions
to system function (typically DLL exports) is "WINAPI", defined in windef.h

-Martin