[12] in GSSAPI Development
Re: On provision of source IP addresses
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Apr 29 20:15:35 1991
Date: Mon, 29 Apr 91 20:14:32 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Linn. 508.486.6588. DTN 226-6588. 29-Apr-1991 1643"
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: John Linn. 508.486.6588. DTN 226-6588. 29-Apr-1991 1643's message of Mon, 29 Apr 91 13:43:34 PDT,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Mon, 29 Apr 91 13:43:34 PDT
From: linn@zendia.enet.dec.com
Another use for the IP address would be to provide a value to compare
against optional entries in a ticket's caddr field (per KV5 draft 4,
p. 24).
This is exactly the reason why I'm arguing that the network address
should be included into the gss_accept_security_context(). I agree that
including the IP address is a bit of a layering violation, and it may be
a little bit ugly, but 1) needing to pass information from one layer to
another is not ipso facto a bad idea, and 2) in an OSI environment,
that's probably the least of your problems. :-)
The alternative, however, is that you would need to document in the GSS
API documentation that due to limitations in the design of the GSS API
1) a site that wishes to use Kerberos V5 and the GSS API must use
zero-address tickets (ref KRBV5 draft 4, page 24) or 2) the GSS API
implementation must explicitly violate the Kerberos protocol spec and
_not_ check the the sender address against addresses contained in the
ticket during a gss_accept_security_context(). It is my belief either
of these possibilities are worse than the minor elegance problem with
putting in the network address into GSS API layer. After all, we are
intending to use the GSS API in the real world!
In any case, current input_chan_binding_buffer serves no purpose anyway
--- since it is specified as "application specific", an application
could just sign input channel information using gss_sign and then the
application server could compare it as part of the startup of the
application protocol. So at the very least, even if we don't do
anything else, the input_chan_binding_buffer variable should go away.
- Ted
