kerberos custom credential cache

On 9/26/06, J. Bruce Fields <bfields at fieldses.org> wrote:
> > >> Also, our site uses aes256 keys for everything, so I would like to
> > >> investigate what might be needed to support encryption types other
> > >> than single des, specifically types 16-18. Has anyone looked into
> > >> this?
> > >
> > >Yes, I'm working on it right now, but it may take some time.
> >
> > Is there anything I can do to assist the effort?
>
> My first draft of the triple-DES support is here:
>
> http://linux-nfs.org/cgi-bin/gitweb.cgi?p=bfields-2.6.git;a=shortlog;h=des3-support
>
> (I realize triple DES isn't the most desired; it was just easy to get
> started on.  Probably I should have gone ahead with AES first
> instead....)

Cool, I might give it a try.  3DES is at least better. Ill see if I
can get it going.

> We need to finish that and work on more algorithms.  That means:
>         - digesting the relevant kerberos rfc's
>         - getting the kernel<->gssd interface right.  I think it's
>           almost there, but I'm still a little confused about how to identify
>           encryption types.
>         - writing kernel code to handle the data exchange for the
>           various algorithms.

The Linux kernel has for some time had crypto modules, is there any
way we could leverage those? No sense in re-writing the algorithms if
we dont need to. Plus, if someone has hardware encryption (like the
Via Padlock chip) and a crypto module is written for that hardware,
you get to use it free!

> I'll try to post some design notes to the wiki as I go along to help
> anyone that wants to contribute.
>
> Information about which enctypes in particular people care about is
> useful.

There arnt too many out in the wild these days.  A list of all the
"known" enctypes are here:
http://www.iana.org/assignments/kerberos-parameters  I would say if
you stick to the RFC and Microsoft ones, you will cover most people
pretty well.

Jay

-- 
Jay Kline
http://www.slushpupie.com/