Skip Menu |
 

Download (untitled) / with headers
text/plain 12.5KiB
From ranous@hpindavg.cup.hp.com Fri Oct 4 20:07:23 1996
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id UAA23509 for <bugs@RT-11.MIT.EDU>; Fri, 4 Oct 1996 20:07:19 -0400
Received: from relay.hp.com by MIT.EDU with SMTP
id AA29792; Fri, 4 Oct 96 20:07:10 EDT
Received: from hpindavg.cup.hp.com by relay.hp.com with SMTP
(1.37.109.16/15.5+ECS 3.3) id AA097914028; Fri, 4 Oct 1996 17:07:08 -0700
Received: from localhost by hpindavg.cup.hp.com with SMTP
(1.38.193.4/15.5+IOS 3.20+cup+OMrelay) id AA10111; Fri, 4 Oct 1996 17:08:05 -0700
Message-Id: <9610050008.AA10111@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
Subject: GSSAPI RFC 1961 compliance?

Show quoted text
>Number: 59
>Category: krb5-libs
>Synopsis: GSSAPI RFC 1961 compliance?
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: marc
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Oct e 20:08:00 EDT 1996
>Last-Modified: Wed Nov 20 20:05:32 EST 1996
>Originator:
>Organization:
>Release: beta-7
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:

From: Marc Horowitz <marc@MIT.EDU>
To: Alex Ranous <ranous@hpindavg.cup.hp.com>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pending/59: GSSAPI RFC 1961 compliance?
Date: Sat, 05 Oct 1996 20:07:23 EDT

Show quoted text
>> I believe it would be realitively easy to modify the MIT GSSAPI to
>> handle clients who choose not to use subkeys.

The change you describe is straightforward, however, I'm not convinced
that, by itself, it is a good idea.

In fact, looking at the code, KG_NO_SUBKEY is only returned from one
place, and that is #if 0'd out. The code path which will happen if
there is no subkey looks like it will core dump; is this what's
happening for you? This is certainly a bug, and this PR should
continue to track it, since how we decide to deal with your issue will
determine how to fix the bug.

Show quoted text
>> 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.

The potential attack is the reverse. If the session key is used, and
the attacker managed (by theft or cryptanalysis) to determine the key,
then all sessions between the client and service are compromised, as
you point out. If a subkey is used, and this key is compromised, then
only that particular session is compromised. This is the advantage.

The problem I have with simply using the session key is that it has an
effect on the security level of the connection, and it is
traditionally the right of the server to make policy decisions on this
sort of thing. So, we could make your change, but I'd like to see
some way (even if it was krb5-mech-specific) to determine if a session
key or subkey was used.

Show quoted text
>> 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:

