Re: KITTEN BOF at IETF 60?

Martin Rex <[email protected]> writes:
> Sam Hartman wrote:
>> * During the course  of implementing GSSAPI and GSSAPI mechanisms,
>>  significant problems in the clarity of the base  specification and C
>>  bindings have been found.  KITTEN will identify these problems and
>>  will propose changes to the  specifications to address issues of
>>  clarity.
>
> Strange--I'm not aware of any such problems; and I'm sure I would
> know if there were any real problem with it.  I remember that coming
> up with a different language binding requires discussion (the JAVA
> guys realized that), however the C-Bindings itself is sufficiently
> clear.
>
> Could you elaborate on this?

Well, I haven't implemented a mechanism from scratch, mostly tweaked
MIT's krb5 mechanism, but I can toss out a few nits I have to pick
with RFC 2744:

- No GSS_C_AF_INET6 definition.  Some of the AF definitions that are
  included are silly.  Does anyone on the planet care about
  GSS_C_AF_CHAOS?

- No guidance concerning thread support.

  If a mechanism doesn't provide out-of-sequence detection, can I use
  gss_get_mic in two threads with the same security context, without
  ensuring that the calls aren't fully serialized?

  How about gss_inquire_cred on the same credentials in multiple
  threads?  The description of that function suggests that cred_handle
  is an input argument, but the description of gss_acquire_cred says
  that gss_inquire_cred may implement delayed credential acquisition,
  which suggests modification under the covers.

  How about general use of the GSS-API from multiple threads for
  unrelated sessions?  If a mechanism has static data that it
  modifies, must it use a mutex (or semaphore, or atomic-access
  instructions) internally in a threaded environment?  Or is it up to
  the application to avoid the simultaneous use of GSS-API functions
  in different threads?

  I'm actually working on thread safety for the MIT code right now,
  and I'm pretty much having to guess.

- The handling of "const" is confused.

  Several "pointer or arithmetic type" parameters are declared
  "const".  This does *not* mean "any pointed-to data is not modified
  by the function".  It means "the function implementation cannot
  modify its local copy of the argument passed in", which is just
  silly, since doing so doesn't influence the caller at all.

  I'd have to check the C spec, but I'm not sure if it would be
  compliant with ISO C to actually define the specified OIDs as
  "const", given the header file we're supposed to provide.  But
  that's an "implementation detail", and implementations are on real
  systems, not ISO C abstract machines.  The application isn't allowed
  to write to the OIDs, so as long as the behavior is correct for a
  compliant application, stuffing them in read-only storage and not
  declaring them "const" in the available header is probably fine.

  Maybe that's not completely true.  The spec says "should" in a lot
  of places, including "GSS-API implementations *should* provide
  constant gss_OID values" and "*should* treat...as read-only", but
  not "must", and as far as I've found, it doesn't explicitly give the
  implementation license to blow up if the application misbehaves in
  this regard.

- How is the header file used?  <gssapi.h> or <foo/gssapi.h> or
  something else?  At least some applications are testing the
  environment in order to pick between <gssapi.h> and
  <gssapi/gssapi.h>.  What's "portable" here?

- Tying anything to whether or not X/Open header files are available
  is pretty clear, but unfortunate.  (Especially where a lot of
  systems have optional add-on packages these days.)  Updating to C
  '99 would be nice, if it can be done compatibly.

- Is an implementation allowed to define any of these functions as
  macros as well (a la C '89, which generally allows it but requires
  that an addressable function be available as well).

  For example:
  #define gss_wrap(a,b,c,d,e,f,g)                            \
    ({ /* statement expression - gcc extension */            \
       gss_ctx_id_t _ctx = (b); /* no multiple evaluation */ \
       (_ctx->ops->wrap(a,_ctx,c,d,e,f,g));                  \
    })

- Appendix A: "C-language GSS-API implementations should include a
  copy of the following header-file."

  Ignoring the fact that platform-specific substitutions need to be
  done first, and the preprocessor test using sizeof is completely
  useless (the preprocessor doesn't evaluate sizeof), this also
  suggests that no other changes (e.g., declaring extension functions
  or additional name-type OIDs) are allowed.

- The description of equality comparisons in section B.3 makes me
  shudder.  I'm not even sure what it means.  As far as I can tell, if
  your machine lets you have two objects (pointers, integers, floats)
  that compare equal with "==" despite having some bits that are not
  identical, then you have to fix up those bits to always be equal.

- If you want to make recommendations about ABI compatibility, how
  about suggesting *either* pointer or arithmetic type for handles,
  and not giving the implementation the choice.  Not only is it valid
  for pointers and arithmetic types to be passed and returned
  differently, there is at least one platform where pointers and
  numbers *are* returned differently.  Also, floating-point values are
  "arithmetic", and are often passed differently from both integers
  and pointers.

  (And I'd have to research it, but suggesting incomplete struct
  pointer types might be a better option.)

- Should the ABI discussion touch on shared library names?  I'm not
  sure.  Perhaps not.

- No discussion of C namespace issues.

  Are names starting with "gss_" and "GSS_" reserved for
  implementation internal use, future updates and extensions?  Or
  should applications feel free to use them?  If they're reserved,
  then under what conditions?  (See the C library spec's description
  of this sort of thing, IIRC there are at least two classes of
  reserved names.)

  Inclusion of gssapi.h on an ANSI C system is required to define
  ptrdiff_t and offsetof(), right?  After all, Appendix A, which
  apparently is normative, says it includes stddef.h, and C '89 says
  stddef.h defines those.  So using some system-specific header than
  only provides a __size_t for the implemenation's use, and avoiding
  stddef.h, is not allowed?

  What's added to the namespace on an X/Open system?

  Can I use gss_uint32 in my code?  (True, there's no guarantee that
  it's the same as OM_uint32.)

(Taking off my "amateur language lawyer" hat now....)

> Channel bindings are actually non-portable anyway, many gss-api mechanisms
> don't implement them (even Microsoft's Kerberos doesn't) and portable
> applications don't use them anyway.  Routing&multihoming issues,
> NATs and all that interfere in all sorts of ways.

And the non-portability makes it okay for the specification to be
confusing?  Does the GSS-API spec say that you shouldn't use channel
bindings?  Should it?

> So far I've primarily seen clear breaches of the abstraction when
> IPv4 channel bindings where used with Kerberos and the Kerberos
> gssapi mechanism did not only verify the channel bindings at both
> ends with the application provided values, but also peeked inside
> the channel bindings and matched them up against credentials.

What abstraction?  I thought RFC 2743 section 1.1.6 allowed for this
sort of use?

Ken
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]