Subject: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 14:25:43 -0600

I was looking at what it'd take to modify various HTTP client
libraries to support channel binding.  An issue comes up that has come
up before: migration is hard.  In effect we have to change the clients
to do CB first, then when we're done we must change the servers.

(Background: implementations of RFC4121 acceptors ignore initiator CB
data when the acceptor application provided no CB data.  The inverse
is not true: if the initiator provides no CB data and the acceptor
does then context establishment fails.)

This is ETOOHARD in many cases.  It's tempting to conclude that in
such cases the problem is that there's too many implementations to
modify, thus one may never finish at all -- and if one cannot finish
then there's no point to trying.  But I'm not so sure, and I think
that it'd be nice to have an upgrade path that doesn't require any
sort of flag day.

IF the GSS-API had had a ret_flag by which to indicate that both
parties provided CB data and CB succeeded, then we could have
negotiated CB more easily.  The idea is that if one peer did not
provide CB data then this flag would not be set, and if both provided
different CB data then context establishment would fail as today.
BUT, it's too late to introduce such a flag: applications don't know
to check for it.

What can we do to improve this?

Well, we could introduce such a flag but retain the traditional
behavior, with the new behavior being enabled only when additional
steps are taken (e.g., configuration, or perhaps a flag set on the
acceptor credential handle, or on a duplicate of GSS_C_NO_CREDENTIAL).

That's all I can think of.  Other alternatives?

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Feb 2013 22:01:42 +0100 (CET)

Nico Williams wrote:
> This is ETOOHARD in many cases.

I mentioned that interop problem with MIT Kerberos in Nov-2011:
  http://www.ietf.org/mail-archive/web/kitten/current/msg02838.html

Microsoft Kerberos does not seem to suffer from this problem.

Ignoring CB which only the initiator asserts but not ignoring CB
that only the acceptor asserts looks like an inconsistency and a bug to me.

Rfc2743 clearly says, that _only_ when both peers assert the same
type of channel bindings data, then gssapi mechanisms ought to
validate that data.  And even then, a mechanism implementation
may decide to not implement channel bindings and ignore CB data entirely
(without this being visible to the calling app, due to a lack
 of a respective context attribute flag).

   http://tools.ietf.org/html/rfc2743#page-16

   1.1.6:  Channel Bindings

   The GSS-API accommodates the concept of caller-provided channel
   binding ("chan_binding") information.  Channel bindings are used to
   strengthen the quality with which peer entity authentication is
   provided during context establishment, by limiting the scope within
   which an intercepted context establishment token can be reused by an
   attacker. Specifically, they enable GSS-API callers to bind the
   establishment of a security context to relevant characteristics
   (e.g., addresses, transformed representations of encryption keys) of
   the underlying communications channel, of protection mechanisms
   applied to that communications channel, and to application-specific
   data.

   The caller initiating a security context must determine the
   appropriate channel binding values to provide as input to the
*> GSS_Init_sec_context() call, and consistent values must be provided
*> to GSS_Accept_sec_context() by the context's target, in order for
*> both peers' GSS-API mechanisms to validate that received tokens
*> possess correct channel-related characteristics. Use or non-use of
   the GSS-API channel binding facility is a caller option.  GSS-API
   mechanisms can operate in an environment where NULL channel bindings
   are presented; mechanism implementors are encouraged, but not
   required, to make use of caller-provided channel binding data within
   their mechanisms. Callers should not assume that underlying
   mechanisms provide confidentiality protection for channel binding
   information.

>
> It's tempting to conclude that in

Implementations which do fail on the acceptor side for security
contexts where the initiator did not assert any channel bindings
are ignoring both, the underlying GSS-API specification, and the
ramifications of the implemented behaviour with respect to
migration from scenarios that do not use CB to the use of CB.

> What can we do to improve this?

Fix the server-side rfc1964 & rfc4121 implementations which got this wrong.

Maybe you could add a new gss_inquire_context_ex() call that returns
information about whether&which type of CB data the initiator asserted,
whether&which type of CB data the acceptor asserted, and whether
the CB data of initiator and acceptor was successfully validated.
 
For context attributes (input as well as output) it might be difficult
to distinguish whether a server is dealing with an old implementation
that does not recognize and ignore (on input) or not assert (on output)
that context attribute, or whether the client did not send CB data.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 15:22:19 -0600

>  of a respective context attribute flag).

Golly, you're right, RFC2743 (and RFC2744 does not correct) does imply
that CB are ignored when one party doesn't use them.  However, without
a return flag for indicating CB state this is uselessly broken:
there's no way to enforce a CB requirement!

If implementations had gotten that right then CB could never be added
to existing GSS applications!  And it'd be impossible to prevent
cut-and-paste attacks where a target principal is used for multiple
application protocols some of which use CB and some of which don't.

Hmm, this is a serious bug in the spec!  We must fix it.

> migration from scenarios that do not use CB to the use of CB.

See above.  It is not reasonable for acceptors to ignore initiator CB
without signalling this to the application.

> Fix the server-side rfc1964 & rfc4121 implementations which got this wrong.

