[2069] in Kerberos-V5-bugs
Re: gss_import_name...
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Wed Jul 3 01:15:06 1996
To: blob@syl.dl.nec.com (David Blob)
Cc: krb5-bugs@MIT.EDU, cat-ietf@MIT.EDU
Date: Wed, 03 Jul 1996 01:14:44 EDT
From: Marc Horowitz <marc@MIT.EDU>
>> In RFC 1961 (GSS-API w/Socks5), they say:
>>
>> The client should call gss_import_name to obtain an internal
>> representation of the server name. For maximal portability
>> the default name_type GSS_C_NULL_OID should be used to specify
>> the default name space, and the input name_string should
>> treated by the client's code as an opaque name-space specific
>> input.
>>
>> Which of course tries to allocate & copy the name. Problem is the name
>> is NULL, so on the copy, I get a seg fault. Is this a problem in beta6,
>> or an oversight in the RFC? If that's the case, what should go there?
Neither rfc1508 nor draft-ietf-cat-gssv2-06.txt (which is supposed to
advance to proposed, but is still in rfc-editor-wait) mentions the
validity of NULL to indicated a default name type, and I believe this
is correct. However, rfc1509 does describe the validity of NULL.
This is a conflict, and I believe the base specification gets it
right. So, I believe that rfc 1961 is in error. This rfc reads like
it was written to a much older version of the gssapi drafts than is
currently under discussion in cat group. I've only read section 3.1,
but I believe this is a sufficient, more correct replacement:
3.1 Preparation
Prior to use of GSS-API primitives, the client and server should be
locally authenticated, and have established default GSS-API
credentials.
The client should call gss_import_name to obtain an internal
representation of the server name. The name type should indicate
the Host-Based Service Name form, and the input name_string should
be of the form "socks@socks_server_hostname" where
"socks_server_hostname" is the fully qualified host name of the
server with all letters in lower case.
Although this set of inputs should be portable to most mechanisms,
implementations may wish to make the input name configurable.
Although it probably doesn't exist yet, there will be an IANA registry
in which "socks" should be registered.
That said, I'm unconvinced it is appropriate for this rfc to explain
all the details of how applications should call the gssapi.
Otherwise, this sort of thing will end up in a huge number of
documents (assuming gssapi gets the widespread adoption I hope it will
:-). There are already some people talking about non-C gssapi
bindings, too. Most of section 3 seems to be independent of SOCKS,
since all gssapi applications need to do this sort of thing.
There are also the aesthetic consideration that interleaving API stuff
with the more traditional packet block diagrams makes things a little
hard to read.
Marc
