Creating a new pre-authentication plugin

[Alejandro Perez Mendez]

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

Indeed, this approach is also written down into the draft. We just shown 
our preference for the other alternative since we think GSS-preauth does 
not (theoretically) make the KDC statefull. The problem is that, seeing 
now that usually MIT Kerberos and other implemenations are linked with 
the GSS-API in an static way, the KDC would be becoming into a statefull 
element.

I agree we don't want that, so the partially established context might 
be a solution. Again, the major issue is that current GSS-API 
specifications do not allow this to be done. I don't know if any 
mechanism or mechglue would do it.

Regards

>
> Nico
> --