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

[Greg Hudson]

On Fri, 2010-04-30 at 12:23 -0400, Jeff Blaine wrote:
> 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).

Well, you need some way of creating an armored channel.  For the moment,
that means the client API consumer needs to provide an armor ticket.

The preauth framework draft envisions using anonymous PKINIT when no
armor ticket is available.  We have anonymous PKINIT support in krb5
1.8, but haven't connected the dots to FAST.  There are some performance
implications (public key operations being substantially more expensive
than the symmetric key operations used in a traditional AS exchange)
which might get in the way of full transparency even if we did implement
this.

A future option is using some form of Encrypted Key Exchange (EKE),
which is a name for a family of techniques for establishing a temporary
key based on a shared secret without exposing that secret to offline
attack.  There is a bit of a patent minefield in this area, though it
may be navigable later this year.  EKE techniques tend to involve some
variation on a Diffie-Hellman exchange, so are still more
computationally expensive than a traditional AS exchange, but they would
be less subject to a man-in-the-middle attack than anonymous PKINIT
would.