[2295] in Kerberos-V5-bugs
pending/59: GSSAPI RFC 1961 compliance?
daemon@ATHENA.MIT.EDU (Alex Ranous)
Fri Oct 4 20:08:15 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: gnats-admin@rt-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, Alex Ranous <ranous@hpindavg.cup.hp.com>
Date: Fri, 04 Oct 1996 17:08:05 -0700
From: Alex Ranous <ranous@hpindavg.cup.hp.com>
To: krb5-bugs@MIT.EDU
>Number: 59
>Category: pending
>Synopsis: GSSAPI RFC 1961 compliance?
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Oct e 20:08:00 EDT 1996
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
Now that the MIT Kerberos 5 Beta 7 GSSAPI implements RFC 1964 correctly (it
uses a zero IV when calculating checksums), I'd thought that I'd revisit the
issue of DCE GSSAPI/MIT GSSAPI interoperability. I've identified a numbe of
problems. Some of these are DCE problems that I've fixed and have submitted
to the "proper" authorties.
One problem I ran against was that MIT GSSAPI specifies a subkey in the
authenticator when initiating a request. Unfortanately, DCE completely
ignores the subkey, only using the session key in the ticket for the context
key. I've added support to DCE to handle the subkey whan accepting a context.
The problem I have now is that DCE can't generate a subkey when initiating a
context since it needs to be able to work with legacy DCE based server that
don't support use of subkeys. The MIT code expects to see a subkey when
accepting a context, and returns an error if it's not there. This appears to
violate the RFC. In section 1.2:
(1) context key: uses Kerberos session key (or subkey, if
present in authenticator emitted by context initiator) directly
This seems to say that it is up the the initiator whether or not a subkey
should be used as the context. DCE violated this by ignoring the subkey. It
appears the MIT also violates this by ignoring it's absense. On the other
hand, there is a GSS_KRB5_S_KG_NO_SUBKEY defined by the standard, which
implies that it might be ok to do this.
I believe it would be realitively easy to modify the MIT GSSAPI to handle
clients who choose not to use subkeys. Currently in accept_sec_context.c,
krb5_auth_con_getremotesubkey() is called, and if there isn't a subkey, the
GSS_KRB5_S_KG_NO_SUBKEY error is returned.
It seems reasonable that if there is no subkey, then call
krb5_auth_con_getkey() to get the session key and use that in ctx->subkey
instead. This should allow a DCE based client to interoperate with a MIT
server.
Does this seem reasonable?
Alex
BTW, I'm not sure why the MIT bits are using a subkey in the first place. It
doesn't seem to be adding any security. If the session key is vulnerable,
then the subkey could be retrieved from the authenticator anyway.
