Creating a new pre-authentication plugin

[Greg Hudson]

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.

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

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