On Fri, Mar 19, 2004 at 09:57:27PM -0500, Ken Raeburn wrote: > Martin Rex <[EMAIL PROTECTED]> writes: > > 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?
Such things should have an allocation policy, perhaps using the IANA. > - 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? This should be implementation specific, though I'd have the spec recommend yes, even when using oos detection (oos tokens aren't necessarily a problem). > 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. A single cred should be shareable across multiple threads. Yes, we do need to decide how much the spec should say about threading. > 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 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. Sure, but this is really a simplification that I think most of us should be willing to live with. On any platform where pointers to different things are of different sizes and so on this spec may not be workable, but that's ok; implementors on those platforms may have to make their own bindings, or they may find the Java bindings useful. > - 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. Well, on IP32, IP64 and LP64 platforms it's possible to give the implementor a choice of integer and pointer types for the handles and still maintain ABI compatibility. That's most every platform. [...] > - 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.) Not only this, but also, the GSS_C_*, GSS_S_* and gss_* names originate from RFC2743. The base spec should have an allocation policy for extensions' names. And the bindings specs should apply the base spec's policy towards the language's namespace. [...] > Can I use gss_uint32 in my code? (True, there's no guarantee that > it's the same as OM_uint32.) There should be. It's implicit in the name. Yeah, I'm convinced: the base spec and the bindings specs need updating. 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]
