Credential cache file format documentation
Tim Alsop
Tim.Alsop at CyberSafe.Com
Wed Sep 13 12:31:13 EDT 2006
Simon,
Thanks. This makes sense and is consistent with what we concluded when
looking into this by checking MIT code.
For cache type 1,2 and 3 we currently store deltatime info in a hidden
ticket in the cache, and we also store the IP address of the KDC where
the time offset came from. The deltatime header tag does not currently
allow any way to store this ip address, so this is what we were thinking
of adding, into a new tag. From what you said, and from what we have
observed, the MIT code will ignore any tags it does not recognise. We do
also, in case somebody else uses these tags for propriatory reasons.
Thanks again,
Tim
-----Original Message-----
From: Simon Josefsson [mailto:jas at extundo.com]
Sent: 13 September 2006 17:20
To: Tim Alsop
Cc: kerberos at mit.edu
Subject: Re: Credential cache file format documentation
Tim,
As far as I know, the header tags are not described anywhere.
I have looked at both the MIT and Heimdal source code, and they appear
to skip any unknown tags properly. So it would appear possible to add
a new tag without causing problems in existing MIT/Heimdal clients. I
have not tested this though.
The ccache format is less flexible than the Shishi ticket file format,
so to be able to fully switch to the ccache format in Shishi, I may
add a header tag to store additional information that Shishi can
understand. I'm still quite skeptical about this though; we'll likely
only read/write the ccache format for compatibility and not use it as
the real ticket file, and in that case, there is no need to duplicate
the information in the ccache file. But this is still an open
question.. it may be an issue that the key is stored in two different
files.
If you experiment with new tags, I'd be interested to hear about it if
you run into any problem.
I have updated the description with more details about header tags,
and some notes about the DeltaTime tag, see:
http://josefsson.org/shishi/ccache.txt
Thanks for your comments!
/Simon
"Tim Alsop" <Tim.Alsop at CyberSafe.Com> writes:
> Simon,
>
> If you can, it would be useful if you can document the cache type
0x0504
> differences, e.g. what the header tag/tags contain, and in what
format.
> We recently made some changes to our products, and in order to test
the
> cache interoperability I tried to find documentation on the header
tags,
> but couldn't. We are also considering adding a new header tag but
cannot
> do this without understanding if there are any interop issues that
this
> may cause. I could not find any doc which indicates whether it is
> possible to add additional information into a cache header, if cache
> type is 0x0504. Do you know whether this is described anywhere ?
>
> Thanks,
> Tim
>
> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> Behalf Of Simon Josefsson
> Sent: 13 September 2006 16:44
> To: kerberos at mit.edu
> Subject: Credential cache file format documentation
>
> Inspired by Michael B Allen's writeup of the keytab file format posted
> to this list a few months ago, which allowed me to implement support
> for reading keytab's in Shishi, I became interested in documentation
> of the ccache file format.
>
> I didn't find much documentation, but the format was pretty
> straight-forward, so I wrote the following description of it. If
> someone is looking for the same thing, I'd thought I'd share this. To
> read it, it probably helps to have read Michael's keytab.txt first.
>
> As you'd might suspect, this is the first step towards reading (and
> possibly writing) ccache files in Shishi...
>
> Enjoy,
> Simon
>
> The Kerberos Credential Cache Binary File Format
> Copyright (C) 2006 Simon Josefsson <simon josefsson.org>
> http://josefsson.org/shishi/ccache.txt
> Last updated: Wed Sep 13 17:11:53 CEST 2006
>
> Like the MIT keytab binary format (see Michael B Allen's reverse
> engineered description in keytab.txt), the credential cache format is
> not standard nor documented anywhere.
>
> In C style notation, the MIT credential cache file format is as
> follows. All values are in network byte order. All text is ASCII.
>
> ccache {
> uint16_t file_format_version; /* 0x0504 */
> uint16_t taglen; /* only if version is 0x0504
*/
> header tags[]; /* only if version is 0x0504
*/
> principal primary_principal;
> credential credentials[*];
> };
>
> credential {
> principal client;
> principal server;
> keyblock key;
> times time;
> uint8_t is_skey; /* 1 if skey, 0 otherwise */
> uint32_t tktflags;
> uint32_t num_address;
> address addrs[num_address];
> uint32_t num_authdata;
> authdata authdata[num_authdata];
> countet_octet_string ticket;
> countet_octet_string second_ticket;
> };
>
> keyblock {
> uint16_t keytype;
> uint16_t etype; /* only present if version
> 0x0503 */
> counted_octet_string keyvalue;
> };
>
> times {
> uint32_t authtime;
> uint32_t starttime;
> uint32_t endtime;
> uint32_t renew_till;
> };
>
> address {
> uint16_t addrtype;
> counted_octet_string addrdata;
> };
>
> authdata {
> uint16_t authtype;
> counted_octet_string authdata;
> };
>
> header {
> uint16_t tag; /* 1 = DeltaTime */
> uint16_t taglen;
> uint8_t tagdata[taglen]
> };
>
> DeltaTime {
> uint32_t time_offset;
> uint32_t usec_offset;
> };
>
> principal {
> uint32_t name_type; /* not present if version 0x0501 */
> uint32_t num_components; /* sub 1 if version 0x501 */
> counted_octet_string realm;
> counted_octet_string components[num_components];
> };
>
> counted_octet_string {
> uint32_t length;
> uint8_t data[length];
> };
>
> Permission to copy, modify, and distribute this document, with or
> without modification, for any purpose and without fee or royalty is
> hereby granted, provided that you include this copyright notice in ALL
> copies of the document or portions thereof, including modifications.
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
More information about the Kerberos
mailing list