[48] in GSSAPI Development
Re: GSS-level token wrapping
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri May 17 23:43:32 1991
Date: Fri, 17 May 91 23:42:34 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Wray, Secure Systems Development, DTN 226-6106 16-May-1991
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106 16-May-1991 1023's message of Thu, 16 May 91 16:30:50 PDT,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Thu, 16 May 91 16:30:50 PDT
From: "John Wray, Secure Systems Development, DTN 226-6106 16-May-1991 1023" <wray@ultra.enet.dec.com>
Also, don't think that there's any suggestion that the token itself
need to be encoded in BER. Only the relatively simple GSSAPI header
is expressed in ASN.1 - the rest of the token is "free-form".
The GSSAPI header is small enough (and constant enough) that we
expect that an implementation should have no trouble using it, even
if the inner-token format doesn't (and doesn't want to) use ASN.1.
Note that if it's encoded in BER, it will certainly not be constant and
may not even be small.... for example, there are 127 ways of encoding a
small integer, taking up to an extra 128 bytes of overhead. To wit: the
following is a valid ASN.1 BER encoding of "42"....
2,1,254,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,42
.... and a valid parser of BER ASN.1 has to be able to accept the above,
as well as....
2,1,253,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,42
... and over a hundered other ways of encoding the integer 42.
The same mess can also be applied to OID's --- there are 127 different
ways of encoding any arbitrary OID (assuing it has less than 255
components; if it has between 256 and 65535 components, there are 126
different, distinct ways of encoding it). This is why I suggested that
we mandate that the header (or at least the portion specified by the
"GSS API" documents) be encoded in DER. At least there is one
inefficient way of encoding any object, instead of 127 different
inefficient ways.
If the initial portion of the header is encoded in DER, it would
eliminate the requirement that the GSS API token parser understand
ASN.1. It would be possible to treat an initial string of bytes as a
constant indentifier for "Kerberos" or "SPX", instead of needing to go
through a painful mess of decoding BER. In fact, I would suggest that
the GSS API specification include how to construct the constant string
that would correspond to the DER encoding of the GSS API token header
for a given OID. This way, someone would be able to implement the GSS
API without needing to pay $$$ and go through a lot of bother to obtain
the ASN.1 specifications.
- Ted
P.S. Actually, I may be mistaken. There may be an infinite number of
ways of expressing any object in BER; it's a question of whether or not
an encoding of the form:
31, 128, 128, 128, ... , 128, 2, 1, 42
is a valid way of expressiong the integer 42. It seems to be valid, but
I'm not positive of that. If it is valid, then there is a infinite (but
still countably infinite, thank goodness!) ways of encoding the integer
42.
Yes, I'm being facetious, but the point remains that BER is a bad idea,
and I'd strongly argue for something a little bit more reality-oriented.
A DER-encoded header is still derived from ASN.1, but it has the
advantage that it is possible to ignore its ASN.1 ancestry in some
cases.
