Automatic FAST via Anonymous PKINIT

[Nathaniel McCallum]

On Tue, 2014-05-20 at 14:59 -0400, Nathaniel McCallum wrote:
> FAST is useful, especially for OTP. But FAST is also difficult to get
> setup. In the FreeIPA community, we work around this problem by using
> SSSD on the client-side and it establishes FAST automatically. However,
> kinit doesn't work. Making this process not only smoother, but with a
> similar behavior to what web-user expect is highly desirable. To this
> end, I would like to propose a design for a zero-conf client FAST
> channel. This breaks down into three distinct tasks: client behavior,
> client trust and server policy.
> 
> === CLIENT BEHAVIOR ===
> 
> The client should detect the following state:
> 1. Preauth is required.
> 2. FAST is offered.
> 3. No known preauth mechs are offered.
> 
> Currently, when this state exists, the client fails to authenticate. I
> would like to propose that when this state exists, the client should
> instead attempt to perform anonymous PKINIT and use the resulting ticket
> to establish the FAST channel to find if new preauth mechs are
> available.

Further thought has, I think, recognized a further problem with this
proposal. State attribute #3 needs to be clarified as: "No known preauth
mechs are offered except anonymous-only PKINIT." A quick perusal of RFC
6112 does not seem to provide any way for the client to detect if what
is being offered is regular PKINIT, anonymous-optional or anonymous-only
PKINIT.

In other words, the client cannot detect whether or not it should use
PKINIT directly or should use PKINIT to gain an anonymous ticket to
establish FAST to find more preauth mecs.

The easiest solution to me seems to be the creation of a new padata id
which implies that the PKINIT is anonymous-only PKINIT.

Thoughts?

Nathaniel