Fetching tickets over EAP
Thursday, December 25th, 2008Or how to talk to the Kerberos KDC over your appliation protocol
Talking to the KDC with no network
Sometimes you want to talk to the KDC when there is limited or direct network. Or your application simply knows better how to communicate with the KDC.
For example, if it was possible to use EAP with GSS-API so it run Kerberos initial ticket fetching over the EAP channel, this is not so far off given the new IAKERB gss-api mechanism that Larry Zhu is proposing (currently in last call). With his mechanism you can talk to the KDC and get initial and service tickets for a service over a gss-api channel.
First the when you login to the network using EAP the network topology looks like this:
Client ---[EAP over wavelan]---> Wavelan access point ---[radius]---> Radius server
First you authenticate to the radius server, and the radius server tells the access point to let you out on the network, and then you get a IP address from the DHCP server. So why doesn’t this fit together with the Kerberos stack.
In the classial appliation the world looks like this:
Application -> GSS-API -> Kerberos mechanism <--[Kerberos protocol]--> KDC
|
[token]
|
appl <---------/
|
|
\
------[application protocol]----> server
But when you are in an about to use EAP to login to the network, theKerberos mechanism have no way to talk to the KDC, the only channel you have EAP the channel to the Radius server.
So the obvious solution is to let the Kerberos mechanism talk though the EAP channel over the the Radius server, and have the radius server forward over the packets over the the KDC.
The problem with Kerberos krb5_get_init_creds()
The Kerberos function krb5_get_init_creds() is that it expect to be able to resolve the DNS information to the KDC and then talk to the KDC to get initial tickets, so deep inside the function there is a function that will send of a packet the the KDC.
As described above, this wont work since the Kerberos library have no network connection to the KDC, it have to talk to the KDC thought the GSS-API layer.
The replacement function, krb5_init_creds()
So the new function krb5_init_creds() and krb5_init_creds_step() instead of sending of the packet to the KDC, return the packet that is supposed to be sent off to the KDC, and the expect the caller to call
krb5_init_creds_step() with whatever the KDC returned. There is a helper function that does all this: krb5_init_creds_get().
So krb5_get_init_creds_password() is now implmented in terms of the new functions. And is as described below.
krb5_get_init_creds_password()
{
krb5_init_creds_init(&ctx);
krb5_init_creds_get(ctx);
krb5_init_creds_free(ctx);
}
krb5_init_creds_get(ctx)
{
while(1) {
ret = krb5_init_creds_step(ctx,inpacket, &outpacket);
if (ret != CONTINUE)
break;
krb5_send_to_kdc(outnpacket, &inpacket);
}
}
GSS-API usage of krb5_init_creds_step()
This way GSS-API mech can take advantage of the split stack and instead of sending the packet to the KDC, send of the packet over to GSS-API peer and when it get back the reply, stuff the answer back into krb5_init_creds_step() to continue the dance.
Application -> GSS-API <–> Kerberos mechanism
|
[token]
|
appl <---------/
|
|
\
------[application protocol]----> server <--[Kerberos protocol]--> KDC
Now, someone just need to implement IAKERB to use this functionallity.