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