Re: krb5dissect

[Russ Allbery]

Simon Josefsson <address@hidden> writes:

> As far as I can tell, 'klist' cannot output:

> * raw encryption keys for ccache
> * raw krb5 tickets

Ah, yes, this is true.  And I'm guessing that this probably wouldn't be
accepted as a change either, for various reasons.

> And generally its output is highly parsed and formatted compared to
> krb5dissect which just output the raw contents of the file.

Also certainly true.

> This discussion has made me realize that perhaps there is some other
> potential for krb5dissect, to convert ccache/keytab into a text format
> that can be transported, or possibly into/from a standard-format for
> transferring credentials (possibly IETF's keyprov, although they seem to
> use rather complicated XML to do this).  But I'm not sure it will be
> anything more than a debug tool to parse ccache/keytab's directly.

That would be interesting to me for other reasons.  WebAuth currently has
to serialize tickets into its token structure, and maintaining that code
is remarkably obnoxious and requires significant fiddling between
different versions of Kerberos.  Unfortunately, it needs to deal with
in-memory structures, so something that only reads disk files isn't a lot
of help.

See:

    <http://webauth.stanford.edu/protocol.html#krb5token>

for the encoding that WebAuth uses.

> Also, since the ccache/keytab format isn't a standard, it may be useful
> to have a decoder written the way I interpreted the format, and have
> 'klist' do whatever MIT thinks it should do.  MIT may enhance the
> format, and then being able to debug why Shishi doesn't handle new
> formats properly may be useful.

I certainly agree that having the code available is useful.  Separate
interoperable implementations are great.  I only wasn't sure about the
command-line utility itself.

> That's very good.  Is there any chance your pam_krb5 could become
> modular enough so that the krb5-specific calls are isolated and could be
> replaced?  Or do you think it is not worth the effort?  I don't have
> resources to work on pam_shishi/krb5 but perhaps a GSOC project is
> accepted to modularize pam_krb5 and add Shishi support.

I'm not sure.  It's borderline.  This is difficult to do right now given
the number of data structures that Kerberos libraries use and want code to
pass around.  The hardest part of writing a good abstraction layer over
the Kerberos library is dealing with the data structures, not with the API
calls.  It would certainly require starting with a high-level design and a
clear specification of what functionality one needs from the Kerberos
layer so that the code didn't make unwarranted assumptions.  Adding things
like PKINIT support will stress the compatibility layer a lot (MIT's
PKINIT branch and Heimdal's release candidates handle PKINIT in entirely
different ways).

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>