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]