[26] in GSSAPI Development
Re: Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (John Wray, Secure Systems Developm)
Tue Apr 30 22:33:05 1991
Date: Tue, 30 Apr 91 13:05:16 PDT
From: "John Wray, Secure Systems Development, DTN 226-6106 30-Apr-1991 1450" <wray@ultra.enet.dec.com>
To: gssapi-dev@Pa.dec.com
>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.
I don't think the layering violation problem is insurmountable, either. I'm
more worried about a couple of practical problems that requiring the network
address may cause us.
What form of source address should a verifier should provide when the token
originator is on a different network from the verifier? For example, consider
a transport-level relay connecting an X.25 network to a TCP/IP net. The relay
accepts incoming calls from the X.25 net and converts them into TCP
connections, dynamically mapping the X.25 call-id into a TCP port number. We'd
like to be able to support end-to-end (application-to-application)
authentication through such a device, but I can't see how to get the
source-network-address to the receiver for it to pass into its
accept_sec_context any way except by having to carry it in the application
protocol (in which case we can't claim that we're providing independent
verification of the source address, so it's value is very suspect).
Similarly, consider a dial-in line from a PC to a host system. I'd like the PC
to be able to authenticate itself to the host system using the GSSAPI, but
there aren't any addresses involved here. I think that the underlying
mechanism must still be able to function without requiring source addresses.
That said, whenever addresses are available, they should be supplied in the
channel bindings. To allow individual mechanisms to offer the maximum
protection possible, it's well worth defining a format so that the mechanism
can reach into the bindings and read the address from them, provided that no
mechanism will refuse to provide authentication services in the absence of such
addresses.
>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.
From above, this isn't just an OSI vs TCP/IP problem. I have no problems with
the above, except, for the reasons above, the GSS_ADDRTYPE_NULL should always
be allowed, with the explicit proviso that if it's specified, then the
application is explicitly opting out of providing the adddress, and source
network-address checks by the mechanism will therefore be impossible. By not
providing a source address, the application is saying that it doesn't care.
>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.
The intent is that the all the channel binding material should be signed, not
sealed. The channel bindings themselves need not be transferred between source
and target - only their signature need be sent. That's why the channel
bindings are inputs to both init_sec_context and accept_sec_context.
John
