Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG

From: Thomas Maslen <[email-masked]>
Date: Wed, 13 Feb 2013 05:23:11 +0000

This is a general comment on draft-williams-kitten-channel-bound-flag-01 from the perspective of Java GSSAPI (RFC 5653).

NOTE:  This is just my personal 0.02.  It doesn't necessarily reflect the views of my employer (Quest, now part of Dell).  Also, I have no affiliation with Oracle, so I'm definitely not speaking for them.  With that out of the way...

To solve this problem for the Java GSSAPI (RFC 5653), I think that it would be more natural to do any one of the following:

    (a) Add a new constructor to the ChannelBinding class (section 7.6.1) that uses a new boolean parameter to convey the same information as Nico's GSS_C_CHANNEL_BOUND_CRED_OPT_OID, or

    (b) Instead of adding a new constructor, add a boolean setter method, or

    (c) Create a new subclass of the ChannelBinding class [OK, that's probably silly], or

    (d) Add a variant of the GSSContext.setChannelBinding(ChannelBinding cb) method (section 7.4.31) that includes the extra boolean

To me, any of those feels much more natural than doing something tricky via the GSSCredential.

I think I understand why you have to resort to (from my perspective) somewhat unnatural acts for the C bindings -- you can't add a field to the gss_channel_bindings_struct because that would break badly, and you (very reasonably, per your section 1.2) don't want to change the signature of gss_accept_sec_context() -- but IMO it would be unfortunate if a problem that is specific to the C bindings led to a perverse design in the abstract GSSAPI (RFC 2743) and in the Java bindings.

For example, I don't think that the Java bindings really need GSS_C_CHANNEL_BOUND_CRED_OPT_OID, and for that matter I'm not sure that the abstract GSSAPI does either.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Feb 2013 05:17:30 -0500

Folks,  we're in a position where several people are eagerly discussing
the details but where no one has actually expressed support for doing
the work besides Nico.

The sorts of comments Jeff, Luke and even Thomas are making are the
kinds of comments I'd expect from people working to solve a
problem. However none of those people  have even indicated that they
want to either:

1) Update RFc 2743 to describe actual practice

2) Provide a solution for adding channel binding to acceptors that
previously did not have it.

I'd also like to hear from Martin as I don't know how to interpret his
comments with regard to those two questions.

Right now, we have Nico and crickets.

Sam Hartman
Kitten co-chair

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 13 Feb 2013 05:09:13 -0800

I don't have a full background,

However I fully support this effort if, as the messages seem to imply, it is
not currently possible for an initiator or an acceptor to know that channel
binding has or has not occurred when requested.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sam Hartman
> Sent: Wednesday, February 13, 2013 2:18 AM
> To: [email-masked]
> Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG
> 
> 
the
> details but where no one has actually expressed support for doing the work
> besides Nico.
> 
> The sorts of comments Jeff, Luke and even Thomas are making are the kinds
> of comments I'd expect from people working to solve a problem. However
> none of those people  have even indicated that they want to either:
> 
previously
> did not have it.
comments
> with regard to those two questions.
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Feb 2013 09:02:48 -0500

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I don't have a full background, However I fully support this
    Jim> effort if, as the messages seem to imply, it is not currently
    Jim> possible for an initiator or an acceptor to know that channel
    Jim> binding has or has not occurred when requested.

It's not possible for an acceptor to deal with initiators some of which
support channel binding and some of which do not.  In the case of HTTP,
Microsoft found it incredibly useful to deploy channel binding in an
existing protocol.
It's not possible to do with GSS-API as specified.
Nico proposes to

1) Fix areas where RFc 2743 differs from what implementations actually
do. He proposes to decide the implemented behavior is correct rather
than to argue the spec is correct.

Nico also proposes to make it possible for an acceptor to support
initiators without channel binding along-side initiators with channel
binding.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 13 Feb 2013 06:19:46 -0800

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2013 6:03 AM
> To: Jim Schaad
> Cc: 'Sam Hartman'; [email-masked]
support
> channel binding and some of which do not.  In the case of HTTP, Microsoft
> found it incredibly useful to deploy channel binding in an existing
protocol.
> 1) Fix areas where RFc 2743 differs from what implementations actually do.
> He proposes to decide the implemented behavior is correct rather than to
> argue the spec is correct.
> 
initiators
> without channel binding along-side initiators with channel binding.

I think that he also makes it possible for the initiator and the acceptor to
determine if the channel binding occurred.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Feb 2013 09:24:34 -0500

If the initiator and acceptor both pass in non-empty channel bindings
they already have confidence that channel binding happened today.  Even
after Nico's proposal, it will be possible for an acceptor to explicitly
ignore channel bindings.

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Feb 2013 16:39:06 +0100 (CET)

