[5790] in Kerberos
problems with rfc vs krb5b5 api types
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Fri Aug 25 17:17:29 1995
To: krb5-bugs@MIT.EDU
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 */
and for last request field type, there is no type, but here's the
relevant struct:
typedef struct _krb5_last_req_entry {
krb5_magic magic;
krb5_octet lr_type;
krb5_timestamp value;
} krb5_last_req_entry;
The first problem is simple: For the first four types, there is no way
for an application to specify a negative value for the type, since the
types themselves are unsigned. The last two are just weird, as there
is no reason for the preauth type to be a specific length, and I
assume krb5_octet is just an arbitrary implementation artifact.
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.
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.)
Marc