That would break existing applications.

> the CB data of initiator and acceptor was successfully validated.

This is not acceptable; see above.

I'm writing an I-D that proposes the following solution:

 - add a GSS_C_CHANNEL_BOUND_FLAG as a ret_flag
 - standardize GSS_Set_cred_option()
 - specify a credential option for signalling that the application
understands the new flag
 - retain existing implementation behavior when the application does
not set this credential option

Separately, implementations might also provide an env. var. to enable
the new behavior.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Feb 2013 22:38:24 +0100 (CET)

Nico Williams wrote:
> Martin Rex <[email-masked]> wrote:
>>

GSS-API CB are uselessly broken is misleading.
GSS-API CB are useless is the correct determination.

If your app-level protocol correctly uses the message protection
facilities to protect all app-level communication, then GSS-API CB
are unnecessary.  If apps want to abuse a GSS-API context establishment
handshake as a substitute for an OTP scheme, thats where rfc4559 is
suddenly screaming for GSS-API CB...

> Hmm, this is a serious bug in the spec!  We must fix it.

It's simply a feature that never existed.

I'll note, however, that the description of Channel Bindings in GSS-API v1
(rfc1508) is much less clear about the desired behaviour, and rfc1964
may be have inherited the ambiguity (and the lack of conveying the
type of CB that was assert) from the GSS-API v1 spec.

-Martin

---

From: Luke Howard <[email-masked]>
Date: Tue, 12 Feb 2013 08:42:03 +1100

Windows has ASC_REQ_ALLOW_MISSING_BINDINGS / ASC_REQ_PROXY_BINDINGS (although the documentation says that this is only for HTTP Digest, note the documentation is often wrong).

GSS doesn't have acceptor input flags as you point out.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 15:43:29 -0600

> suddenly screaming for GSS-API CB...

Thanks Martin, but that's not a useful answer.  Anyone else?

I will submit an I-D later today.

> It's simply a feature that never existed.

Well, no, it did exist in RFC2744, and it was used back when people
used IP addresses for channel binding (*that* was useless).

> type of CB that was assert) from the GSS-API v1 spec.

OK, this is useful: we'll call it a bug in the spec and fix it.  Thanks Martin.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 22:51:48 -0600

I've submitted http://www.ietf.org/id/draft-williams-kitten-channel-bound-flag-00.txt
to address this issue.

Please review.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Tue, 12 Feb 2013 16:29:14 +1100

Careful, said MS, you're stepping on my toes.

#define GSS_C_DCE_STYLE                 0x1000
#define GSS_C_IDENTIFY_FLAG             0x2000
#define GSS_C_EXTENDED_ERROR_FLAG       0x4000

On 12/02/2013, at 3:51 PM, Nico Williams <[email-masked]> wrote:

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

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

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Feb 2013 06:34:29 +0100 (CET)

Wouldn't it be simple to use one single API call with an additional
"critical" input parameter rather than these two with weirdly
different API semantics (only the _critical variant with an option
to create a modified copy of the handle).

Btw. the use of expressions such as
  "const gss_OID"
  "const gss_buffer_t"

is a historic defect of the GSS-API v2 C-Bindings spec (indicating
that the author didn't know how "const" affects typedef'ed pointers
-- it results in const pointers to mutable data, rather than a
mutable pointers to const data.

alternatives to choose from:

(1) simply drop const

     gss_function( ... , gss_OID   oid_param , ... );

(2)  avoid the typedefed pointer

     gss_function( ... , const gss_OID_desc  * oid_param , ... );

(3)  define appropriate pointer-to-const-data types:

typedef const gss_OID_desc     * const_gss_OID;
typedef const gss_buffer_desc  * const_gss_buffer_t;
 
     gss_function( ... , const_gss_OID  oid_param , ... );

-Martin

---

From: Luke Howard <[email-masked]>
Date: Tue, 12 Feb 2013 16:40:14 +1100

> mutable pointers to const data.

True, we have gss_const_OID and gss_const_buffer_t now.

However gss_set_cred_option has already shipped in MIT/Heimdal for some years now, with that prototype.

> typedef const gss_buffer_desc  * const_gss_buffer_t;

Namespace infraction. :-)

See RFC 5587.

-- Luke

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Feb 2013 06:40:55 +0100 (CET)

> #define GSS_C_EXTENDED_ERROR_FLAG       0x4000

Correct.  The "standardized" flags fill up from the low values,
whereas the vendor flags fill up form the high values.

  http://tools.ietf.org/html/rfc4121#section-4.1.1.1

The context flags currently defined in rfc2744 are:
  http://tools.ietf.org/html/rfc2744#page-85

   #define GSS_C_DELEG_FLAG      1
   #define GSS_C_MUTUAL_FLAG     2
   #define GSS_C_REPLAY_FLAG     4
   #define GSS_C_SEQUENCE_FLAG   8
   #define GSS_C_CONF_FLAG       16
   #define GSS_C_INTEG_FLAG      32
   #define GSS_C_ANON_FLAG       64
   #define GSS_C_PROT_READY_FLAG 128
   #define GSS_C_TRANS_FLAG      256

