Subject: GSS-API extensions for AEAD

From: Luke Howard <[email-masked]>
Date: Sat, 11 Sep 2004 17:10:21 +1000

We need to support AEAD in GSS-API in order to interoperate with some
vendor implementations of DCE RPC.

I've extended our GSS-API implementation, which is based on Heimdal,
to add the GSS_Unwrap_Ex() and GSS_Wrap_Ex() APIs. The C bindings are
as follows:

/*
 * GSS_Unwrap() with support for associated data.
 *
 * Notes:
 *
 *	token_header_buffer contains the GSS-API token as
 *	received from the peer
 *
 *	associated_data_buffer contains the complete data
 *	over which the checksum is to be verified;
 *
 *	input_message_buffer contains the complete data to
 *	be decrypted if confidentiality was requested;
 *
 *	input_message_buffer value must point into the value
 *	of associated_data_buffer (hence input_message_buffer
 *	just specifies a span within associated_data_buffer).
 *
 *	On returning GSS_S_COMPLETE, output_message_buffer
 *	will contain input_message_buffer after unwrapping and;
 *
 *	associated_data_buffer will have been authenticated
 *
 */
OM_uint32 gss_unwrap_ex(OM_uint32 *minor_status,
			const gss_ctx_id_t context_handle,
			const gss_buffer_t token_header_buffer,
			const gss_buffer_t associated_data_buffer,
			const gss_buffer_t input_message_buffer,
			gss_buffer_t output_message_buffer,
			int *conf_state,
			gss_qop_t *qop_state);

/*
 * GSS_Wrap() with support for associated data.
 *
 * Notes:
 *
 *	associated_data_buffer contains the complete data
 *	over which the checksum is to be verified;
 *
 *	input_message_buffer contains the data to be
 *	encrypted if conf_req_flag == TRUE.
 *
 *	On returning GSS_S_COMPLETE, output_token_buffer
 *	will contain the GSS-API tokenheader, and;
 *
 *	output_message_buffer will contain input_message_buffer
 *	after wrapping (including any padding)
 */
OM_uint32 gss_wrap_ex(OM_uint32 *minor_status,
		      const gss_ctx_id_t context_handle,
		      int conf_req_flag,
		      gss_qop_t qop_req,
		      const gss_buffer_t associated_data_buffer,
		      const gss_buffer_t input_message_buffer,
		      int *conf_state,
		      gss_buffer_t output_token_buffer,
		      gss_buffer_t output_message_buffer);

Any comments? Worth writing this up as an Internet Draft?

-- Luke

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

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Sep 2004 12:57:18 -0400

So, you can't guarantee that a particular mechanism can support this.
Remember all the trouble we had designing CFX.  Remember also that CFX
isn't even guaranteed to support this; it only happens to work for
AES.

I would feel very uncomfortable inshrining this in a standard.

That said, I do completely understand the problem you're trying to
solve.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Sep 2004 17:12:31 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> So, you can't guarantee that a particular mechanism can
    Sam> support this.  Remember all the trouble we had designing CFX.
    Sam> Remember also that CFX isn't even guaranteed to support this;
    Sam> it only happens to work for AES.

I'm still uncomfortable with this but wouldn't mind agreeing to
consider the extension and specify if we believe it is a good idea
after consideration.

---

From: Luke Howard <[email-masked]>
Date: Sun, 12 Sep 2004 17:27:27 +1000

>That said, I do completely understand the problem you're trying to

Well, no harm documenting it as an individual submission -- will be
a little while until I have the spare cycles anyway.

-- Luke

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Sep 2004 19:56:29 +0200

> Any comments? Worth writing this up as an Internet Draft?

Yes, I believe so.

> So, you can't guarantee that a particular mechanism can support this.

I'm not sure I see how that is a problem.  Mechanisms that do not
support AEAD return an error.  That approach works for mechanisms
today, that don't implement the full API.

Thanks,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Sep 2004 12:24:56 -0500

> today, that don't implement the full API.

I don't think it's a problem to have this extension, even though it
would not be applicable to all mechanisms.

That said I don't feel much sympathy for this proposal as, though there
may be performance benefits to be had from it (encrypt-in-place) I
prefer channel bindings to anonymous IPsec[1] as a way to improve
performance.  Perhaps CIFS will gain support for doing so and so the
desire for this AEAD extensions to the GSS-API might go away, perhaps
not.  *shrug*

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Sep 2004 14:54:46 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Sat, Sep 11, 2004 at 07:56:29PM +0200, Simon Josefsson
    Nicolas> wrote:
    >> I'm not sure I see how that is a problem.  Mechanisms that do
    >> not support AEAD return an error.  That approach works for
    >> mechanisms today, that don't implement the full API.

    Nicolas> I don't think it's a problem to have this extension, even
    Nicolas> though it would not be applicable to all mechanisms.

True.  My concern is that people would want to use it with certain
mechanisms (krb5) that don't actually support it.

---

From: Luke Howard <[email-masked]>
Date: Tue, 14 Sep 2004 13:35:08 +1000

>desire for this AEAD extensions to the GSS-API might go away, perhaps

For the record, CIFS only uses GSS-API for authentication, so this
proposal is unrelated.

(CIFS does its own integrity protection and to my knowledge has no
support for privacy.)

-- Luke

--