Sam Hartman wrote:
> they already have confidence that channel binding happened today.

I'm terribly sorry to disappoint you, but this is not generally true.
It may be true for specific implementations, though.

There are gssapi mechanisms which do not implement support for
channel bindings, and which will simply and silently ignore that
parameter on gss_init_sec_context() and gss_accept_sec_context()
-- and these are still compliant with rfc2743/rfc2744.

>
> Even after Nico's proposal, it will be possible for an acceptor
> to explicitly ignore channel bindings.

Correct.

I agree with Nico that the existing GSS-API channel bindings semantics,
as specified in rfc2743/rfc2744 are not useful.

I believe it is worthwhile of adding the missing parts to make
GSS-API channel bindings useful.  Adding a context attribute flag
that indicates successful channel bindings validation is reasonable.
But I would appreciate if useful behaviour could be obtained without
having to perform an new GSS-API call.

The underlying principle of GSS-API in security context establishment is:
(rfc2743, Section 1.2.1, page 20)
   http://tools.ietf.org/html/rfc2743#page-20

   Some mechanisms may not support all optional services, and some
   mechanisms may only support some services in conjunction with others.
   Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the
   applications which services will be available from the context when
   the establishment phase is complete, via the ret_flags output
   parameter.  In general, if the security mechanism is capable of
   providing a requested service, it should do so, even if additional
   services must be enabled in order to provide the requested service.
   If the mechanism is incapable of providing a requested service, it
   should proceed without the service, leaving the application to abort
   the context establishment process if it considers the requested
   service to be mandatory.

And as Nico has properly noticed, _without_ a means for the application
caller to know whether channel bindings were used and/or successfully
verified during security context establishment, that last part does not
compute:

                                      leaving the application to abort
   the context establishment process if it considers the requested
   service to be mandatory.

Bottom line: the existing channel bindings support is
underspecified/incomplete.  And implementations that hard fail
on the acceptor side when the client did not assert channel bindings
are in conflict of the general GSS-API architecture as described above.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 09:41:28 -0600

> This is a general comment on draft-williams-kitten-channel-bound-flag-01 from the perspective of Java GSSAPI (RFC 5653).

I really appreciate this comment.  Thanks!

> NOTE:  This is just my personal 0.02.  It doesn't necessarily reflect the views of my employer (Quest, now part of Dell).  Also, I have no affiliation with Oracle, so I'm definitely not speaking fo…

Several years ago the JCP ceded ownership of the JGSS API to the IETF.
 This doesn't mean that Oracle will implement whatever we standardize,
or any other Java implementor for that matter, but it does mean we can
pursue JGSS extensions here.

> To solve this problem for the Java GSSAPI (RFC 5653), I think that it would be more natural to do any one of the following:

Sure, new methods make a lot more sense for the JGSS than a set cred
option method on credentials.  I completely agree.  I'd probably go
for a context method (your option (d)) rather than a new channel
binding constructor, but it's roughly all the same, yes?

> To me, any of those feels much more natural than doing something tricky via the GSSCredential.

Absolutely.  The Java bindings of the GSS-API has a fairly different
model from the abstract and C bindings.  For Java we should follow the
pattern already set for the Java bindings.

> I think I understand why you have to resort to (from my perspective) somewhat unnatural acts for the C bindings -- you can't add a field to the gss_channel_bindings_struct because that would break…

It's because there's no constructor for gss_ctx_id_t values.  You have
to call gss_init/accept_sec_context() with a null context initially.
Also, we already have gss_set_cred_option() in several C
implementations -- it made sense to re-use what we already had for
this sort of extension.

> For example, I don't think that the Java bindings really need GSS_C_CHANNEL_BOUND_CRED_OPT_OID, and for that matter I'm not sure that the abstract GSSAPI does either.

Agreed as to the first part.  As for the abstract API, it and the C
bindings resemble each other fairly closely, so I'd rather keep that
resemblance, but I'm open to alternatives.  After all, this option is
only a credential option in the sense that credentials are the
convenient carrier for the option -- there are other options that are
more like credential options (e.g., options related to cipher suite
policies, but these too would exist primarily to affect cipher suite
negotiation for security context establishment, so maybe this is a bad
example).

I have to agree too with the unstated sentiment that there are some
flaws in the abstract API and C bindings, namely:

 - no app/library context handle
    - minor status is too small to encode desired error information
 - the lack of both an app/library context handle and a constructor
for "empty" security contexts means that we don't get to pass in any
kinds of options except via req_flags and then only in
gss_init_sec_context()