so the next free flag position from the standards range
appears to be 512/0x200.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 Feb 2013 06:54:26 +0100 (CET)

Luke Howard wrote:
> 
> [email-masked] (Martin Rex) wrote:
> 

Of course, reusing the typedefs from 5587 is perfectly OK.

> for some years now, with that prototype.

How about using a slightly different name for the new call that gets
standardized?  You're free to implement the single new call as a thin
wrapper to your old/existing interfaces.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 23:54:59 -0600

> to create a modified copy of the handle).

Maybe, but we've got a lot of things to throw into a replacement for
GSS_Init/Accept_sec_context().  If we tackle that now I'm afraid we'll get
really bogged down.

> mutable pointers to const data.

That's why we introduced new typedefs for const types in RFC5587.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 23:57:19 -0600

Oh!  oops, i screwed up constness for the OID and buffer types.  Sigh.
 I'll fix that.  Thanks for catching that.

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 23:58:23 -0600

> #define GSS_C_EXTENDED_ERROR_FLAG       0x4000

I checked MIT and Heimdal.  Did I miss 0x1000?  What flag number do you
suggest?

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 00:01:01 -0600

>   http://tools.ietf.org/html/rfc4121#section-4.1.1.1

We really need a registry.  We only have 32 bits to work with here :(

---

From: Luke Howard <[email-masked]>
Date: Tue, 12 Feb 2013 17:03:26 +1100

On 12/02/2013, at 4:58 PM, Nico Williams <[email-masked]> wrote:

> I checked MIT and Heimdal.  Did I miss 0x1000?  What flag number do you suggest? 

gssapi_ext.h in MIT

I suppose either start from the very top or use the next standards available one as Martin pointed out.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 08:39:57 -0500

With my chair hat on, may I suggest that phrases like "not acceptable,"
or "hopelessly broken," don't really add anything to the discussion.
I think the discussion would be enhanced by a bit more verbosity.

Obviously the currently implemented behavior is something that we've
found quite useful in the GS2 SASL mechanism and in other contexts.
There are applications that use and depend on channel binding today.

Nico would like to expand channel binding to HTTP.  Microsoft has done
this in their implementation although they needed to use different API
level semantics than GSS implementations provide.

It's reasonable for this WG to agree with Nico that's a valuable thing
to do and thus to work on doing it.

It's also reasonable for us to say that we don't support that use
case. Which isn't the same as saying the status quo is
unacceptable. People are getting work done today with channel
binding. Nico is hoping to standardize a way that channel bindings have
been more useful to one implementation.

So, I think one of the first questions to the WG is do we want to
support this additional use case.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 10:08:16 -0600

On Tue, Feb 12, 2013 at 7:39 AM, Sam Hartman <[email-masked]> wrote:

Thanks Sam.

My view is that RFC2743 is broken with regards to CB as written and in
any case it doesn't reflect what has actually been implemented and
deployed.  Given this it'd be better to update RFC2743 than leave it
as-is.  Whether it's worth doing anything to improve negotiation of CB
is separate question.

To summarize, I'm asking the WG two questions:

a) do we want to update RFC2743 to reflect reality and correct a
serious flaw in it?

b) do we want to add any features to make negotiation of CB more feasible?

My answer is -unsurprisingly- "yes" to both questions.

> level semantics than GSS implementations provide.

Thanks for noting this.  Microsoft depended on it for deployment of
"IWA w/ EP", which is shorthand (roughly) for "GSS w/ CB".

> to do and thus to work on doing it.

I'd certainly appreciate it.

> been more useful to one implementation.

Right.

> support this additional use case.

I do.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 11:15:39 -0600

On Mon, Feb 11, 2013 at 11:57 PM, Nico Williams <[email-masked]> wrote:
> Oh!  oops, i screwed up constness for the OID and buffer types.  Sigh.  I'll
> fix that.  Thanks for catching that.

That came from cutting-and-pasting the prototype from MIT krb5.
Fortunately the constness issue can be fixed without breaking
compatibility.

I'll be submitting a -01 shortly.  If anyone has links to the relevant
SSPI docs for the similar feature in SSPI please share so I can add an
informative reference to them.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 11:27:48 -0600

> #define GSS_C_DCE_STYLE                 0x1000

Aha!  I missed this because I'd searched for GSS.*FLAG.  Can we make
sure that all flags follow the GSS_C_.*_FLAG pattern, or that they
have aliases that do?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 11:48:03 -0600

I've posted a -01.  I've added some text about alternative designs,
SSPI, changed the flag assignment, and cleaned up some things.  Also
added a recommendation for mechanisms.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 11:49:16 -0600

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-williams-kitten-channel-bound-flag-01.txt

---

From: Luke Howard <[email-masked]>
Date: Wed, 13 Feb 2013 09:01:40 +1100

> sure that all flags follow the GSS_C_.*_FLAG pattern, or that they

We can, but I thought it better to follow RFC4757 to the word.

-- Luke