Would like to add support for this capability and for default plugins to be shipped with the server and client distributions. We also need to consider JDBC, ODBC and .Net driver capabilities.

@DavidMcLennan My initial release of the plugin could be found at https://code.launchpad.net/~qiush-summer/maria/krb_auth_plugin, and Vlad also gave a JDBC implementation http://bazaar.launchpad.net/~wlad-montyprogram/+junk/mariadb-java-client/revision/470. Unfortunately, we didn't consider the ODBC and .Net driver correspondents then. See anything else I can help.

Nice work qiushuang,

In CONJ-164 I've added a bit of a plugin framework. Should be easy enough to adapt the JDBC work there too. Vlad's client implementation seems compatible with http://docs.oracle.com/javase/6/docs/technotes/guides/security/jgss/lab/part5.html#SPNEGO (when SPNEGO_OID is used instead of KERBEROS_OID).

How hard would it be to wrap the server side in SPNEGO to be compatible with https://dev.mysql.com/doc/internals/en/spnego.html ?

elenst can you add a patch label here?

This can be easily modified to support Oracle/MySQL's Windows authentication. Easily however on Windows only (since choice Kerberos vs Negotiate is defined by single parameter in SSPI), no idea what effort would be to support it Unix server and C-client side.

But, if compatibility with Oracle/MySQL is desired, SPNEGO plugin also should be called differently. Neither "kerberos_client" , nor SPNEGO, but "authentication_windows_client" which is the name of Oracle/MySQL plugin ( they also only implement the server and C client on Window only)

@danblack : Also, there are some scary details in MySQL/Oracle windows authentication implementation for which I miss explanation, other than "it is a historical bug, but we document it here". Those should not be replicated QIUs kerberos plugin, I guess

https://dev.mysql.com/doc/internals/en/windows-native-authentication.html . has this or example:

Due to implementation details (again) the first packet sent from the client to the server is expected to be either

• 254 bytes long max or

• send the first 254 bytes first, appended by 1 byte with a magic value plus a 2nd packet with rest of the data

yeh, saw those odd document bits. Different plugin structure on the server side corresponding to a different name. Thanks for the info.

Hello! I have modified this code to support encryption as well, and opened https://github.com/MariaDB/server/pull/95 for it.

Robbie Harwood, nice work. But .. is there a very strong reason for Kerberos encryption, provided that server and most of the client libraries (including those written natively in Java, .NET, Python, Ruby etc) already support good encryption via SSL?
Also when using Kerberos, people would likely (more often than not) want to just to authenticate for say SSO purposes not to encrypt, as encryption is a big CPU hog.

If one uses Kerberos for authentication, there is no additional sysadmin effort to use it for encryption. Kerberos does not need certificate management the way a TLS setup does.