I could go on.  That's a start.  However, this is the API we have.  I
have toyed before with a version 3 of the API to correct all of these
and many more problems (e.g., memory management issues in the C
bindings).  However, that would be a huge undertaking that I have
neither the energy nor the funding for, and even if I did, I'd still
have the immense task of getting the new API adopted.  I've settled
for accepting the flaws of the standard API and the barnacles that
implementations have gathered over the years, though not without some
sadness.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 09:44:57 -0600

> having to perform an new GSS-API call.

I don't see how we can avoid adding new function calls.  A req_flag
wouldn't help.  And a new ret_flag does nothing to protect against
apps that don't understand it.

> verified during security context establishment, that last part does not

Right.

> are in conflict of the general GSS-API architecture as described above.

Whereas in my view the GSS-API specification (RFC2743) has a bug.  You
yourself agree that the specified behavior is not useful -- how is
that not a specification bug?

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Feb 2013 17:02:52 +0100 (CET)

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

You're misunderstanding the GSS-API architecture.
The gssapi mechanism MUST NOT do that ("protect the application")

In GSS-API, the "req_flags" are about desires of the caller, not about
requirements (that is where GSS-API differs from Microsoft's SSPI).

GSS-API mechanisms are expected to establish the security context,
even if it does not meet all of the desires of the application,
and it is the duty of the application caller to check whether the
characteristics of the resulting security context are "sufficient".

The exact same semantics applies to "gss_wrap(conf=TRUE)".
If the gssapi mechanism can apply only integrity protection, but
not confidentiality protection, then it MUST succeed anyhow, and
return "conf_avail=FALSE":

   The conf_avail return value indicates whether the context supports
   per-message confidentiality services, and so informs the caller
   whether or not a request for encryption through the conf_req_flag
   input to GSS_Wrap() can be honored. 

> that not a specification bug?

The lack of an indicator that channel bindings were successfully validated
is the defect.  Failing security context establishment when the acceptor
provided channel bindings but the initiator did not supply them is a
bug of the server-side gssapi mechanism implementation.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 10:16:07 -0600

> The gssapi mechanism MUST NOT do that ("protect the application")

I misunderstood nothing.  The GSS-API *should* have had
GSS_C_CHANNEL_BOUND_FLAG, and if it had had that from day zero there
would be no question of "protect[ing] against apps that don't
understand [that flag]."  But *now* we cannot add this flag and
otherwise retain the original channel binding behavior, implementing
both in existing implementations that implement the alternative
actually-deployed behavior -- doing so would break things.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Feb 2013 17:23:16 +0100 (CET)

Nico Williams wrote:
[ Charset UTF-8 unsupported, converting... ]
> actually-deployed behavior -- doing so would break things.

I believe that you can add it now.

We can add it as a flag for both, input _and_ output.

For gssapi callers that do not pass that flag on input,
you can retain the original behaviour.

But gssapi callers that pass the new channel-bindings context
attribute flag as a desire on input, the semantics should follow
the original GSS-API architecture, and cause a successful context
establishment when just one side asserted channel bindings -- and
it is up to the calling application to check the resulting
new context attribute flag (which it claimed to understand!!)
whether it indicates successful channel bindings validation.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 10:26:39 -0600

> [ Charset UTF-8 unsupported, converting... ]

Really?  That's kinda funny.  It's 2013...

> We can add it as a flag for both, input _and_ output.

GSS_Accept_sec_context() has no flags inputs.  In order to make the
originally-specified behavior safe, the acceptor-side of the
mechanisms need to know if the acceptor applications understand the
new flag.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Feb 2013 17:44:08 +0100 (CET)

Nico Williams wrote:
> mechanisms need to know if the acceptor applications understand the

Ooops, you're right.  I forgot about that.
I'll think about it.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 10:43:49 -0600

I should also add that adding a new variant of
GSS_Accept_sec_context() that takes req_flags sounds silly given the
architecture of the API (namely that the application is to find out
what features it got, and that it is the initiator's responsibility to
request features needed by the application).

I would, I suppose, settle for that, but we do have a long-term need
for additional options, some of which cannot merely be flags, thus my
interest in standardizing gss_set_cred_option().  My fear is that
adding a variant of GSS_Accept_sec_context() will take us down a
rabbit hole out of which we'll not get for a long time -- we'll have
too much pressure to add other functionality and correct other base
GSS-API flaws.  Whereas adopting a widely deployed GSS extension from
C implementations seems like a path that is likely to yield quick
progress.

Perhaps we should test consensus on this question of which approach to
take to add this feature, but if we choose to go the new
GSS_Accept_sec_context() variant then I'll want a commitment to not
bikeshed it, otherwise I'll lose interest and move on to other
problems.

Nico
--