[5558] in Kerberos
Re: What is a GSSAPI channel binding?
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Wed Jul 26 11:12:41 1995
To: kerberos@MIT.EDU
Date: 26 Jul 1995 14:50:26 GMT
From: marc@cam.ov.com (Marc Horowitz)
>> The gss-sample application that comes with Kerberos 5 beta 5, though,
>> uses no channel bindings, and yet it works. So it's not necessary
>> to pass the information even if the underlying mechanism needs it.
>> (If it were, channel bindings could not be optional.)
That is correct. Channel bindings are not required by the kerberos
mechanism. Here's the relevant text from the internet draft:
When input source address channel binding values are provided by a
caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
source address specifier value within the input structure is
GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
context's peer bears address restrictions, it is recommended that an
implementation of the Kerberos V5 GSS-API mechanism should check that
the source address as provided by the caller matches that in the
received token, and should return the GSS_S_BAD_BINDINGS major_status
value if a mismatch is detected.
>> krb5_gss_accept_sec_context(), in fact, will pull the address from the
>> channel binding into a krb5_address, but then returns without doing
>> anything with it (it has local scope). All it seems to do is checksum
>> the channel binding, not actually use its contents.
That's because whoever ported the code from krb5b4 to krb5b5 blew it.
When I originally wrote the code, the paddr variable was passed to
krb5_rd_req(), and if the message came from the wrong host,
gss_accept_sec_context would return an error. The beta5 behavior is
wrong, and will need to be fixed.
>> This is consistent with the fact that Kerberos tickets and
>> authenticators are already keyed to particular addresses. So it seems
>> that the gssapi_krb5 library doesn't actually add any security when
>> you use channel bindings.
If you use the b5 gssapi code, the address in the authenticator is
never checked, so that bit of security is actually lessened. Once the
code is fixed, passing in the channel bindings will add value.
>> But my question was: If other protocols have the ability to choose
>> at the time data is sent whether it should be channel-bound or not,
>> shouldn't it be an option to gss_seal() and gss_sign(), instead of being
>> set at the time a security context is initiated? Or do channel bindings
>> apply to the token, not to the application data? If this seems unclear,
>> it's because I'm confused about what a channel binding actually does.
Channel bindings currently apply to context initiation, not to
per-message tokens. If you want to confirm that a per-message token
(that is, sign or seal) comes from the right ip address, then you
should pass channel bindings into gss_init_sec_context() and
gss_accept_sec_context(), and make sure that the source address of the
per-message tokens matches the source address of the context
initiation tokens.
I'm unaware of a protocol which has channel-binding data in each
message, *and* allows this channel-binding data to be different across
different messages in the same context. If I'm wrong, then you're
right, and the current API is inadequate. You'll notice that GSSAPI
is only a proposed standard, which means it can be revised if
necessary. Those of us working on it are not omniscient, and it's
entirely possible we missed something. But we'll need some pretty
strong convincing.
Marc
