[30] in GSSAPI Development
Re: Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (John Wray, Secure Systems Developm)
Wed May 1 13:51:32 1991
Date: Wed, 1 May 91 10:50:41 PDT
From: "John Wray, Secure Systems Development, DTN 226-6106 01-May-1991 1308" <wray@ultra.enet.dec.com>
To: gssapi-dev@Pa.dec.com
Ted writes:
>It would seem that the mechanism should be making the security decision
>of whether or not the source (or receiver) address matters, _not_ the
>application. Insofar as the low-level transport address provides some
>level of protection against attacks, this is an authentication decision
>which the mechanism may want to make based on this information; it is
>not necessarily an authorization decision.
But the mechanism won't necessarily know anything about the networking
environment. The reason that the GSSAPI deals in token-manipulating services
(rather than in services that provide authenticated network connections) is to
allow this decoupling. I don't dispute that, in a purely internet environment,
the application should provide source and target internet addresses, so that
the mechanism can do this additional verification. By providing IP addresses
in channel-bindings to init_ and accept_sec_context, the application is
implicitly informing the mechanism that IP will be used to carry the token.
Once thus informed, a given mechanism may be able to provide stronger
protection. In the absence of knowledge of the chosen networking technology,
the mechanism shouldn't prevent the applications from communicating as securely
as possible.
>I could imagine
>authentication systems where the hostname might be part of the
>authenticated principal, and as such the decision to allow a user
>operating at one (trusted) hosts versus allowing a user operating at
>another host would be an authorization decision made by application.
>However, the source (and receiver) addresses can also be used to make
>authentication decisions, by on comparing the source address against
>information sealed inside a ticket to make exploting stolen tickets more
>difficult. Why should we prevent that?
I agree that we don't want to prevent this. Applications that have access to
their own address and the network address of the remote peer should be
encouraged to present such addresses. Defining a mandatory portion in the
channel bindings to contain addresses is very strong encouragement. Allowing
the use of the GSS_ADDRTYPE_NULL is a way to allow applications that really
cannot give meningful addresses to continue to use the GSSAPI.
>As for the two examples which John presented, the X.25 to TCP/IP relay
>and the PC w/o a network address, let's look at them in reverse order.
>If the PC really doesn't have a network address then the server can use
>GSS_ADDRTYPE_NULL without any problems.
If this is true, then I don't think we're in disagreement (assuming that the
authentication mechanism won't refuse to authenticate such a client).
>As for the X.25 to TCP/IP relay, even if the X.25 source address cannot
>be trusted (because you don't trust the relay to give you authoratative
>information about where the X.25 connection _really_ came from), is that
>an excuse not to put the (admittedly possibly suspect) information into
>the sender_address field, instead of GSS_ADDRTYPE_NULL?
Well, the situation I was imagining was that I (the TCP host) had received an
incoming TCP connection from the relay, and so all I know is the internet
address of the relay. I don't know the X.25 address of the originator. I
don't even support X.25! I just want the GSSAPI to tell me who my remote
client is. In this case, passing in the only address available to me (the
relay's internet address) will guarantee failure to authenticate, so I don't
really have any choice but to use GSS_ADDRTYPE_NULL.
>Presumably the
>person who modified the mechanism to accept X.25 source address in
>addition to TCP/IP address knew that X.25 source address might not be
>secure since they need to go through a relay, so it should be his
>responsibility to use or not use the information as appropriate. I feel
>strongly that the application should not ever withhold information to
>the mechanism --- let the mechanism decide what do to with the
>information, since it can always ignore it.
This illustrates a serious problem - The mechanism shouldn't have to be
modified just to allow the use of an alternative network protocol. If the
mechanism is given a source address that it doesn't understand, it should
simply ignore it (but continue to check it against the channel bindings in the
token).
Maybe there's a disconnect at the heart of the matter - The channel bindings
_must_ be the same at init_sec_context and at accept_sec_context. The token
has to convey a signature that covers the actual octet-string of _all_ the
channel binding data (or provide the same service by an alternative mechanism).
That includes any portion of the bindings that the mechanism understands to be
an address. If the mechanism at both ends can understand some portion of the
channel bindings, then it may make any additional checks it wants to using that
portion of the bindings. However, if the mechanism doesn't understand the
bindings, applications must still be able to use them to protect themselves
against token-stealing. This way, even if the mechanism doesn't understand
(for example) X25 addresses, the applications can still put them in the
source/target address fields of the channel bindings and expect them to be
verified.
Choosing not to use addresses therefore isn't a unilateral decision - the
acceptor can't simply refuse to supply them and expect to authenticate a client
that has provided them. If both initiator and verifier decide that some other
form of bindings are more apropriate, or if they need to use an addresstype
that is not known to the mechanism, then they should still be able to get
authentication services from the mechanism.
John
