I am doing a project which involves authentication and I can't quite grasp the difference between SASL and gssapi. Is gssapi used under the covers of SASL? Can I use gssapi without SASL? What is the correct thing to do?
If I use libsasl, do I need to link with libgssapi_*?
Thanks.
SASL and gssapi basically solve the same problem in different ways. Both are a way to find the best common authentication method to use between two systems.
So no, gssapi isn't used under the hood in SASL, unless you use something like RFC4752
Yes, you can use gssapi without SASL, examples of that would be the typical linux machine logging into a windows AD domain via the kerberos/gssapi providers.
It all depends on what kind of authentication scenarios you have to implement, both SASL and gssapi have their uses. GSSAPI is most commonly used with the Kerberos system.
Related
I have a web application which is developed using vb.net.
My web application uses Windows authentication mode.
Security team scanned the application and reported one issue.
Steps followed to produce the issue:
1. Type the url in browser (url - https://sample/applicationname) and press Enter
2. Analyze the response using proxy tool 'Fiddler' - which shows that authentication method in NTLM which is insecure.
Recomendations given by security team:
Change authentication method to a more secure one such as Digest, client certificates or similar. Otherwise use an encrypted channel to protect information by implementing HTTPS.
Note: HTTPS is already implemented.
Kindly let me know how to solve the issue.
Thanks in advance.
Digest is less secure than NTLM, so you may want to mock your security team. Digest uses MD5 (in a weak manner) and requires reversible passwords. If you really want to go more secure than NTLM, your may want to configure kerberos. The options vary depending on your version of IIS. Google will have your answer.
I'm currently trying to implement GSSAPI support in a third-party LDAP library (the Common Lisp library trivial-ldap). I got it to work when authenticating to an AD server (using the mechanism GSS-SPNEGO) but when trying to talk to an OpenLDAP server I get an error reply from the server saying that the mechanism is not supported.
It turns out that OpenLDSP doesn't support GSS-SPNEGO, but instead wants GSSAPI. The protocol used to do GSSAPI authentication seems very different from GSS-SPNEGO, but my problem is that I can't figure out is what way.
Is there anyone that could assist in explaining how the GSS packets are supposed to be wrapped inside the SASL messages when using the mechanism GSSAPI?
I tried simply sending packets in the same form as GSS-SPNEGO, but when I do so the SASL handshake never ends. After the context has been created, I keep getting result code 14 (LDAP_SASL_BIND_IN_PROGRESS) as a response to anything I send.
You can safely use the GSSAPI SASL mech. This is plain Kerberos 5. GSS-SPNEGO is just SPNEGO which will try Kerberos 5 first and if this fails it may resort to NTLM. Active Direcory supports DIGEST-MD5, and the two mentioned mechs. I've been using GSSAPI mech for years from Windows and Unix.
This is probably a dumb question but can I do away safely with just basic HTTP auth or do I still benefit from digest auth even if the server is already on SSL?
The only advantage you would gain by using HTTP Digest authentication over SSL/TLS is to prevent the disclosure of the user password to the server itself, if your sever is capable of being configured with passwords in "HA1 format" directly (i.e. if it doesn't need to know the password itself, but where the user password can be configured with MD5(username:realm:password), without requiring the password in clear, see Apache Httpd for example).
In practice, this isn't really a big advantage. There are better alternatives if protecting the password itself from the server is required (in particular because MD5 isn't considered good enough anyway nowadays).
The other features of HTTP Digest authentication (over form/HTTP Basic) are already provided by the SSL/TLS layer.
Across ssl basic auth is secure enough for most needs.
I've been searching for a bit now, but I can't find an answer. WCF Security Best Practices say to use Windows Authentication when possible. Can this provide non-repudiation and data integrity if you require signing?
(The most important question here is non-repudiation. I'm using TLS but trying to determine if I can provide non-repudiation through Windows Auth with TLS or MLS. Theoretically, the TLS provides hop-to-hop data integrity.)
Yes, for first question. Check this:
Chapter 4: WCF Security Fundamentals
Windows Authentication does not provide data signing.
Windows Authentication is preferrable and suggested by the best practice guide because it is built in all Microsoft machines. It doesn't like the certificate that requires a lot of infrastructure setup. If your machine is joined to an Active Directory domain, it should just work.
Windows Authentication is using SPNEGO to negotiate to use which authentication method, Kerberos or NTLM. Whenever possible, client and server will try to pick Kerberos first. Otherwise, NTLM will be used.
To answer your question of whether the message can be sigend or not, both Kerberos and NTLM can be used to sign and encrypt messages. As a WCF programmer, it should be transparent to you. All you need to do is to set the ProtectedLevel to EncryptAndSign. If you don't believe me, you can look at the network trace after setting up the Windows Authentication. You should see the messages are encrypted.
When using the Windows Authentication, WCF will call SSPI to do authentication and message encryption. I won't cover the detials of SSPI. Here is the SSPI call for NTLM to encrypt message and here is the SSPI call for Kerberos to encrypt message. You can set a break point in Windbg to prove that.
Although it's not explicitly stated in the above links, this link clearly states that the above mentioned EncryptMessages methods can provide data integrity (signing) and privacy (encryption).
Back to your original question about whether Windows authentication support non-repudiation, this is actually a bigger question. Data signing is necessary for non-repudiation but not sufficient. WCF is also providing the auditing feature to record operation or transaction. This is to guarantee that a user cannot deny performing an operation or initiating a transaction. So, in order to support non-repudiation, you should also set SuppressAuditFailure to false to make sure auditing is always functioning properly.
I have created a REST API that uses Basic HTTP authentication. Is is restricted to SSL only. Now that it is implemented I am hearing criticisms that Basic HTTP over SSL is not secure. It would be detrimental to the project for me to "stop the press" and it would be outside the scope of some of my clients skill set to use OAuth, etc. I need to understand the risk and rewards of this methods. Any examples of big names using Basic HTTP auth would be helpful as support also.
Basic HTTP authentication over SSL is basically secure, with caveats. Security issues predominantly arise from the use of Basic auth without SSL, in which case, the username and password are exposed to a MITM. In a browser, there are also problems with expiring credentials, but this isn't so much of an issue for REST services.
perhaps I am mislead but I don't see a problem with SSL only BASIC... esp. not with a stateless API.
If the callers are forced to use a SSL-sniffing proxy then BASIC means that the password is available in cleartext to the proxy... in this specific case Digest would be better (even with SSL) because the proxy wouldn't know the password (digest means challenge response...).