I'd question your use of the word "need" here (GSSAPI is still only a
proposed standard, so we're allowed to change things with good
reason). However, there may still be a way out of this. How do these
legacy DCE servers (I assume you mean legacy GSSAPI application
servers, not kdcs or anything) behave when they see a subkey in the
AP_REQ? krb5b7 copies the subkey from the AP_REP message to the
AP_REP message. If the DCE legacy code does something different, then
the DCE, and maybe MIT, initiators could be made to recognize the old
gssapi acceptors, and automagically do the compatible thing (use the
session key instead of the subkey. This means up-to-date gssapi peers
would use subkeys as intended, and newer initiators could talk to
older acceptors. Old initiators couldn't talk to newer acceptors, but
you didn't mention a requirement for that :-)

Marc

P.S. The bug is that krb5_auth_con_getremotesubkey() returns 0 even
when there is no subkey. This will cause gss_accept_sec_context() to
core dump when it references ctx->subkey->enctype. It's not
immediately clear to me if it's more correct to return an error code
from krb5_auth_con_getremotesubkey(), or to check the ctx->subkey
return.

Responsible-Changed-From-To: gnats-admin->marc
Responsible-Changed-By: hartmans
Responsible-Changed-When: Sat Oct 5 23:49:54 1996
Responsible-Changed-Why:
My understanding was that you were looking at this and were thinking about responding.


From: Alex Ranous <ranous@hpindavg.cup.hp.com>
To: Marc Horowitz <marc@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pending/59: GSSAPI RFC 1961 compliance?
Date: Mon, 07 Oct 1996 13:34:00 -0700

Show quoted text
> >> I believe it would be realitively easy to modify the MIT GSSAPI to
> >> handle clients who choose not to use subkeys.
>
> The change you describe is straightforward, however, I'm not convinced
> that, by itself, it is a good idea.
>
> In fact, looking at the code, KG_NO_SUBKEY is only returned from one
> place, and that is #if 0'd out. The code path which will happen if
> there is no subkey looks like it will core dump; is this what's
> happening for you? This is certainly a bug, and this PR should
> continue to track it, since how we decide to deal with your issue will
> determine how to fix the bug.

I actually haven't tested a DCE client with a DCE server, since personally all
I need to work is the reverse case, which I have working. I've submitted my
changes to necessary folks in HP to get this stuff put in DCE (I hope).

Show quoted text
> The problem I have with simply using the session key is that it has an
> effect on the security level of the connection, and it is
> traditionally the right of the server to make policy decisions on this
> sort of thing. So, we could make your change, but I'd like to see
> some way (even if it was krb5-mech-specific) to determine if a session
> key or subkey was used.

This may be so, the but RFC really doesn't make this clear. Pehaps the RFC
should say something like the server can specify a subkey in the AP-REP
response token and the client should honor this. Of course if the client
didn't request mutual authentication, that would be a problem. It's all
rather vague and can lead to implementation that don't interoperate.

Show quoted text
> >> 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:
>
> I'd question your use of the word "need" here (GSSAPI is still only a
> proposed standard, so we're allowed to change things with good
> reason). However, there may still be a way out of this. How do these
> legacy DCE servers (I assume you mean legacy GSSAPI application
> servers, not kdcs or anything) behave when they see a subkey in the
> AP_REQ? krb5b7 copies the subkey from the AP_REP message to the
> AP_REP message. If the DCE legacy code does something different, then
> the DCE, and maybe MIT, initiators could be made to recognize the old
> gssapi acceptors, and automagically do the compatible thing (use the
> session key instead of the subkey. This means up-to-date gssapi peers
> would use subkeys as intended, and newer initiators could talk to
> older acceptors. Old initiators couldn't talk to newer acceptors, but
> you didn't mention a requirement for that :-)

What the currently available DCE does now is completely ignore the subkey
entirely. What I've done is modify DCE to look at the subkey when accepting a
context, and if there, use that as the context key instead of the session key.
I've also modified DCE so that if accepting a context with the old mechanism
OID and using a subkey, to use the context key as the IV when computing
checksums so that DCE can talk to pre-beta 7 MIT clients.

Currently shipping DCE most likely don't support the new mechanism OID (it's
in the code but #ifdef out by default). What might be reasonable is to have
DCE generate subkeys when initiating contexts using the new OID, and not when
using the old one. This way new DCE clients can talk to new MIT and DCE
servers using the new OID, and legacy DCE servers using the old OID. The new
DCE servers could accept contexts from old and new DCE or MIT clients. A pre
B7 MIT server couldn't talk to any DCE client (the client wouldn't know which
IV to use). Similarly, a old DCE server could talk to any MIT client. If a
B7 MIT server wanted to talk to an existing DCE client, it would have to
recognize a connection from a client using the old mech OID and no subkey as a
DCE client, and to use the session key and a zero IV.

The tricky part is getting DCE to use subkeys when initiating a context, since
it appears that may be non-trivial in DCE's implementation of Kerberos. I'll
leave that to others to deal with. If DCE doesn't implement this, then some
sort of way of telling MIT GSSAPI to use the session key instead of the subkey
would be nice.

Alex


From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz N1NZU <marc@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/59: GSSAPI RFC 1961 compliance?
Date: Wed, 30 Oct 1996 18:38:28 -0500

`Theodore Y. Ts'o' made changes to this PR.

I've bumped the priority and severity levels of this PR, because we need
to deal with this before the 1.0 release. Marc, you were last looking
at this; are you still dealing with it?

- Ted

State-Changed-From-To: open-analyzed
State-Changed-By: marc
State-Changed-When: Tue Nov 5 18:53:02 1996
State-Changed-Why:

I'm going to change the MIT implementation to use the session key if
no subkey is present, as the RFC says. I don't quite agree with the
RFC, but it is the spec.

I'll be committing the patch in the next day or two.

State-Changed-From-To: analyzed-closed
State-Changed-By: marc
State-Changed-When: Wed Nov 20 20:05:01 1996
State-Changed-Why:

The patch is checked in on the 1.0 release
branch. (accept_sec_context.c:1.34.2.1)

Show quoted text
>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.