Subject: [kitten] I-D documenting the structure of the GSS negotiation loop

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Oct 2013 14:52:24 -0400 (EDT)

Hi all,

I asked Nico for review of a draft which included (among other things) a 
description of the structure of the GSS negotiation loop.  Part of the 
comments I received were that it would be nice to have a separate document 
that anyone writing a protocol spec using the GSS-API could refer to 
(instead of having to document the loop for each application protocol). 
So, here's the -00 version of such a document.  Comments welcome!

-Ben

On Mon, 21 Oct 2013, [email-masked] wrote:

>
> A new version of I-D, draft-kaduk-kitten-gss-loop-00.txt
> has been successfully submitted by Benjamin Kaduk and posted to the
> IETF repository.
>
> Filename:	 draft-kaduk-kitten-gss-loop
> Revision:	 00
> Title:		 Structure of the GSS Negotiation Loop
> Creation date:	 2013-10-21
> Group:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-kaduk-kitten-gss-loop-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-kaduk-kitten-gss-loop
> Htmlized:        http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00
>
>
> Abstract:
>   This document specifies the generic structure of the negotiation loop
>   to establish a GSS security context between initiator and acceptor.
>   The control flow of the loop is indicated for both parties, including
>   error conditions, and indications are given for where application-
>   specific behavior must be specified.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>

---

From: Greg Hudson <[email-masked]>
Date: Mon, 28 Oct 2013 13:03:13 -0400

Here are a couple of issues Ben and I discussed before the draft was
submitted, which Ben thought we could use list input on:

1. Overlap with 2743

It wasn't immediately clear to me whether this draft is a distillation
of RFC 2743 or whether it imposes new requirements.  I think there might
be some new requirements (like "The initiator MUST NOT change any of the
input parameters to GSS_Init_sec_context() between calls", while 2743
only mentions the claimant_cred_handle parameter), but they aren't
differentiated from repeated requirements.

2. Handling of impossible situations

Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI
returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty
output token.  This is a nonsense answer from the GSS implementation,
indicative of a serious bug, and I don't think a spec like this needs to
describe what applications should do in the face of bugs.  I think most
applications I have seen will just send an empty token to the other
side, which will reject it, and that's not a problem.

3. Example code

The draft is written completely at the RFC 2743 level, independent of
language bindings.  I was sort of expecting a draft like this to have
example code using the C bindings.  There is already example code for
gss_init_sec_context and gss_accept_sec_context in RFC 2744, but it
could perhaps be improved to cover some of the statements in the draft,
like checking ret_flags after the context is established.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 28 Oct 2013 13:37:03 -0400

> side, which will reject it, and that's not a problem.

Just FYI:
The NTLM mechanism can do this (empty token) in "connectionless mode",
and it is not a bug, the server will not reject it, but create an
appropriate reply token.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Oct 2013 12:40:26 -0500

On Mon, Oct 21, 2013 at 02:52:24PM -0400, Benjamin Kaduk wrote:
> I asked Nico for review of a draft which included (among other
> things) a description of the structure of the GSS negotiation loop.
> Part of the comments I received were that it would be nice to have a
> separate document that anyone writing a protocol spec using the
> GSS-API could refer to (instead of having to document the loop for
> each application protocol). So, here's the -00 version of such a
> document.  Comments welcome!

Thanks for doing this!

> >Htmlized:        http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00

I'll review later today in detail.  I think pseudo-code would be nice to
have.  I don't mind if it's synchronous-looking pesudo-code: between
threadlets (the JavaScript literature is filled to the brim, and long
ago spilled, with libraries along these lines) and such, and programmers
who know how to turn synchronous code into async code, I don't think
that's a problem.  I realize that normative text is also desirable, but
we already have it: in RFC2743.  So for an informative I-D I think
pseudo-code would be very good to have, and since we have C code in
RFC2744, it shouldn't be difficult to adapt.

