Re: KITTEN BOF at IETF 60?

On Mon, Mar 22, 2004 at 10:17:40PM +0100, Martin Rex wrote:
> Ken Raeburn wrote:
> > 
> > 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?
> 
> For me GSS_C_AF_CHAOS is just as useless ans GSS_C_AF_INET4.  :)
> 
> Seriously, the channel bindings are probably straight from GSS-API v1
> which was published in 1993 (rfc-1508/1509) and someone was trying
> to create a complete list of known networking protocols at that
> time, I suppose.  That there is no GSS_C_AF_INET6 seems to indicate
> that there weren't many implementors using channel bindings when
> GSS-API v2 was discussed...

Or that IPv6 wasn't being used by "many implementors using channel
bindings when [the] GSS-API v2 was discussed..."

> 
> > 
> > - No guidance concerning thread support.
> 
> Multi-threading is an extremely platform specific mess and thread support
> will implementation specific anyway.  GSS-API v2 does *NOT* cover
> threads at all, and it is quite good that it doesn't even try to
> (because it would almost certainly have failed).

We don't have to talk about particular threading interfaces.  Just
what is and is not thread-safe in the GSS-API.

> The discussion about multi-threading with GSS-API came up a few times
> on CAT before GSS-API v2 was completed, but most of the participants
> agreed that it would be a too radical change for a mature API and
> better be saved for a GSS-API v3 revision that could decide to
> break with interoperability.  The apparently most often mentioned
> lack was an initialization and a final cleanup call.

This is not a problem for platforms with decent run-time linkers ;)
where the applications need not know about library initialization and
finalization.

[...]
> A gssapi mechanism implementation that wants to offer support for
> multiple threads must at least offer concurrent use of independent
> handles (correctly locking/serializing access to internally shared
> resources).

Yes.  This much definitely can be said in the C-bindings spec.

[...]
> >   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.
> 
> rfc-2743/2744 is actually GSS-API v2 update 1.
> 
> If you look at rfc-2078 there was the concept of dynamic OIDs over
> a few years in GSS-API v2, but was dropped when it was realized that
> there were several problems with dynamically allocated OIDs and
> that it was backward-incompatible with GSS-API v1.
> 
> Rather than explicitly "outlawing" mechanism implementations that
> had implemented the gss-api-v2 draft it was considered more appropriate
> to list the requirements and constraints on OIDs once they're made
> visible to the application.
> 
> One of the situations where OIDs might be initially dynamic is
> plug-n-play multimechanism schemes where the glue layer figures
> out OIDs and OID_sets at runtime.  But as there is no (more)
> gss_release_oid() call, the OID needs to exhibit "const" behaviour
> once it has been returned to the application caller via any of
> the gssapi calls.

Right.  gss_release_oid() was needed for use with gss_str_to_oid().

> > - 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.
> 
> B.3 says:
>    For binary portability, additional constraints are required. The
>    following is an attempt at defining platform-independent constraints.
> 
> Why does this make you shudder?  The decription that follows this is
> more-or-less the assumptions that must be met so that the *independent*
> header files of the application programmer and the gssapi mechanism
> programmer will smoothly interoperate when the two binaries
> (exe-application and shared lib-mechanism) meet in the wild.
> 
> > 
> > - 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.
> 
> It really doesn't matter how it is passed.
> 
> It is about interoperability when the two binaries (exe-app and
> shared lib-mechansim) have been *independently* built with differing
> definitions for e.g. gss_ctx_id_t.
> 
> So even if the application treats it as a pointer and the gssapi
> mechanism actually uses an "int" they both should interoperate!
> However if the gssapi mechanism uses an integer (and a union to
> get size/alignment of void*), then the gssapi mechanism must clear
> bits in gss_ctx_id_t when setting the integer part of the union
> in case that sizeof(void*)>sizeof(int), e.g. on a 64-bit platform.

I get it.  Do note Ken's point about architectures that use different
registers for passing pointer and integer arguments (e.g., MC680x0).

I think apps should always see pointers, even though the GSS-API library
might cast them into integers and then back, internally.

I.e., force the header to use pointers to partial structs and leave it
at that.

> 
> > 
> >   (And I'd have to research it, but suggesting incomplete struct
> >   pointer types might be a better option.)
> 
> I agree.  Instead of just discouraging (void*) the spec would have
> better suggested to use imcomplete struct pointers -- I didn't know
> how simple that is and how good it works for quite a while...

And it is good!

> > (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?
> 
> I think that a GSS-API v2 spec that wants to advance to draft standard
> (which may well be independent of KITTEN going for GSS-API v3),
> then the refined spec should clearly outline that channel bindings
> are optional for the gssapi mechanism to implement and optional
> for the application to use and it should give a warning what
> mechanisms should do if one peer supplied/supports channel bindings
> and the other doesn't... (in order to document existing practice).

The base spec should say that channel bindings support is optional for
all mechanisms except those that mandate it.  This cascades through to
the language bindings specs.

> 
> > 
> > > 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?
> 
> I would consider that heavily underspecified.  I think it is a flawed
> assumption that the network interface that the application is
> using is for communication will always be available/visible/accessible
> to the gssapi implementation when it acquires/creates credentials,
> even if both are using IPv4.  This seems to be more obvious when the
> application is *NOT* using IPv4.

This is definitely not an abstraction violation.  If you want to use
channel bindings you have to know the "name" of the channel you're
binding to -- that's part of the channel binding concept.  If you don't
have access to the channel's name, you can't use channel bindings.

GSS-API applications aren't required to know the names of the channels
they use, unless they want to use channel bindings.

> I know little about IPv6, but the situation of adhoc-creation of
> network addresses unknown to the gssapi mechanism may be more
> common with IPv6.

Network addresses make bad channel names.  We know this.

We're trying to bind to channels that have cryptographic characteristics
that we can bind to.  TLS and SSHv2 channels definitely have
cryptographic names that can be used that are much better than network
addresses.  We're working on IPsec channel bindings that don't require
knowledge of network addresses either (I think we'll soon have agreement
in the IPsec space on this).

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]