[19] in GSSAPI Development
Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (John Linn. 508.486.6588. DTN 226-6)
Tue Apr 30 10:59:29 1991
Date: Tue, 30 Apr 91 07:58:44 PDT
From: "John Linn. 508.486.6588. DTN 226-6588. 30-Apr-1991 1058" <linn@zendia.enet.dec.com>
To: gssapi-dev@ATHENA.MIT.EDU
Ted writes:
> 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!
Thanks for clarifying the requirement. I recognize that OSI can be an
irresistible bashing target; on the other hand, recognizing the fact that many
of its constructs and concepts are becoming widely accepted (even in the IETF,
the keepers of the Internet architecture), I believe that we can't afford
ourselves the luxury of dismissing it. I believe that we should be able to
operate and provide peer-peer authentication even in a strictly layered
environment, preserving the opportunity to provide extra security value by
violating that layering if and where possible.
I think the situation is as follows: All candidate mechanisms can support their
core cryptographic strong authentication features without adopting conventions
on what's passed in channel bindings. Kerberos wants to adopt a
convention so that the source IP address can be extracted from the channel
binding argument in order to support an additional feature. It is important
to us that we preserve the ability to pass arbitrary, application-provided
information for protection and validation through the channel binding facility.
I'd like to converge on a constructive compromise.
I propose that we should accomodate both motivations by agreeing on a
self-descriptive channel binding argument. The first value agreed for its
descriptor would correspond to a source address specifier (which could assume
one of a number of address types, per Ted's earlier-cited examples: would a
NULL_ADDRESS make sense for use across an addressless wire?), followed by
(optional) application-provided data to be uninterpreted from the viewpoint of
an underlying mechanism. All mechanisms in attendance would agree to accept
channel binding arguments carrying this descriptor. Applications providing
channel binding arguments would receive protection features which are broader
(in a manner which is partially mechanism-specific) than applications omitting
such arguments, but applications could still function without providing channel
bindings. Mechanisms receiving channel bindings with address types they didn't
recognize could treat them as uninterpreted data. Other descriptor values and
interpretations could be declared, registered, and/or adopted later.
>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.
This rationale seems to suggest that it's wrong for the interface to support
any function which a caller could perform instead. To protect context
establishment tokens providing peer entity authentication, before reaching the
point where you're in a position to use gss_sign and gss_verify, it's useful
for a peer to be able to compare information about an associated channel which
they provide against that which is incorporated in a received token to
represent what the other peer provided. One reason for putting this particular
comparison below the interface is the fact that a detected mismatch is very
likely to represent an attack; a system's GSSAPI implementation (whose primary
purpose in life, unlike that of most caller applications, is to support
security functions) is a good central place within a system to trigger alarms
and collect audit trails on suspicious events. The ability for a mechanism to
carry and protect such information within its tokens doesn't mean that the
mechanism must treat it as other than uninterpreted data.
--jl
