Creating a new pre-authentication plugin

[Nico Williams]

On Wed, Aug 1, 2012 at 12:45 PM, Alejandro Perez Mendez <alex at um.es> wrote:
> El 01/08/12 17:16, Greg Hudson escribió:
>> * KDC statelessness is a serious concern for us, just as it was within
>> the IETF working group.  The draft argues that the KDC should not be
>> considered "stateful" because the state lies within the GSSAPI objects,
>> but that position does not resolve the practical issues which give rise
>> to the statelessness requirement.
>
> That's something still under discussion into the IETF, though in the
> last discussion we more or less agreed that it would be something
> depending on how the GSS-API is implemented. From a specification point
> of view, the state is GSSAPI's responsibility.

I believe statelessness here requires that each hop be able to be
performed against different KDCs.  This is important to me and to
others.  I recommend you pursue the exported partially established
security context token approach to retain statelessness, which I think
is eminently feasible (and would benefit us all in other ways).

> If we assume the GSS-API is linked statically and locally with the KDC
> process, meaning that when the KDC process stops, all the GSS-API is
> lost, I can only think on two problematic situations:
>
> 1) The client tries to continue the pre-authentication with a different
> KDC: I haven't checked it yet, but seems reasonable that try_again()
> function uses the existing socket to send the subsequent AS_REQ
> messages, thus resulting into the client going to the exact same KDC.
> Thus this situation would be avoided in MIT KRB.

The KDC is free to close the connection immediately after sending a
KDC-REP.  There are good reasons for the KDC to want to do so, namely
to reduce the duration of resource consumption by clients.  Even if
the KDC didn't close the connection immediately it would still want to
have an LRU queue for closing connections.  Associating krb5 gss
pre-auth with connection state seems risky: clients might never finish
when the KDC is under stressful load, thus contributing to more stress
as they retry.

>> * How do we prevent loops where the client attempts to use gss-krb5 to
>> satisfy the preauth mechanism and that devolves into another AS request?

There is no more cause to loop infinitely here any more than TGS-REQ's
PA-TGS's use of AP-REQ, or FAST AS-REQs using armor tickets.

Nico
--