Creating a new pre-authentication plugin

[Alejandro Perez Mendez]

El 01/08/12 19:01, Greg Hudson escribió:
> On 08/01/2012 01:45 PM, Alejandro Perez Mendez wrote:
>> That's something still under discussion into the IETF, though in the
>> last discussion we more or less agreed that it would be something
>> depending on how the GSS-API is implemented. From a specification point
>> of view, the state is GSSAPI's responsibility.
> The KDC would still need state mapping client cookies onto GSSAPI
> handles, which are typically pointers.

There is no need to do that if we use the value of gss_ctx_id_t into the 
COOKIE. That's exactly the amount of information the KDC needs to 
continue the process.

> Accepting pointer values from
> the client would open up the KDC to memory attacks.

Again, that's a matter of implementation. Assuming gss_ctx_id_t is a 
pointer, is knowing too much about how the GSS is implemented (according 
to RFC 2744 it could be an arithmetic value). I think that, from a KDC 
point of view, GSS preauth MUST not care about how GSS-API handles 
contexts. the COOKIE contains the value of gss_ctx_id_t.

Anyway, IMO that kind of memory attacks (i.e. context does not exists) 
SHOULD be handled at a GSS-API level. Indeed, GSS_S_NO_CONTEXT is a 
possible error code for GSS calls.

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

>> 1) The client tries to continue the pre-authentication with a different
>> KDC: I haven't checked it yet, but seems reasonable that try_again()
>> function uses the existing socket to send the subsequent AS_REQ
>> messages, thus resulting into the client going to the exact same KDC.
>> Thus this situation would be avoided in MIT KRB.
> First of all, that's not the current design; each krb5_sendto_kdc()
> operation does its own KDC address resolution state and sockets.  I
> would like to see our library design change so that we use the same
> address for all KDC-REQs of an AS exchange, but it would be a lot of
> work and it wouldn't be sufficient to make KDC statefulness okay.

Sure, but at least the "atomicity" (in the sense of keeping the same 
peers) of the AS_REQ/KRB_ERR/....../AS_REQ/AS_REP exchange would be 
ensured. Note that, as I see it, the "conceptual" AS_REQ exchange would 
start with the first AS_REQ and ends with the last AS_REP.

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

>> I thought gss-krb5 never resulted into AS_REQ message sent to the KDC,
>> just into TGS_REQ requests.
> That's no longer the case in 1.11; see:
>
>    http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation
>
I didn't know about this feature. Anyway, I think that just forbidding 
gss-krb5 as an allowed mechanism to be used with GSS preauth should do it.

Regards,
Alejandro