[16480] in Kerberos_V5_Development
Re: X-CACHECONF in cache type 0504
daemon@ATHENA.MIT.EDU (Weijun Wang)
Fri Nov 19 09:14:02 2010
Message-ID: <4CE5ECA3.9010600@oracle.com>
Date: Fri, 19 Nov 2010 11:18:59 +0800
From: Weijun Wang <weijun.wang@oracle.com>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <1290104141.2633.1197.camel@ray>
Cc: "krbdev@MIT.EDU" <krbdev@mit.edu>, Tim Alsop <tim@cybersafe.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
