[1608] in Kerberos-V5-bugs
Re: problems with rfc vs krb5b5 api types
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Aug 25 18:08:38 1995
Date: Fri, 25 Aug 1995 18:04:40 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: Marc Horowitz <marc@cam.ov.com>
Cc: krb5-bugs@MIT.EDU, kerberos@MIT.EDU, cat-ietf@MIT.EDU
In-Reply-To: Marc Horowitz's message of Fri, 25 Aug 1995 17:17:48 -0400,
<199508252117.RAA19333@dun-dun-noodles.cam.ov.com>
Cc: kerberos@MIT.EDU, cat-ietf@MIT.EDU
Date: Fri, 25 Aug 1995 17:17:48 -0400
From: Marc Horowitz <marc@cam.ov.com>
In RFC 1510, there are a number of types which have semantics
associated with sign. These are:
host address types (addr-type member of HostAddress and HostAddresses)
encryption key type (keytype member of EncryptionKey)
checksum type (cksumtype member of Checksum)
the authorization data type (ad-type member of AuthorizationData)
padata type (padata-type member of PA-DATA)
last request field type (lr-type member of LastReq)
In krb5.h, the corresponding C types are:
typedef unsigned int krb5_addrtype;
typedef unsigned int krb5_keytype;
typedef unsigned int krb5_cksumtype;
typedef unsigned int krb5_authdatatype;
typedef krb5_int32 krb5_preauthtype; /* This may change, later on */
Yes, this is a problem which is directly related to a previous
implementer of Kerberos V5 at MIT being a bonehead. It's not directly a
bug, per se, since it merely means that the current implementation
cannot support local types. It will be fixed at some point in the
future.
The second problem is more difficult: In the case of the checksum data
passed to krb5_mk_req_extended(), there's no way for an application to
pass in local checksum data, since the in_data argument is always
passed to krb5_calculate_checksum() (except when the cksumtype is
0x8003, which is a case I'll get to later). I suspect that this
problem extends to other parts of the api for the other types in
question, although I haven't actually checked to verify this. Just to
complicate things, there are export considerations for an API which
allows arbitrary checksum values to be passed into
krb5_mk_req_extended(), since this field is encrypted on the wire.
The reason why it wasn't allowed was (1) to simplify the API, and (2)
more importantly, because of the export considerations which you
mentioned.
Now, on to GSSAPI. GSSAPI defines a "local" checksum type for the
checksum it passes as a part of its AP-REQ. Quoting from the latest
i-d:
The checksum will have a type of 0x8003 (within the set of negative
16-bit values reserved by Kerberos for application use)
Unfortunately, a major oversight seems to have occurred. Nowhere in
RFC1510 does it say that the checksum type values are 16 bits long.
In fact, the ASN.1 type of the checksum type (and all of the types
listed above) is INTEGER, which can be up to 1023 bits long, if I
remember my ASN.1 correctly. (I suspect that the source of the 16 bit
number is an earlier krb5 release. Until krb5b4, krb5_cksumtype was a
typedef for krb5_ui_2, which is an unsigned 2-byte (16-bit) value.)
I don't know exactly what krb5b4 does with 0x8003 when encoding it.
(I tried to look at the code, but it's pretty ugly.) But krb5b5 will
treat it as a positive value. This is clearly incorrect. It will
take some more investigation of what needs to be done to keep backward
compatibility, if we decide this is sufficiently important. (One
possibility is to request that MIT allocate 0x8003 as an official
checksum type, legislating the problem out of existence.)
We would have been much better off if the Kerberos GSSAPI had used an
officially assigned number; so my suggestion would be to either (a)
assign a new checksum number for the Krb5 GSSAPI, like 0x9 or 0xa
(whichever is the next unsed number), or (b) if we care about
maintaining backwards compatibility, allocating or reserving 0x8003 so
it doesn't get allocated by anyone else.
- Ted
