Creating a new pre-authentication plugin

[Greg Hudson]

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.  Accepting pointer values from
the client would open up the KDC to memory attacks.

The KDC would also need some way to release abandoned GSSAPI handles.

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

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.

> 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