On Fri, Mar 19, 2004 at 09:57:27PM -0500, Ken Raeburn wrote:
> Martin Rex <[EMAIL PROTECTED]> writes:
> > 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:
> 
> - 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));                  \
>     })

Why bother?

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

We're using pointers to incomplete structs in the upcoming release of
Solaris.  The use of "void *" for this sort of thing should be avoided
as it foils compiler/lint type checking.

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

Perhaps there should be a recommendation, but nothing more.

> > 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 truly don't care that some implementations don't support channel
bindings.  I care that some do, and truly, some do, and more will.

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

Me too, and anyways, rfc1964 has the initiator send a hash of the
channel bindings to the acceptor, so the acceptor can't "[peek] inside
the channel bindings and [match] them up against credentials."

The problem with rfc1964 (and cfx) is that the acceptor does not send a
hash of the channel bindings back to the initiator (and if it did it'd
have to be a different value) to prove that it too sees the same
underlying channel as the client.  But I think this is a minor problem
that can be addressed in one of several ways, and which does not need to
be addressed here now.

Cheers,

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]

Reply via email to