Details
Critical
Description
This task identifies TODOs to add Kerberos authentication support to MariaDB.
Kerberos is a standardised network authentication protocol providing mutual authentication of potential users and network service. Many commercial relational database management systems have already internalized support for Kerberos authentication. The goal of this project aims to adding cross-platform Kerberos authentication support to MariaDB database.
User Scenario
In this section, we give a normal use case.
Suppose user Adam what to authentication against his Kerberos principal.
Step 1 Create a login user in MariaDB and specify the kerberos as server side authentication plugin.
CREATE USER 'adam' IDENTIFIED VIA kerberos AS 'adam/mariadb@lp';
The gap between MariaDB username length and Kerberos principal name length make it error-prone to embedded a whole principal name into a MariaDB login name. We use a short name as MariaDB login name and identify the principal name with the AS clause. If the AS clause is absent when creating a user, the MariaDB login name is used as principal name implicitly.
Step 2 At client side, Adam acquires a service ticket (or access token) to MariaDB.
Step 3 Adam tries to login with short login name.
$ mysql -u adam
Step 4 If adam/mariadb@lp is a valid principal in Kerberos and the service ticket is not expired, Adam can login MariaDB passwordlessly; otherwise, he will receive an actionable error message.
The Source Code
Source codes will be located in the plugin/auth_kerberos directory.
mysql_declar_plugin/mysql_declare_plugin_end macros can be used to define server side plugin and mysql_declare_client_plugin/mysql_end_client_plugin macros for client side.
Client-Server Communication
This section defines the message exchanges between client and server during Kerberos authentication.
Step 1 Server sends the null-terminated SPN to the client (the SPN is given as server parameter, documented in yet another section).
Step 2 Client receives SPN from server with vio->read_packet, creates a secure context with the SPN by gss_init_sec_context repeating until done.
Step 3 Client writes the output token created by gss_init_sec_context to the server, using vio->write_packet.
Step 4 Server acquire credential with gss_acquire_cred to get the initial server credential.
Step 5 Server reads token created at step 3, checks the principal name enclosed in the token with its credential get in step 4 and accepts the access requests if recognizable otherwise fails the connection.
Figure-out SPN
This section describes the policy to identify a valid service principal name.
For the server side plugin, an SPN is requried. The principal name is an option in configuration file (e.g. ~/.my.cfn) with
spn=primary/instance@realm
or
spn=primary@machine.domain
depending on its platform, where primary is the service name. If this option does not present, mysql is the default SPN.
Cross-platform Requirements
GSSAPI based Kerberos authentication is widely used in *nix world, while Windows also provides an SSPI based Kerberos authentication process. The plugin will support Windows-SSPI in addition to GSSAPi to maximize the compatibility.
Links
- Configure Kerberos authentication in Oracle RDBMS. http://docs.oracle.com/cd/A97630_01/network.920/a96573/asokerb.htm
- Using Kerberos authentication with SQL Server. http://msdn.microsoft.com/en-us/library/cc280745(v=sql.105).aspx
- Configuring Kerberos for Sybase. http://www.sybase.com.hk/content/1029260/1029260.pdf
- The Kerberos network authentication service (v5). http://tools.ietf.org/html/rfc4120
- GSS-API C-binding. http://tools.ietf.org/html/rfc2744
- The Kerberos version 5 Generic Security Service Application Program Interface (GSS-API) mechanism: Version 2. http://tools.ietf.org/html/rfc4121
- MariaDB Pluggable Authentication. https://kb.askmonty.org/en/development-pluggable-authentication/
- How the Kerberos Version 5 Authentication Protocol Works. http://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx
- SSPI/Kerberos Interoperability with GSSAPI. http://msdn.microsoft.com/en-us/library/ms995352.aspx
- Best Practices for Integrating Kerberos into Your Application. http://www.kerberos.org/software/appskerberos.pdf
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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.)
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.