X-CACHECONF in cache type 0504

[Weijun Wang]

Hi Greg

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?

Thanks
Weijun

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
> principals.
>
>> 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
> https://mailman.mit.edu/mailman/listinfo/krbdev