8. Authentication Protocols (OBJ 1.5)
There are numerous different authentication protocols in use within our enterprise networks. This includes radius cactus plus diameter. LDAP kerberos eight, two, one, x and EAP. First. We have the radius protocol. The Remote Authentication Dialing User Service Protocol is a network protocol that’s used to authenticate users, authorize them to services, and account for their usage of those services, whether they’re remote or on premise in a network. Radius provides central administration of dial up, VPN and wireless network authentication. Radius can also be used to support the use of 802 One, X, and EAP, the Extensible authentication protocol, both of which we’re going to discuss inside this lesson. Now, Radius is considered a cross platform client server protocol and operates within layer seven of the OSI model, the application layer.
Now, this is going to utilize UDP for making its connections, and that makes Radius really fast during its authentication and authorization functions. To implement Radius, you should usually run it on a separate server, but it can also be loaded on the same server as your Windows domain controller if you’re working in a smaller domain environment. Now, radius requires three pieces. In order to properly be configured in an enterprise network, you need a Supplicant, an Authenticator, and an authentication server. The Supplicant is any device asking to be authenticated using the Radius protocol. The Supplicant attempts to connect to a device on the network that’s referred to as an Authenticator.
This would be something like a switch, an access point, or another networking device. This authenticator is known as the radius client. Once the Supplicant requests authentication from the Authenticator or Radius Client, that authenticator passes this request to the authentication server known as the Radius Server to provide some level of security. The communications between the various network devices is going to be encrypted during this process, but it is only encrypted with a shared secret key. This shared secret key is considered weak protection and subject to attack. So it is better to configure and use IPsec for better protection of your connections between your network devices in order to provide a better protection for them from exploitation. Second.
We have Takis Plus. Now, the Terminal Access Controller Access Control System plus, or Tachis Plus, is a proprietary protocol developed by Cisco to provide separate authentication, authorization and accounting services. Tackis plus is used in the same manner as Radius, but it does provide more granular access control than Radius does. Tackis plus is more reliable than Radius as well because it relies on TCP instead of UDP for its communications. But Tackis Plus is considered a proprietary protocol as opposed to the more cross platform protocol, Radius. Third. We have diameter. Diameter is another authentication authorization and accounting protocol, and it was created as a next generation version of Radius. Diameter, unlike Radius or Tachus, plus is a peer to peer protocol and most commonly used in 3G IP multimedia systems and LTE 4G cellular networks. Fourth. We have LDAP.
LDAP is the lightweight directory access protocol, and it is a database that centralizes information about your clients and objects on your network. LDAP is a simplified version of the X 500 Directory service, and it contains a hierarchical organization of users, groups, servers, and systems. LDAP is considered to be crossplatform as well. Fifth. We have active directory and kerberos. Now, Active Directory was created by Microsoft and is considered an example of a single sign on authentication system. Now, a Single Sign on authentication system or SSO authentication system is going to enable a user to authenticate once and then receive authorizations for multiple services across your enterprise network in a Windows enterprise domain environment.
Active Directory is going to be used to organize and manage everything, including your clients, your servers, your devices, and your users. Once the user logs into the Windows domain, they can access all the enterprise networks resources using those same credentials as long as they’ve been put and given access into those resources based on their role or their group membership. Active Directory can be used as part of our enterprise security policies as well, and it allows us to perform access control through its group policy functions. Authentication and authorization are then going to be performed through the Kerberos system using a ticketing system approach.
Kerberos uses symmetric encryption and a trusted third party known as the Key Distribution Center, or KDC, to conduct the authentication and authorization functions. When the user logs onto the domain, they’re going to get a ticket granting ticket or TGT from this key distribution center. This ticket granting ticket is then going to be provided to the domain controller anytime the user wants to access a resource, and then the domain controller is going to provide the user with a service ticket or a session key to use as appropriate for the function they’re trying to do. These tickets are going to be presented to the resource and access will be granted because the resource always trusts the domain controllers provided tickets that were given out to these users. 6th, we have the 802 One X framework. Now eight two One X is a standardized framework that’s used for port based authentication on both wired and wireless networks. Since 802 One X is just our framework, it’s going to utilize other mechanisms to do the actual authentication. For example, both Radius and Tachus Plus can both be utilized for authentication. If you’re using 802 One X for eight two One X to work, it requires three roles, and these are going to sound familiar because of the same three roles we talked about with Radius. The first is a Supplicant, which is the device or user that’s requesting access to the network. The second is the Authenticator, which is the device through which the Supplicant is attempting to access the network, such as through a switch, a wireless access point, or a VPN concentrator.
The third is the authentication server, which is the centralized device that performs the authentication. Usually it’s going to be a Radius or Takis Plus server. While Radius and Takis Plus can both perform the role of the authenticator, we usually have to determine which is going to be best for our particular enterprise network. Radius is considered cross platform, but Takis Plus is a Cisco proprietary protocol. Takis plus is a little bit slower in operations because it relies on TCP for its transport protocol, but this also adds additional security and independently conducts authentication authorization and the accounting processes. Takis plus also supports all network protocols. But Radius doesn’t support the remote access protocol, NetBIOS frame protocol or X 25 pag connections.
Overall, Tackis Plus is an excellent choice if you’re using Cisco devices across your entire network. Otherwise, I’m usually going to opt for using Radius in my 802 One x implementations. When designing your security architecture for your enterprise networks, you need to definitely consider how you’re going to use 802 One X as part of your defense. Using eight two one x is one of your best protections that you can add to your internal network to prevent rogue devices from gaining access to your organization’s devices and resources. Again, it provides port based authentication. Anything that connects to a switch or wireless access point would be required to present itself for authentication if you’ve implemented 802 one x prior to them gaining access to the entire network. Another feature of 802 one x is the ability to encapsulate EAP.
This is our 7th protocol. EAP or the extensible authentication protocol. Now, EAP is actually not a single protocol by itself, but instead it’s a framework in a series of protocols that allows for numerous different mechanisms of authentication, including things like simple passwords, digital certificates, and public key infrastructure. There are several variants of EAP as well, such as EAP MD five EAP TLS EAP TTLs EAP fast and Eappe. EAP MD Five is a variant of EAP that utilizes simple passwords and the Challenge Handshake authentication process to provide remote access authentication. Now, if you’re using this method, you have to ensure that you’re using long, strong and complex passwords in order for you to maintain the security of your system.
EAP MD Five is considered a one way authentication process, so it’s not going to provide you with mutual authentication like some of the other EAP versions will. EAP TLS is a form of EAP that uses public key infrastructure with a digital certificate being installed on both your client and your server as your method of authentication. This makes it immune to password based attacks because neither side is going to use a password and instead they’re going to be using digital certificates to uniquely identify themselves. This is considered a form of mutual authentication between both devices, the client and the server, because each one is going to authenticate with the other one using those digital certificates. Another variant of this is known as EAP TTLs.
This is going to require a digital certificate on the server, but not on your client. Instead, the client is going to use a password for its authentication while the server uses the digital certificate. This makes it more secure than the traditional EAP MD Five, which just uses passwords, but it is less secure than using EAP TLS, because now we’re only using one digital certificate instead of two inside the process. Our fourth variant of EAP. Is EAP Fast or EAP Flexible authentication via Secure Tunneling. Now, EAP Fast uses a protected access credential instead of a certificate to establish mutual authentication between the devices. The fifth and final variant we have is Eappe, or Protected EAP.
Now, this variant also supports mutual authentication by using server certificates and the Microsoft Active Directory databases for it to authenticate a password from a client. Now, in addition to all these crafts platform variants of EAP we just discussed, there’s also a proprietary version that was developed by Cisco known as EAP Leap, or the lightweight EAP. Since its proprietary, it only works on Cisco based devices. So unless you’re using all Cisco devices in your network, you really should stick with one of the standard EAPs in your network instead. As you can see, there’s lots of different authentication protocols that can be found in our enterprise networks. This includes Radius Tacos plus diameter LDAP, kerberos 802, one x, and the seven variants of EAP.
9. Federation (OBJ 1.5)
Organizations these days are now grouping together to create federations. Each organization that joins the federation agrees to a common set of standards and policies that they’re going to use for identification. This allows them to create a Federated identity for each user. They can then use this identity across all the systems of each of those businesses that have joined that federation. These federations support the provisioning and management of identification, authentication and authorization. This can to be done through two basic models cross Certification or Trusted third party. The Cross Certification model utilizes a web of trust between the organizations in which each organization certifies every other organization inside the federation.
This model works well with a small number of organizations, but once the number gets too large, it can then become very difficult to manage. Thinking back to your earlier networking studies, you can actually relate the Cross Certification model to a full mesh networking model. If we have any number higher than about five organizations, this model starts to break down really quickly. The trusted third Party model, also known as a bridge model, allows organizations to place their trust in a single third party. This third party then manages verification and certification for all the organizations inside of that federation. This is more similar to the way a traditional certificate authority on the internet works. This model is quite efficient even with a large number of organizations within a given federation.
With either of these two models though, it’s important to keep in mind the concept of a transitive trust and the relationship it’s going to form. A transitive trust is a two way relationship that is automatically created between a parent and child domain within a Microsoft Active Directory forest. When a new domain is created or joins into the federation, it’s going to share its resources with its parent domain by default, and this enables the authenticated user to access any resource in both the child and the parent. Therefore, when you begin to interconnect domains to create a federation, it’s really important to determine if you want to allow for this default transitive trust to exist or if you want to break those transitive trusts by applying additional configurations and security measures to better protect your own domain. If a transitive trust is not set up, then it’s going to be important to determine how Attestation is going to be performed in the federation.
This may rely on SAML open ID or Shibolith. Now SAML is the Security Ascertation Markup language and it’s an Attestation model built upon XML for Soap based web services. SAML supports Federated identity management and it’s going to be used for authentication and authorization between different systems, especially over the web or when using single signon sessions. Now to perform this function, SAML uses an Ascertation ticket that’s going to be provided to the user who’s being authenticated. It then sends this ticket to the web servers that the user wants to get access to. SAML is a standardization of the SSO or single sign on process, and it’s used heavily in the web. SAML works well for several situations.
The first is when your organization needs to provide single signon services or to participate in single signon services. The second is when the organization needs to allow an application to access its web portal. The third scenario is when the organization needs to provide a centralized identity service and process. Another possible solution to this problem is Open ID, which is an Open standard decentralized protocol for authenticating users. Open ID allows a user to log into an identity provider and then utilize that same account across cooperating sites called Relaying Partners or RPS. One of the largest and most well known Open ID identity providers is actually Google. Anytime you logged into a website outside of Google using your Google login, you’ve been using Open ID without even knowing it.
Open ID is much less difficult to implement than SAML, but SAML performs the same functions much more efficiently. Also, OpenID only allows the service provider to initiate the identification, whereas SAML can initiate this from the service provider or the identity provider’s side. The latest version of Open ID is called OpenID Connect, and it works well in cooperation with OAuth 20. OAuth, or Open Authorization is an authorization standard that allows different websites to rely on a trusted third party to authenticate its users. These days, a lot of websites allow users to log in using their Google, Facebook or LinkedIn accounts. My own website, for example, allows my students to log in to our private resources using their LinkedIn accounts.
And my web server never actually gets their LinkedIn credentials. Instead, we get a token from LinkedIn’s authorization server that tells us the user successfully logged into LinkedIn and therefore they are properly identified and match up with their email address. Now we know that they can be authorized to use our resources. Now when you’re using OAuth, often data is going to be sent using a JSON web token or JWT. A JSON web token is a token format that contains a header, a payload, and a signature in the form of a JavaScript object notation or JSON message. JSON web tokens are going to be used to provide authorization and specify what access rights and privileges a user is going to have on a given system.
This is a form of assertion that’s going to be made about a person, and it assumes the person has already been authenticated. So what does a JSON web token look like? Well, it looks like this. Notice we have some curly brackets with these different key pairs together. ALG H 256. What do you think that means? Well, this is specifying what algorithm is being used. In this case a 256 bit hash. So that probably means we’re using Shaw 256. Next it says what type it is. In this case it says the type is JWT or a JSON web token. Then we see. The next set contains SUV, which stands for subject. This is defining who it is that we’re going to make an attestation about by providing their ID. Next, we have the name, in this case, Jason, and then we have the email, in this case, Support@deontraining. com.
Now, in this example, I only have two fields that are attributes of that particular subject ID that we’re talking about. In this case, it’s Jason, the ID with an email of support at deon training. Now, the beauty of A. JSON web token is you can have a lot of different key pairs here to provide different fields of information that you need during the attestation process. But in this case, I wanted to keep it pretty simple and focus on the format of A. JSON web token. Now, Shibolith is another open source option for single signon capabilities and this utilizes SAML. It’s going to essentially utilize a communitywide password that enables members of the community to access an online resource without revealing their individual identities.
The origin server can actually vouch for their identity of that individual user without giving the target server any amplifying information about their identity, and therefore it protects the individual user’s privacy. Additionally, the individual user does not know the password that’s actually being used by the community server since it’s generated internally to that origin server. Therefore, we can’t share it with anybody else outside of the community even if we wanted to. Shiblith is going to be used when privacy is considered a major concern, but it is not nearly as popular as SAML or open ID.
