Implementing a KDB plugin

[harsh savla]

Hello,

I have a use case where I need to authenticate Kerberos principals against
a RESTful Cloud service. This service can talk to an Active Directory(AD)
which maintains the users passwords. On the client side we have a Linux
based VM which runs the MIT Kerberos server. It has also Samba running.

The idea is that end users map Samba share using map drive and enter their
Kerberos credentials. This hits our VM (specifically the krb5kdc service)
and we just pass these credentials to the cloud service which then
authenticates against the AD. Once authentication is successful, ticket is
given to the client.

So in this case the kdb plugin is going to have to talk to the cloud
service. Is it possible to implement this kind of plugin? I see that there
are a few kdb implementations already available under
krb5-1.14.2/src/plugins/kdb/ namely db2, hdb and ldap.

Thanks,
Harsh
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by harsh savla
The idea is that end users map Samba share using map drive and enter their
Kerberos credentials. This hits our VM (specifically the krb5kdc service)
and we just pass these credentials to the cloud service which then
authenticates against the AD.

Kerberos KDCs do not generally receive the user's password from the
client. Instead, the client and KDC leverage their shared knowledge of
the password (more specifically, a long-term key derived from the
password) to authenticate and create a ticket-granting ticket for the
client. Therefore, it is not possible to create a KDB module which
causes the KDC to act as a pass-through password authentication service.

With some caveats, it is possible to do this using the FAST OTP preauth
protocol (RFC 6560). In our implementation, you would do this by
creating a local RADIUS server which authenticates the client's
otp-value (which could just be a password) against a third-party
service. The two caveats are (1) you must deploy FAST on the client to
protect the communication between the client and KDC, and (2) this
preauth mechanism is only implemented by MIT krb5 clients, not Microsoft
or Heimdal.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[harsh savla]

Thanks for the reply. I am aware of the fact that the user's password won't
be transferred plain-text or even encrypted over the wire.

I was thinking along the lines that the security blob (encrypted using the
user's password as a key) received by the krb5kdc service on user login
will be passed to the cloud service via the kdb plugin. The cloud service
then passes this blob to the AD (Windows Active Directory) service. AD, as
it supports Kerberos, will have the long term keys stored for all the
users. So it should be able to authenticate the blob.

Post by Greg Hudson

Post by harsh savla
The idea is that end users map Samba share using map drive and enter

their

Post by harsh savla
Kerberos credentials. This hits our VM (specifically the krb5kdc service)
and we just pass these credentials to the cloud service which then
authenticates against the AD.

Kerberos KDCs do not generally receive the user's password from the
client. Instead, the client and KDC leverage their shared knowledge of
the password (more specifically, a long-term key derived from the
password) to authenticate and create a ticket-granting ticket for the
client. Therefore, it is not possible to create a KDB module which
causes the KDC to act as a pass-through password authentication service.
With some caveats, it is possible to do this using the FAST OTP preauth
protocol (RFC 6560). In our implementation, you would do this by
creating a local RADIUS server which authenticates the client's
otp-value (which could just be a password) against a third-party
service. The two caveats are (1) you must deploy FAST on the client to
protect the communication between the client and KDC, and (2) this
preauth mechanism is only implemented by MIT krb5 clients, not Microsoft
or Heimdal.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by harsh savla
I was thinking along the lines that the security blob (encrypted using
the user's password as a key) received by the krb5kdc service on user
login will be passed to the cloud service via the kdb plugin.

It may be possible to gateway from the Kerberos protocol to a web
service and back to the Kerberos protocol again, but the MIT krb5 KDC
cannot be transformed into such a gateway element by a KDB module. KDB
modules can control how principal metadata and key data is retrieved,
and can participate in some policy decisions, but they cannot make
radical alterations to the basic protocol flow.

We do implement an HTTP proxy protocol called MS-KKDCP in our clients as
of release 1.13, but it's a bit different than what you describe.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Rick van Rein]

Hello Harsh,

Post by harsh savla
I have a use case where I need to authenticate Kerberos principals against
a RESTful Cloud service. This service can talk to an Active Directory(AD)
which maintains the users passwords. On the client side we have a Linux
based VM which runs the MIT Kerberos server. It has also Samba running.

Please note that I am drafting an integration method for Kerberos +
Diffie-Hellman
into TLS, known als TLS-KDH. I think most questionable parts are gone
nowadays,
and we are implementing this for a client and server side. This work is
scheduled
for delivery on July 1st.

http://tls-kdh.arpa2.net
https://tools.ietf.org/html/draft-vanrein-tls-kdh

What you seem to want (KRB --> REST --> KRB if I understand correctly) would
easily run into timeouts of Kerberos clients which may be as low as 1 second
and are not generally user-tunable. I bet you said HTTP and meant HTTPS,
which would aggravate the chances of a timeout.

-Rick
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev