Creating a new pre-authentication plugin

[Nico Williams]

On Wed, Aug 1, 2012 at 3:09 PM, Greg Hudson <ghudson at mit.edu> wrote:
> 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.

I'd be fine with a GSS extension by which to get secure object handles
as largish octet strings, otherwise I agree with Greg.

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

We could have some measure of automatic memory management in GSS
extensions, but none that could help with this.

But, we've discussed before the encrypted exported partially
established security context token approach.  I heartily recommend
that approach (and it should work even in cases where there's no easy
way to export the partially established context by simply recording an
address where the importer of the token can call by proxy to continue
the security context token exchange).

Nico
--