Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG

[Nico Williams <[e-mail]>]

On Tue, Feb 12, 2013 at 11:23 PM, Thomas Maslen <[e-mail]> wrote:
> 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 for them.  With that out of the way...

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 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.

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
--