preauth (I'm a Roomba in a 2'x2' room)

[Jeff Blaine]

On 4/30/2010 12:02 PM, Greg Hudson wrote:
> Encrypted challenge replaces encrypted timestamp when FAST is used.  It
> has all the nice properties of encrypted timestamp, plus it doesn't
> expose the user's password to an offline attack (unless the attacker has
> access to the armor key).  Since FAST was not in use in your test,
> fast_kdc_get_armor_key() returned a null armor key and the plugin
> returned ENOENT.
> 
> Getting FAST to happen is actually relatively easy.  It's enabled in the
> KDC by default.  The client will use it whenever it has access to an
> "armor ticket".  The armor ticket is ideally obtained with a
> high-quality key such as a host keytab, but any valid ticket will work,
> so you can just get credentials the normal way and use them:
> 
>   kinit username
>   kinit -T /path/to/my/ccache username
> 
> If username has the preauth_required bit set, then the second kinit
> should use encrypted challenge (assuming it doesn't have the
> configuration necessary to use PKINIT).

This works, thank you.

I guess I completely misunderstand FAST then, because I thought
it was something transparent to the user and just a framework
(within the scope of preauth plugins) for handling secure
conversations with the KDC.  That's the way the RFC draft
reads to me at least.  So, it's clear now that it's not
transparent really (a 2-step process instead of 1 above).