Creating a new pre-authentication plugin

[Alejandro Perez Mendez]

El 01/08/12 21:09, Greg Hudson escribió:
> On 08/01/2012 03:03 PM, Alejandro Perez Mendez wrote:
>>> Accepting pointer values from
>>> the client would open up the KDC to memory attacks.
>> Again, that's a matter of implementation.
> Yes, but we know what our implementation is, and it uses pointer values.

Right.

>> Anyway, IMO that kind of memory attacks (i.e. context does not exists)
>> SHOULD be handled at a GSS-API level.
> As far as I'm aware, there's no good way to do this in a library GSSAPI
> implementation.  Back before we had a mechglue, we used to have a table
> of valid pointer values, but that required global synchronization for
> every GSSAPI call.

A (hash) table of valid pointers seems reasonable to me. I think 
mechglue could have such a table.
What do you mean with global synchronization? Do you mean locks, 
semaphores and related multi-thread/multi-process stuff? I understand 
you had strong reasons for this decision, but I don't completely 
understand them.

Anyway, COOKIEs must be protected (i.e. encrypted), thus clients cannot 
modify data inside.

>>> The KDC would also need some way to release abandoned GSSAPI handles.
>> Yes, this would be the more problematic issue. I need to figure out how
>> to solve this. But, just asking, isn't it a problem that GSS-API
>> implementation has to deal with?
> No, or there wouldn't need to be gss_release_ functions.

I we had the table of valid handlers, we could add a expiration time. 
 From time to time, mechglue can lookup for expired contexts and delete 
them. Though I think this may be highly inefficient.

>>> Second, sending two requests on the same UDP socket does not guarantee
>>> that the same KDC process handles them.  There could be multiple worker
>>> processes serving the same socket (see the man page documentation of
>>> krb5kdc -w), or there could be a network element (like an F5)
>>> distributing requests on the same IP and port to different real KDC
>>> hosts.
>> Again, just asking, wouldn't these workers share the same GSS-API memory
>> space? Wouldn't mech_glue be the same for all of them?
> No, in both cases.  KDC worker processes have distinct address spaces,
> and of course if a network element is distributing requests to different
> real KDC hosts, they will have distinct address spaces by virtue of
> being on different machines.
>
So, although theoretically GSS preauth does not make the KDC statefull, 
implementing it on MIT Kerberos actually makes it.

In that case, the GSS-preauth draft says:

    On the other hand, others think that the GSS-API must be considered
    as a library that is executed within the same thread or process as
    the calling application (the KDC in this specific case).  If such is
    the assumption, then the KDC will be indeed storing the state
    associated to the security contexts, making it statefull.  In that
    case, it would not be enough building the PA-FX-COOKIE padata just
    with the context_handle, as it could not be possible to recover the
    whole state of the KDC plus GSS-API from that information.  On the
    contrary, the whole GSS-API security context must be serialized and
    included into the cookie.  In order to prevent replay attacks, the
    PA-FX-COOKIE MUST also contain a time-stamp.  Furthermore, since
    critical information may be contained in the exported security
    context, the data contained in the PA-FX-COOKIE MUST be
    confidentiality and integrity protected using a key shared amongst
    all the KDCs deployed in the realm.


The problem with this approach is that exporting partially established 
contexts is something not allowed by current GSS-API specification.

Regards,
Alejandro