X-CACHECONF in cache type 0504
weijun.wang at oracle.com
Thu Nov 18 22:18:59 EST 2010
I'm a member of the Java SE Security Team in Oracle. We're aware of this
issue and about to fix it.
Java 1.6 currently just reads all entries as normal credential cache. It
fails on the new type of entry when trying to interpret the last 2
fields as ticket and second ticket. For the new entry, the field used to
be the ticket is a 3-bytes sequence which is not a DER encoding at all.
We have several solutions:
1. Ignore any unparseable entry. This is not perfect coz we cannot
detect illegal entries.
2. Ignore entries whose service principle name starts with
"X-CACHECONF:/". This should fix the current issue, but I'm not sure if
there will be more "strange" entries later.
What's your suggestion? and how does MIT handles a ccache file?
On 11/19/2010 02:15 AM, Greg Hudson wrote:
> On Thu, 2010-11-18 at 08:57 -0500, Tim Alsop wrote:
>> Why was 0504 cache type format changed, thus breaking interoperability
>> with other code which uses same cache type ?
> The cache format was not changed incompatibly. The additional
> information is encoded as credential entries for oddly-named server
>> Basically if MIT code is used to create the cache, the Java 1.6 code
>> cannot recognise the TGT unless the cache entries are renewed to
>> remove the extra information added by MIT.
> If so, I would expect that to reflect a bug in the Java 1.6 code; it
> should see a config entry as just another credential for a service it
> doesn't care about. Obviously, had we been aware of such a bug at the
> time we added the cache config support, we would have attempted to work
> around it.
> krbdev mailing list krbdev at mit.edu
More information about the krbdev