To: | krb5-bugs@MIT.EDU |
Subject: | gss serializer code missing some fields |
From: | Ken Raeburn <raeburn@MIT.EDU> |
Date: | Mon, 26 Jan 2004 16:05:47 -0500 |
This should get fixed for 1.3.2....
Ken
Return-Path: <krbdev-bounces@MIT.EDU>
Received: from po9.mit.edu (po9.mit.edu [18.7.21.65])
by po9.mit.edu (Cyrus v2.1.5) with LMTP; Wed, 21 Jan 2004 15:27:50 -0500
X-Sieve: CMU Sieve 2.2
Received: from fort-point-station.mit.edu by po9.mit.edu (8.12.4/4.7) id
i0LKRmrd001938; Wed, 21 Jan 2004 15:27:48 -0500 (EST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i0LKRXGk012027;
Wed, 21 Jan 2004 15:27:33 -0500 (EST)
Received: from pch.mit.edu (localhost [127.0.0.1])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i0LKQlqe021044;
Wed, 21 Jan 2004 15:27:19 -0500 (EST)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i0LKQiqb021040
for <krbdev@PCH.mit.edu>; Wed, 21 Jan 2004 15:26:44 -0500 (EST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
i0LKQhGk011069
for <krbdev@mit.edu>; Wed, 21 Jan 2004 15:26:43 -0500 (EST)
Received: from jurassic.eng.sun.com ([129.146.86.31])
by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0LKQg0H026885
for <krbdev@mit.edu>; Wed, 21 Jan 2004 12:26:42 -0800 (PST)
Received: from 192.129.100.95 (vpn-129-152-202-123.East.Sun.COM
[129.152.202.123])i0LKQbla343439
for <krbdev@mit.edu>; Wed, 21 Jan 2004 12:26:41 -0800 (PST)
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
To: krbdev@mit.edu
In-Reply-To: <1074696064.633.22.camel@pebblebeach.wki.test.net>
References: <005401c3dea6$ab1344d0$b285d38d@citi.umich.edu>
<1074696064.633.22.camel@pebblebeach.wki.test.net>
Message-Id: <1074716603.633.35.camel@pebblebeach.wki.test.net>
X-Mailer: Ximian Evolution 1.4.5
Date: Wed, 21 Jan 2004 15:23:23 -0500
Subject: Re: foolproof method of determining Kerberos version?
X-BeenThere: krbdev@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: wyllys.ingersoll@sun.com
List-Id: Kerberos Developers Mailing List <krbdev.mit.edu>
List-Help: <mailto:krbdev-request@mit.edu?subject=help>
List-Post: <mailto:krbdev@mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request@mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/krbdev>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request@mit.edu?subject=unsubscribe>
Sender: krbdev-bounces@MIT.EDU
Errors-To: krbdev-bounces@MIT.EDU
X-Spam-Score: -4.9
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Lines: 68
Xref: all-in-one list.mit.krbdev:7892 all.2004-01:1365
MIME-Version: 1.0
On Wed, 2004-01-21 at 09:41, Wyllys Ingersoll wrote:
I also noticed that the 'cksumtypes' field is also not covered by
the serialization code either.
Again, the solution can be to either copy the fields as part
of the internalize/externalize routines or to determine
the correct values in the 'internalize' routine by
checking the ctx->subkey->enctype field and setting them
accordingly.
For now, I added the following block to the end of 'kg_ctx_internalize'
(ser_sctx.c):
switch (ctx->subkey->enctype) {
case ENCTYPE_DES_CBC_MD5:
case ENCTYPE_DES_CBC_CRC:
case ENCTYPE_DES3_CBC_SHA1:
case ENCTYPE_ARCFOUR_HMAC:
ctx->proto = 0;
break;
default:
ctx->proto = 1;
kret = krb5int_c_mandatory_cksumtype(kcontext,
ctx->subkey->enctype,
&ctx->cksumtype);
break;
}
/* Get trailer */
-Wyllys
Received: from po9.mit.edu (po9.mit.edu [18.7.21.65])
by po9.mit.edu (Cyrus v2.1.5) with LMTP; Wed, 21 Jan 2004 15:27:50 -0500
X-Sieve: CMU Sieve 2.2
Received: from fort-point-station.mit.edu by po9.mit.edu (8.12.4/4.7) id
i0LKRmrd001938; Wed, 21 Jan 2004 15:27:48 -0500 (EST)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i0LKRXGk012027;
Wed, 21 Jan 2004 15:27:33 -0500 (EST)
Received: from pch.mit.edu (localhost [127.0.0.1])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i0LKQlqe021044;
Wed, 21 Jan 2004 15:27:19 -0500 (EST)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i0LKQiqb021040
for <krbdev@PCH.mit.edu>; Wed, 21 Jan 2004 15:26:44 -0500 (EST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
i0LKQhGk011069
for <krbdev@mit.edu>; Wed, 21 Jan 2004 15:26:43 -0500 (EST)
Received: from jurassic.eng.sun.com ([129.146.86.31])
by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0LKQg0H026885
for <krbdev@mit.edu>; Wed, 21 Jan 2004 12:26:42 -0800 (PST)
Received: from 192.129.100.95 (vpn-129-152-202-123.East.Sun.COM
[129.152.202.123])i0LKQbla343439
for <krbdev@mit.edu>; Wed, 21 Jan 2004 12:26:41 -0800 (PST)
From: Wyllys Ingersoll <wyllys.ingersoll@sun.com>
To: krbdev@mit.edu
In-Reply-To: <1074696064.633.22.camel@pebblebeach.wki.test.net>
References: <005401c3dea6$ab1344d0$b285d38d@citi.umich.edu>
<1074696064.633.22.camel@pebblebeach.wki.test.net>
Message-Id: <1074716603.633.35.camel@pebblebeach.wki.test.net>
X-Mailer: Ximian Evolution 1.4.5
Date: Wed, 21 Jan 2004 15:23:23 -0500
Subject: Re: foolproof method of determining Kerberos version?
X-BeenThere: krbdev@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: wyllys.ingersoll@sun.com
List-Id: Kerberos Developers Mailing List <krbdev.mit.edu>
List-Help: <mailto:krbdev-request@mit.edu?subject=help>
List-Post: <mailto:krbdev@mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request@mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/krbdev>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/krbdev>,
<mailto:krbdev-request@mit.edu?subject=unsubscribe>
Sender: krbdev-bounces@MIT.EDU
Errors-To: krbdev-bounces@MIT.EDU
X-Spam-Score: -4.9
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Lines: 68
Xref: all-in-one list.mit.krbdev:7892 all.2004-01:1365
MIME-Version: 1.0
On Wed, 2004-01-21 at 09:41, Wyllys Ingersoll wrote:
Show quoted text
> On Mon, 2004-01-19 at 11:09, Kevin Coffman wrote:
>
> I think there is another problem with the serialization routines
> (internalize/externalize) - they are not handling the new "proto" field.
> > CITI's NFSv4 code for Linux needs to pass GSS-API context information
> > to/from the kernel. This requires knowledge of the private Kerberos
> > structure krb5_gss_ctx_id_rec which is defined in
> > lib/gssapi/krb5/gssapiP_krb5.h. This structure changes in 1.3.2. Is there
> > a foolproof way to determine at compile-time and/or run-time what version of
> > Kerberos we are using so we can deal with this? Is there a better way for
> > us to deal with this?
> >
> > The [de]serialization routines don't help us since they keep the output
> > opaque.
> >
> > BTW, just looking at this, these routines don't appear to have been updated
> > to match the changes to the context structure changes in 1.3.2? i.e. the
> > code in kg_ctx_externalize() still assumes integers for initiate, seed_init,
> > and established.
> > > to/from the kernel. This requires knowledge of the private Kerberos
> > structure krb5_gss_ctx_id_rec which is defined in
> > lib/gssapi/krb5/gssapiP_krb5.h. This structure changes in 1.3.2. Is there
> > a foolproof way to determine at compile-time and/or run-time what version of
> > Kerberos we are using so we can deal with this? Is there a better way for
> > us to deal with this?
> >
> > The [de]serialization routines don't help us since they keep the output
> > opaque.
> >
> > BTW, just looking at this, these routines don't appear to have been updated
> > to match the changes to the context structure changes in 1.3.2? i.e. the
> > code in kg_ctx_externalize() still assumes integers for initiate, seed_init,
> > and established.
>
> I think there is another problem with the serialization routines
> (internalize/externalize) - they are not handling the new "proto" field.
I also noticed that the 'cksumtypes' field is also not covered by
the serialization code either.
Again, the solution can be to either copy the fields as part
of the internalize/externalize routines or to determine
the correct values in the 'internalize' routine by
checking the ctx->subkey->enctype field and setting them
accordingly.
For now, I added the following block to the end of 'kg_ctx_internalize'
(ser_sctx.c):
switch (ctx->subkey->enctype) {
case ENCTYPE_DES_CBC_MD5:
case ENCTYPE_DES_CBC_CRC:
case ENCTYPE_DES3_CBC_SHA1:
case ENCTYPE_ARCFOUR_HMAC:
ctx->proto = 0;
break;
default:
ctx->proto = 1;
kret = krb5int_c_mandatory_cksumtype(kcontext,
ctx->subkey->enctype,
&ctx->cksumtype);
break;
}
/* Get trailer */
-Wyllys
Show quoted text
>
> I suppose 'proto' could be set after the serialization by examining the
> enctypes (as its done in accept_sec_context, for example), but it should
> probably be serialized along with everything else in the structure.
>
> Also - the large block comment describing the contents to be serialized
> needs to be updated to show the new 64 bit values.
>
> -Wyllys
> I suppose 'proto' could be set after the serialization by examining the
> enctypes (as its done in accept_sec_context, for example), but it should
> probably be serialized along with everything else in the structure.
>
> Also - the large block comment describing the contents to be serialized
> needs to be updated to show the new 64 bit values.
>
> -Wyllys
Show quoted text
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev