[1375] in Kerberos_V5_Development
Re: kdc performance and rcache
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Jul 3 11:58:40 1996
Date: Wed, 3 Jul 1996 11:58:18 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Ken Raeburn
<raeburn@cygnus.com>,
"Donald T. Davis" <don@cam.ov.com>, "Barry
Jaspan" <bjaspan@MIT.EDU>,
krbdev@MIT.EDU
In-Reply-To: Bill Sommerfeld's message of Wed, 03 Jul 1996 10:22:56 -0400,
<199607031423.OAA03145@orchard.medford.ma.us>
Date: Wed, 03 Jul 1996 10:22:56 -0400
From: Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>
The only question is whether making this change would cause existing
implementations to core dump, but my guess is it's very likely we can
change what the KDC encodes in the last-req field without any problems.
I'm not looking at the code right now, but I suspect that the current
DCE encoder implementation is likely to reject a zero-length ASN.1
timestamp (albeit without coredumping) -- the decode of the entire
message will fail if the decode of any subfield fails...
No, not a zero-length timestamp --- but rather a zero length array of
last_req objects. The relevant ASN.1 is:
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type[0] INTEGER,
lr-value[1] KerberosTime
}
EncKDCRepPart ::= SEQUENCE {
key[0] EncryptionKey,
last-req[1] LastReq,
....
}
The question is how will the DCE decoder accept a zero-element SEQUENCE
for LastReq. Obviously, zero-length ASN.1 timestamp is illegal.
- Ted
