[32] in GSSAPI Development
Re: Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (Charlie Kaufman)
Wed May 1 15:46:59 1991
Date: Wed, 1 May 91 12:45:42 PDT
From: Charlie Kaufman <kaufman@kibitz.enet.dec.com>
To: gssapi-dev@ATHENA.MIT.EDU
Maybe it's my imagination, but it seems like we have indeed reached a
compromise on how to fix the channel bindings problem and now all we
are doing is speculating about possible future problems. The
compromise is to have the input argument containing channel bindings to
be changed from a length and a byte string to a structure of the form:
typedef struct channel_bindings_struct {
OM_uint32 sender_addrtype;
gss_buffer_desc sender_address;
OM_uint32 receiver_addrtype;
gss_buffer_desc receiver_address;
gss_buffer_t appl_specific;
} channel_bindings;
And to supply the addresses in the cannonical (network byte order) BSD
format. It would seem that this is all we need to agree on to make
progress on our portability demo. Down the road, there are some other issues:
1) Will Kerberos support the case where sender_addrtype is missing?
Supporting this case is an unnatural thing for Kerberos to be able to
do, but it could be managed by including the network address of the
sender in the token. If we did that, the application would not get the
network address protection that normal Kerberos applications do. I
believe for the first implementation, the we should do the easiest
thing which is not to support this case. We can discuss adding this
"feature" to the Kerberos GSSAPI if it is ever the most important
question on our agenda.
2) How will Kerberos deal with cases where network address is not well
defined or not available (as with dial in PCs or the X.25 transport
layer relay? This seems fundamentally an issue for the Kerberos
implementers to deal with if and when the question comes up. How to
make the solution work with the GSSAPI would seem to be the least of our worries.
------
I hate to muddy the waters when it seems like we have a solution, but
there are some ways in which I would have done this differently:
1) Given that Kerberos doesn't need the receiver address type for
anything, I would have left that out and had applications include it in
application specific data if they felt it appropriate.
2) I don't remember what the difference is between a gss_buffer_desc
and a gss_buffer_t, but it would be nice if we passed in the same kind
of thing for addresses and application data. I would have preferred a
count and a pointer to byte, but maybe that's what one of those is.
3) It would be nice to have a type for the application data to avoid
accidental aliasing between tokens for different applications. But
that introduces the threat of a new registry and in reality it
shouldn't be a problem.
-----
A minor GSSAPI issue that remains is what guarantees the GSSAPI should
make about channel bindings. The DASS implementations guarantees that
the channel bindings provided at the two ends are identical and that
they are not disclosed in a token (meaning that it is OK for the
channel bindings to contain secret information). The GSSAPI spec
should say what applications can expect in this regard. I think the
most natural thing would be for the GSSAPI to guarantee that the
channel bindings provided at the two ends are identical but that they
are not guaranteed to be kept secret within the token. This represents
some extra work for the Kerberos implementation: it would have to sign
the channel bindings and include them (or the signature) in the token
it sends. An alternative would be for the treatment of the channel
bindings to be mechanism specific and have Kerberos ignore everything
but the destination address. If an application wanted to securely
check such data, it would have to explicitly use the "sign" and
"verify" functions. This "works" and is less effort for Kerberos but
it makes the channel bindings of highly dubious value to applications.
I would note that it is not a GSSAPI issue but it *is* a telnet and
rlogin issue to decide what the application specific data will be. I'd
like to put port IDs there to the extent it's easy.
