If radius is Authuntication protocol why use kerberos,pap,chap,... ?
The Remote Authentication Dial-In User Service (RADIUS) protocol provides authentication, authorization, and accounting (AAA) for dial-in infrastructures, and it uses the same account and password to log into your company network through modem, WiFi, or a VPN tunnel. RADIUS has many carrier-grade features (the whole accounting part, for example) and is designed to operate in explicitly configured backbone networks.
But it is not well suited for PC and workstation networks and doesn't have the single-sign-on capability offered by Kerberos.
On the Other Hand, Kerberos provides an encrypted authentication service using shared secret keys. Kerberos can also support authentication via public key cryptography, but this is not covered by RFC 4120. Kerberos does not provide an authorization service, but Kerberos does support pass-through to other authorization services. Kerberos does not provide an accounting service.
For More Information about the PAP and CHAP, refer the following url
http://www.zeroshell.net/eng/kerberos/
and this url too you can refer
http://www.firewall.cx/ftopict-2679-.html
RADIUS (Remote Authentication Dial In User Service), defined in RFC 2865, is a protocol for remote user authentication and accounting.
Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.
Suppose you have Vodafone or Orange Telecom operator's connectivity at your home for internet connectivity.so,you will be needing a particular user id and password to access that.
Here Radius Protocol is used.
Technically, if you see the network file(.pcap file) that Wireshark Tool uses.
You will see that it contains Attribute Value Pairs that contains user name, password fields.
Radius uses CHAP password.So, it is more secured in terms of middle attack.
I hope you got my point
Related
I want to build a server using Node.js, which acts as some kind of proxy. The clients that connect to my server use NTLMv2 for authentication (there is no chance to change this), but the upstream server my server shall connect to requires a Kerberos token.
So, my question is pretty simple: How do I, using Node.js, transform the information provided by NTLMv2 into a Kerberos token? On npm, so far I have found modules for NTLMv2 authentication, but I somehow would probably need to talk to Windows to translate NTLMv2 data of a user into a token for this user.
Any hints on this, how to approach this problem?
Absolutely not! NTLM and Kerberos operate completely different. First of all, I would highly recommend get rid off NTLM as fast as you can.
You can solve your problem in an easy fashion if you can access C interfaces. I also assume you MIT Kerberos on a Unix-like OS like CentOS or FreeBSD, etc.
NTLM will provide you the downlevel logon name. You need first to convert the NetBIOS domain to a DNS domain via LDAP (use libopenldap) then you can construct the Kerberos principal or the enterprise principal for your client. Then create a service account in your KDC and enable protocol transition and contrained delegation on that account for the target service. Now request a TGT on behalf of that user principal and request a service ticket for the user, voila you can access your Kerberos backend.
Here is a decent read: https://k5wiki.kerberos.org/wiki/Projects/Services4User
If you run HTTPd as your reverse proxy, it might handle all the magic for your with mod_auth_gssapi.
On Windows, this is a bit of a pain with the security API and SSPI. While the the principal transformation comes for free with Windows. You'll need LsaLogonUser with KERB_S4U_LOGON, impersonate with that handle and then require SSPI to acquire a cred handle...
If your KDC allows constrained delegation, you can setup your intermedaite server to allow impersonation. This way it can established security context with the client in one mechanism (in your case, NTLM), and talk to the backend server on behalf of the client in another mechanism (Kerberos). Google for "constrained delegation" and "protocol transition" for more information. Hope this helps.
I'm doing some research about authentication protocols, specifically over Bluetooth. My system will not have an Internet connection but I want to authenticate, authorize and encrypt my communications. Are there any known protocols that I should look into? A few requirements:
A one time authentication for the master user
Ability to grant limited access to other users (e.g. generating a time based token)
Thank you for possible answers and suggestions.
When you authenticate against active directory as described in this answer, how is the exchange sent over the network? Is it encrypted? If not, what is the correct way to ensure that it is not sent in clear text?
If the PrincipalContext class implements the Kerberos protocol to authenticate the user against the Active Directory, the users credential is protected according the Kerberos protocol. Basically both sides makes use of a secret key to create a secure channel using a key exchange protocol like Diffie-Hellman.
You can find a quick explanation about the Kerberos protocol in wikipedia, but the RFC 4120 is the official source.
In other hand if it uses plain LDAP queries, the security will be on the transport protocol.
I'm looking for a simple authentication protocol (OpenID, Active Directory, ??) for users to log into my website. It's hosted on Windows Azure. High levels of security are required. What can you recommend and why that particular choice?
Note: At this point in time I will not be using SSL so no plain-text passwords can be transmitted. I will however be transitioning to an SSL environment in the future.
Is the data that your site/service is going to be transmitting across the wire private, sensitive, proprietary, etc? If so, it is ESSENTIAL that you implement SSL in order to prevent anyone with a packet sniffer from being able to syphon data straight from the wire.
In order to perform secure authentication you will need to employ something like SSL to establish a secure communications transport over which you can request and receive a SAML (or similar) identity token from an identity provider.
If you don't use SSL to protect your communications, it's trivial for a malicious 3rd party to steal the identity token and masquerade as the authenticated user and/or to log/monitor/modify every request for any user of your system!
What are your reasons for not using SSL?
We're building a REST API that will only be accessed from a known set of servers. My question is, if there is no access directly from any browser based clients, what security mechanisms are required.
Currently Have:
Obviously over HTTPS
Have HTTP auth enabled, API consumers have a Key & password
Is it neccessary to:
Create some changing key, e.g. md5(timestamp + token) that is formed for the request and validated at the endpoint?
Use OAuth (2-legged authentication)?
Doesn't matter - from browser or not.
Is it neccessary to:
Create some changing key, e.g. md5(timestamp + token) that is formed
for the request and validated at the endpoint?
Use oauth (2-legged authorization)?
Use OAuth, it solves both these questions. And OAuth usage is good because:
You aren't reinventing wheel
There are already a lot of libraries and approaches depending on technology stack
You can also use JWT token to pass some security context with custom claims from service to service.
Also as reference you can look how different providers solve the problem. For example Azure Active Directory has on behalf flow for this purpose
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow
Use of OAuth2/OpenID Connect is not mandatory between your services, there are other protocols and alternatives and even custom. All depends in which relationships are services and either they both are in full trust environment.
You can use anything you like but main idea not to share sensitive information between services like service account credentials or user credentials.
If REST API security is main requirement - OAuth2/OpenID Connect is maybe the best choice, if you need just secure (in a sense of authentication) calls in full trust environment in a simplest way - Kerberos, if you need encrypted custom tunnel between them for data in transit encryption - other options like VPN. It does not make sense to implement somthing custom because if you have Service A and Service B, and would like to make sure call between them is authenticated, then to avoid coupling and sharing senstive information you will always need some central service C as Identity provider. So if you think from tis pov, OAuth2/OIDC is not overkill
Whether the consumers of your API are web browsers or servers you don't control doesn't change the security picture.
If you are using HTTPs and clients already have a key/password then it isn't clear what kind of attack any other mechanism would protect against.
Any compromise on the client side will expose everything anyway.
Firstly - it matters whether a user agent (such as a browser) is involved in call.
If there are only S2S calls then 1 way SSL HTTPS (for network encryption) and some kind of signature mechanism (SHA-256) should be enough for your security.
However if you return sensitive information in your api response, its always better to accept 2 way ssl HTTPS connections (in order to validate the client).
OAuth2 doesn't add any value in a server to server call (that takes place without user consent and without any user agent present).
For authentication between servers:
Authentication
Known servers:
use TLS with X.509 client certificates (TLS with mutual authentication).
issue the client certificates with a common CA (certificate authority). That way, the servers need only have the CA certificate or public key in the truststore, and new client certificates for additional clients/servers can be issued without having to update the truststores.
Open set of servers:
use API keys, issued by a central authority. The servers need to validate these keys on each request (and may cache the hashes of the keys along with the validation result for some short time).
Identity propagation
if the requests are executed in the context of a non-technical user, use JWT (or SAML) for identity propagation of the user principal and claims (authorize at security proxy/WAF/IAM, and issue JWT signed by authentication server).
otherwise the user principal refers to the technical user and can can be extracted from the client certificate (X.509 DName) or be returned with a successful authentication response (API key case).