Personally I doubt that the overhead of encryption is noticeable in the vast majority of cases, but if there is going to be a demand for authentication without encryption (which provides zero connection security on the wire since traffic it is not encrypted, which is why I don't understand the use case) then I can try to meet this demand. I think that having this option invites sysadmins to inadvertently negate their security guarantees.

There's also a limit we are quickly approaching with the current plugin architecture to keep in mind - Kerberos authentication+encryption are best done as a plugin, but at the moment encryption plugins cannot be created. This is changing, but the changes are not yet on the horizon is my understanding, and there is demand for Kerberos right now (there was even a GSOC for supporting it!). I have been performing a similar task for postgres, where they for some time have had authentication without encryption; there is no pleasant way to add encryption later.

The authentication is related yet separate thing from encryption. The use case I had in mind was single sign on, where user does not have to type his password once more after OS/kerberos login. I do not know how much it improves security (certainly it does not on the wire), but it increases convenience considerably and removes the need of having yet one more password, just for accessing database.

Apart from that, as mentioned, there are different clients apart from C client, that on different reasons cannot use C client. There adding additional authentication is trivial, but they require a lot of work in case you tie it together with encryption. You can investigate what it means to add kerberos encryption support to Maria JDBC, while auth only required maybe 20 lines of code

So rather than rendering kerberos support useless outside of C client world, I believe it is a better idea to just support authentication at current moment, and discuss the architecture of pluggable encryption on the mailing list or so. Pluggable encryption certainly has its merit. But, as you say, in this case is mostly convenience (no need to self-sign SSL certificates)

Apparently , there seems to be support for kerberos in SSL http://www.ietf.org/rfc/rfc2712.txt. ?I understand no certificates are necessary on either side, and the client (and server) identity could be extracted. Perhaps this can be investigated further, this could provide both encryption via SSL, authentication via Kerberos , without certificates, and without need to support more encryption in client libraries.

I do not believe 2712 is a realistic option or that it is currently supported in TLS.

If JDBC is going to be required for this to merge, can you point me to that codebase?

JDBC driver is located here https://github.com/MariaDB/mariadb-connector-j

I have no authority about what is going to be required for merge (I am currently not even a member of MariaDB team). I think bigger changes and ideas like yours should be discussed on the mailing list rather than in a bug database.

So far I explained, why I think bundling Kerberos authentication with encryption would make it less valuable. If this RFC2712 is bad or outdated, even then other changes that would make using SSL easier, like for example creating self-signed server certificate on the fly during server start, should solve the remaining concerns about encryption. I doubted there is a significant need of yet another encryption, but this is just my own opinion, based on some previous work on MySQL connectors. Neither Java nor NET (and I guess not many other languages) would offer a "Kerberos stream", yet SSL support is pretty good everywhere.

If you'd like, I can propose a change on the mailing list, though there was discussion of them on the IRC channel beforehand. Mostly, it takes me by surprise that anyone is opposed to these changes; they seem the natural addon to the GSOC work.

I am not sure what you mean by "Kerberos stream".

Java, as well as .NET and probably more languages and runtimes have notion of stream. Java and NET have transparent support for SSL , you read and write bytes without wrapping, in Java using SSLSocket.getInputStream() or SSLSocket.getOutputStream() . In .NET, there is SSLStream that wraps an unencrypted Stream. They are both used to implement SSL support for MySQL.

There is no analog for that stuff for Kerberos encryption, i.e no support out of the box. I do not know why nobody opposed there changes on IRC, but mostly likely the reason would be that people you spoke to never worked on drivers (Connectors in MySQL speak), other than C-based ones (which is, C API and ODBC). But I worked on them

That's true, however: creating such an interface is not difficult (done it before; will probably do it again), and I would imagine it's what these "stream" interfaces are doing under the hood anyway. The GSSAPI interface is just set up to work with an existing flow control layer.

There is no GSSAPI for some of the environments we talk about.

In those environments, one wouldn't be able to use GSSAPI authentication either, no?

No GSSAPI, but SSPI would do in some environments . Also in .NET for example, which does not support either SSPI nor GSSAPI natively, the closest things would be to reuse NegotateStream, which wraps SPNEGO packets .Which makes me think that (optionally?) supporting SPNEGO OID would be good in this patch (also because of the other reasons , it would allow Windows auth outside of domain)

Well, if we're talking Windows, GSSAPI is available there (MIT Kerberos for Windows, or alternately a shim library over SSPI exists). QIU Shuang's original patch had SSPI support which I assume works; however, I can't test or code against that.

His code works fine,I tested it, and can code against that. I actually asked QIU to use SSPI, when I was mentoring his GSoc project, avoiding external dependencies is good , MariaDB/MySQL does not have any experience with shipping 3rd party dlls, the documentation MIT Kerberos on Windows is sparse, there is no 64 bit installer, the quality of them is unknown. His code does not have encryption, though it is possible with SSPI .
Nobody expects you to code on Windows. People just need to be aware that their patches won't always be taken "as-is", and could be heavily modified to be shippable.

Anyways, there is still a general question
1. Is TLS encryption with self-signed server certificate any worse than kerberos encryption? I know I bothered you with this one before, but have not got a "yes","no" or even "maybe" answer

Imagine for a second, TLS is super easy to use, and installer always creates some kind of self-signed certificate, and the server always starts with TLS support (I think I read that MySQL 5.7 installer does that)
Authentication kerberos and encryption(optionally) TLS, would satisfy the needs? What are the drawbacks in this scenario? the obvious benefits are less lines of code required to support GSSAPI encryption for all imaginable client libraries and also for the server. Also plugin can stay plugin,which is good.

2. Is SPNEGO support good in MIT Kerberos, if you are familiar with that? The examples are sparse on the internet? I thought perhaps it would be a good idea to make "GSSAPI" plugin, rather than Kerberos, with configurable OID, which is mostly useful for Windows (but also .NET / Mono, where SPNEGO protocol is supported but plain Kerberos not well)

From a historical perspective, Kerberos has a better track record with regards to security than SSL/TLS. It's hard to use this figure for much, though, because the presence or lack thereof of known-and-resolved vulnerabilities doesn't indicate much about future vulnerability discoveries. GSSAPI has had a core API (with I believe one exception, all that I'm calling here is core) and wire protocol that was defined in 1997 and has not changed since (rfc 2078) except for a slight update in 2000 (rfc 2743 + 2744). By contrast, every version of TLS from SSL 1.0 through TLS 1.2 is either entirely insecure or requires deviation from the specification (client mitigations, disabling broken ciphers, etc.).

A self-signed certificate requires propagation of either the cert or the CA cert to each client that wishes to connect; if this is not performed, then the encryption is worth very little since an adversary can man-in-the-middle the connection without the client noticing. This is not true of Kerberos encryption. If there is a significant use case for GSSAPI authentication with TLS encryption, I'm willing to discuss adding support for operation in this mode, but I really do think GSSAPI encryption is strongly desirable as a feature (especially since it's not going to break anything else).

The plugin provided does not make any Kerberos calls; all are done through the GSSAPI, though I have not tested it with SPNEGO. (This is also true of the original GSOC code, excluding the SSPI portions.)

Serg, could you please review the corresponding commit
https://github.com/MariaDB/server/commit/e6898d1044a435e3dfd37e5c73cf4b75af5dcade

Hi, thank you for the patch. Could you please provide more details about how to configure the client correctly. For example where do I configure the SPN and the auth mech?

SPN is configured in the [server] section of /etc/my.cnf.d/server.cnf (or similar) as kerberos_principal_name. Mechanism is configured through the GSSAPI layer; typically it will be Kerberos5 and SPNEGO, though this may vary with your system.

There is a documentation for the plugin,
https://mariadb.com/kb/en/mariadb/gssapi-authentication-plugin/

with example of how to create service principal on Unix (on Windows, with active directory, the principal name could be determined by the plugin startup code, so it is a lesser concern)

Sorry, but this all is not very clear for me. I was able to follow the doc to created a GSSAPI user. But running mysql --plugin-dir=/usr/lib64/mysql/plugin/ -u maria-user is not working for me.

From my understanding the client would need to be configured to use GSSAPI as well. And typically it needs the SPN name, so it knows the service to authenticate against.

https://mariadb.com/kb/en/mariadb/gssapi-authentication-plugin/ is really thin concerning the client config. There is a list of properties, but where do I place them? Also the client certainly does not need the keytab of the server, but the docu tells you so. Could you please review?

Oh, I realized this might just be a formatting issue :/ ... I read the bullet points as being related to the client properties, but they are not, right? Sorry for the confusion....

Found my mistake, docu is also fine (except confusing formatting). Sorry for bothering you here.

The only thing client has to do is to login as GSSAPI user (e.g kinit, or Windows domain login), and point to the plugin-dir (sometimes default plugin dir works, but often it does not ). client does not have any additional configuration, current plugin API does not allow it.

As for formatting, I do not see it as confusing, but maybe I miss something. I believe everyone can modify it, it is just a wiki, so you're welcome!