Creating a new pre-authentication plugin

[Alejandro Perez Mendez]

On 02/08/12 03:15, Nico Williams wrote:
> 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).

The problem with this approach is that current GSS-API specification 
does not allow the exportation of partially established contexts. Apart 
from that, I'm starting to think this is the most feasible solution due 
to the specific problems with statically linked GSS implementations.

>
>> 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.

Well, as I see it, it more is a matter of client behaviour. The KDC can 
drop the connection whenever it wants, is the client who has to send the 
next request to the same KDC. Besides, we are talking here of UDP 
connections, which are not indeed proper connections.

>>> * 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
> --