Creating a new pre-authentication plugin
Alejandro Perez Mendez
alex at um.es
Thu Aug 2 03:44:11 EDT 2012
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.
>> 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
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
>> 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.
More information about the krbdev