Also, given that we have consensus for the channel-bound flag extension
that introduces a stepper model, I think we'll need to do this again...

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 28 Oct 2013 13:56:13 -0400

> and it is not a bug, the server will not reject it, but create an

That violates RFC 2744, although 2743 doesn't say anything about it that
I can find.  See the description of output_token in RFC 2744 section 5.1
(in the free-form text, the example code, and the parameter list) and
section 5.19.

Note that for a GSS_S_COMPLETE result, the emptiness or non-emptiness of
output_token indicates whether there is a token to be sent, and there is
no other way for an application to know.  For a GSS_S_CONTINUE_NEEDED
result, an application could assume that the token must always be
sent(*), but RFC 2744 doesn't tell applications to do so and doesn't do
so in its own example code.

(*) Actually, while I have always made the assumption that mech tokens
must alternate between initiator and acceptor, I'm not sure whether that
requirement is written down anywhere.

---

From: Simo Sorce <[email-masked]>
Date: Mon, 28 Oct 2013 14:07:30 -0400

> requirement is written down anywhere.

In NTLMSSP this happens only in the first initiate in the client, and
GSS_S_CONTINUE_NEEDED is returned. It is never the case if
GSS_S_COMPLETE is returned of course.

Simo.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 28 Oct 2013 14:09:23 -0400

> requirement is written down anywhere.

It effectively is -- once you call gss_init_sec_context, in order to get
the input token for the next call, someone must call
gss_accept_sec_context, and vice versa.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Oct 2013 13:25:44 -0500

> requirement is written down anywhere.

I'm certain that either it is or it's strongly implied.  There's
PROT_READY as well, but that factors out in prose.  That is, the
exchange of security context tokens absolutely must be synchronous,
first one from the initiator, then one from the acceptor, then back to
the initiator, and so on until complete or failure.

Per-message tokens may be produced/consumed before full security context
establishment if the security context is PROT_READY before it is
established, and these are not required to be exchanged synchronously.
But in that case the remaining security context tokens needed to get to
fully-established (or failure) state must be exchange synchronously
nonetheless.  And any security context token must be consumed before
per-msg tokens produced *after* producing the same security context
token.

Zero-length tokens are not allowed and/or they are indistinguishable
from absent tokens (depending on the bindings).

Zero-length inputs to GSS_Wrap() and GSS_GetMIC(), and zero-length
outputs from GSS_Unwrap(), *are* allowed, but these aren't tokens.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Oct 2013 13:28:35 -0500

> (in the free-form text, the example code, and the parameter list) and

Note that NTLMSSP is not a standard GSS-API mechanism anyways (e.g., it
lacks the ASN.1 mechanism OID header on the initial context token).

But we might need to make allowance for such mechanisms.  In particular
we might need to allow for an empty (or constant) initial security
context token in the case that the mechanism is an adaptation of -say- a
SASL server-goes-first mechanism.

Ben's I-D should point this out.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Mon, 28 Oct 2013 20:10:47 +0100 (CET)

> lacks the ASN.1 mechanism OID header on the initial context token).

Keep in mind that the generic framing is a requirement for
the initial context token.  So it is incompatible with GSS-API to have
an empty context token emitted by the first call to gss_init_sec_context().

> SASL server-goes-first mechanism.

I don't think that this makes an argument for having gss_init_sec_context
emit an empty token on first call.  Asking whether gss_accept_sec_context
should be permitted to not fail when no token is supplied in the first
iteration call looks like a different question to me.

For a gssapi mechanism that starts the handshake on the initiator side,
defining an initial context token intitiator->acceptor hat has the
generic framing should always be possible, even if there is no
substantial mechanism data inside, and the primary purpose is to
pass the ball to the acceptor.

SPNEGO will also likely be unable to deal with a zero-length initial
token from gss_init_sec_context() (and recognizing whether there is
an optimistic token present).

-Martin