[21] in GSSAPI Development
Re: Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Apr 30 14:45:51 1991
Date: Tue, 30 Apr 91 14:44:28 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Linn. 508.486.6588. DTN 226-6588. 30-Apr-1991 1058"
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: John Linn. 508.486.6588. DTN 226-6588. 30-Apr-1991 1058's message of Tue, 30 Apr 91 07:58:44 PDT,
Reply-To: tytso@ATHENA.MIT.EDU
Well, it seems that we will either need to (partially) dismiss the OSI
layering requirement or Kerberos protocol. I'm not sure which horn of
the "design paradox" your compromise chooses, since it was worded it a
manner which was a bit too abstract for my comprehension. Allow me to
restate the controversy in a bit more concrete terms, and if I am
missing any subtleties, please let me know!
It all boils down to whether or not the sender address is optional. If
the sender address is optional, then GSS API implementations which use
the Kerberos mechanism have two choices. They can either return a
run-time error, in which case applications which don't bother to supply
a sender address will not interoperate with Kerberos, or they can
explicitly violate the Kerberos protocol. Neither choice seems
particularily palatable to me. Thus, I would like to make the sender
address a mandatory argument.
What you seem to be telling me is that in OSI-land, it is bad karma for
the application layer to know anything about the sender's network
address. Whether or not this is a valid constraint doesn't matter a
whole lot; debating this is beyond the scope of this forum, and if it
has already been cast into stone as a standard, people will want to
follow it whether or not it is technically valid. Therefore, requiring
the sender address will requiring that the GSS API to violate the
paradigm laid out by the OSI architects. Thus, you would like to see
the sender address be optional.
Does this accurately state the crux of the disagreement? There is also
the question of whether or not an optional "application-specific"
channel binding should be included, but I think this is a minor issue.
My argument against it was not that "all functionaility should be moved
out to the caller responsibility". Instead, I was arguing that it
should be eliminated because the GSS API interface is already needlessly
complicated, and we should make it as simple as possible without
sacrificing functionality --- otherwise, it will be unlikely that people
will use it; after all, it doesn't even have the excuse of being an
international standard! :-) (Sorry, I'm OSI-bashing again, aren't I?
I'll try to avoid it, but it's such an easy target. :-) However, if you
really want to have an application-specific channel binding which is
uninterpreted by the GSS API and the underlying mechanism, I am prepared
to cede the point, although I still think it needlessly complicates the
interface with very little benefit.
However, I think the sender address issue is much more serious, and it
is much harder to solve. Allow me to offer the following concrete,
compromise proposal. The channel_bindings input variable shall take the
following structure:
typedef struct channel_bindings_struct {
OM_uint32 addrtype;
gss_buffer_desc sender_address;
#ifdef OPTIONAL
gss_buffer_t appl_specific;
#endif
} channel_bindings;
The values of addrtype between 0 and 255 shall be reserved for Berkeley
Standard Distribution address family types; if the number is in that
rage, then sender_address shall contain an address defined by the format
for the BSD Address Family. Values above 256 are reserved for future
definition by future GSS API documents. The value 256
(GSS_ADDRTYPE_NULL) shall mean the Null Address type, and should only be
used in environments where it is impossible to obtain the network
address of the sender due to intrinsic restrictions on the environment.
Use of GSS_ADDRTYPE_NULL in any other circumstance will result in
undefined behavior. So applications written for current networking
protocols will be required to set the sender address; however, if OSI
really does take over the world, OSI applications will merely have to
set addrtype to 256. I claim that if you have an application that is
being rewritten to use OSI instead of the TCP/IP protocol stack, enough
things will have to change that needing to hardcode addrtype to be 256
will be the least troubling of all of the changes you will need to make
to that poor application.
As far as the application specific channel bindings goes, if you really
insist that it be included, I suppose it doesn't do any harm. I don't
see it being very useful (especially in an OSI world!), and it just
makes the mechanism implementor's life that much harder, but if you
really want it, I suppose we can compromise on this point. If it is to
be included, however, I would like to see documented explicitly what the
mechanism should do with this information --- should it be sealed? or is
signing the information sufficient? This is important, since someone
might be tempted to put keying information into this buffer when it
might not be appropriate.
What do people think about my proposal?
- Ted
