[5] in GSSAPI Development
Problem in gss_accept_sec_context()
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Apr 25 18:40:25 1991
Date: Thu, 25 Apr 91 18:40:11 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: gssapi-dev@ATHENA.MIT.EDU
Cc: jtkohl@ATHENA.MIT.EDU, gssapi-dev-mtg@menelaus.mit.edu
Reply-To: tytso@athena.mit.edu
In attempting to code gss_accept_sec_context, I ran into a problem.
When Kerberos does a krb5_rd_req(), it requires the sender's network
address, and there's no place to pass that into gss_accept_sec_context.
We could use input_chan_bindings_buffer, but there are two problems with
it. First of all, it says that its application-specific, and what we
need is something which is mechanism specific. Secondly, it says that
it is optional, and it must be mandatory for it to work with Kerberos.
Finally, there is no standard format for the input_chan_bindings_buffer,
and there must be a standard way of passing in the sender's network
address if we want an application originally designed for the SPX
implementation of GSS API to work when linked against the Kerberos GSS
API.
I suggest that we replace input_chan_bindings_buffer on both
accept_sec_context and init_sec_context with the an sender_address
paramter which is mandatory and which takes the following structure:
/* structure for address */
typedef struct gss_network_address_desc {
OM_uint32 addrtype;
int length;
void *contents;
} gss_network_address;
#define ADDRTYPE_INET 0x0002
#define ADDRTYPE_CHAOS 0x0005
#define ADDRTYPE_XNS 0x0006
#define ADDRTYPE_ISO 0x0007
#define ADDRTYPE_DDP 0x0010
Where the definitions for the various address will be defined to match
the defined address family formats in the Berkeley Standard
Distributions of Unix.
We should try to reach consensus about this as soon as possible, since
without this Kerberos is not going to be work with the GSS API (as
currently specified.)
It's somewhat embarassing that we didn't catch this problem sooner, but
it just goes to show that letting architects codify standards without
any implementation experience is a really bad idea. But we knew that
already from OSI. :-)
- Ted
