Domain 5. Chapter 14 Flashcards
(40 cards)
- Access Control Models
A subject is an active entity that accesses a passive object, and an object is a passive entity that provides information to active subjects. For example, when a user accesses a file, the user is the subject, and the file is the object.
Permissions In general, permissions refer to the access granted for an object and determine what you can do with it. If you have read permission for a file, you’ll be able to open it and read it. You can grant user permissions to create, read, edit, or delete a file on a file server. Similarly, you can grant a user access rights to a file, so in this context, access rights and permissions are synonymous. For example, you may be granted read and execute permissions for an application file, which gives you the right to run the application. Additionally, you may be granted data rights within a database, allowing you to retrieve or update information in the database.
Rights A right primarily refers to the ability to take an action on an object. For example, a user might have the right to modify the system time on a computer or the right to restore backed-up data. This is a subtle distinction and not always stressed. However, you’ll rarely see the right to take action on a system referred to as a permission.
Privileges Privileges are a combination of rights and permissions. For example, an administrator for a computer will have full privileges, granting the administrator full rights and permissions on the computer. The administrator will be able to perform any actions and access any data on the computer.
Субъект — это активная сущность, которая обращается к пассивному объекту, а объект — это пассивная сущность, предоставляющая информацию активным субъектам. Например, когда пользователь обращается к файлу, пользователь является субъектом, а файл — объектом.
Разрешения Как правило, разрешения относятся к доступу, предоставленному объекту, и определяют, что вы можете с ним делать. Если у вас есть разрешение на чтение файла, вы сможете открыть его и прочитать. Вы можете предоставить пользователям разрешения на создание, чтение, редактирование или удаление файла на файловом сервере. Аналогичным образом вы можете предоставить пользователю права доступа к файлу, поэтому в этом контексте права доступа и разрешения являются синонимами. Например, вам могут быть предоставлены разрешения на чтение и выполнение файла приложения, что дает вам право запускать приложение. Кроме того, вам могут быть предоставлены права на данные в базе данных, что позволит вам извлекать или обновлять информацию в базе данных.
Права Право в первую очередь относится к возможности совершать действия над объектом. Например, пользователь может иметь право изменять системное время на компьютере или право восстанавливать данные из резервной копии. Это тонкое различие, и оно не всегда подчеркивается. Однако вы редко увидите право на действие в системе, называемое разрешением.
Привилегии Привилегии — это сочетание прав и разрешений. Например, администратор компьютера будет иметь полные права, предоставляя ему полные права и разрешения на компьютере. Администратор сможет совершать любые действия и получать доступ к любым данным на компьютере.
1.1 Authorization Mechanisms
Implicit Deny A fundamental principle of access control is implicit deny, and most authorization mechanisms use it. The implicit deny principle ensures that access to an object is denied unless access has been explicitly granted to a subject. You can also think of this as deny by default.
Access Control Matrix In short, an access control matrix is a table that includes subjects, objects, and assigned privileges. When a subject attempts an action, the system checks the access control matrix to determine if the subject has the appropriate privileges to perform the action. For example, an access control matrix can include a group of files as the objects and a group of users as the subjects. It will show the exact permissions authorized for each user for each file. Note that this covers much more than a single access control list (ACL). In this example, each file listed within the matrix has a separate ACL that lists the authorized users and their assigned permissions.
Capability Tables Capability tables are another way to identify privileges assigned to subjects. They are different from ACLs in that a capability table is focused on subjects (such as users, groups, or roles). For example, a capability table created for the accounting role will include a list of all objects that the accounting role can access as well as the specific privileges assigned to the accounting role for these objects. In contrast, ACLs are focused on objects. An ACL for a file would list all the users and/or groups that have authorized access to the file and the specific access granted to each.
Неявное запрещение Основным принципом контроля доступа является неявное запрещение, и его использует большинство механизмов авторизации. Принцип неявного запрета гарантирует, что доступ к объекту запрещен, если доступ не был явно предоставлен субъекту. Вы также можете думать об этом как об отказе по умолчанию.
Матрица контроля доступа Короче говоря, матрица управления доступом — это таблица, которая включает субъектов, объекты и назначенные привилегии. Когда субъект пытается выполнить действие, система проверяет матрицу контроля доступа, чтобы определить, имеет ли субъект соответствующие привилегии для выполнения действия. Например, матрица контроля доступа может включать группу файлов в качестве объектов и группу пользователей в качестве субъектов. Он покажет точные разрешения, разрешенные каждому пользователю для каждого файла. Обратите внимание, что это охватывает гораздо больше, чем просто один список управления доступом (ACL). В этом примере каждый файл, указанный в матрице, имеет отдельный список управления доступом, в котором перечислены авторизованные пользователи и назначенные им разрешения.
Таблицы возможностей Таблицы возможностей — это еще один способ определить привилегии, назначенные субъектам. Они отличаются от списков ACL тем, что таблица возможностей ориентирована на субъекты (такие как пользователи, группы или роли). Например, таблица возможностей, созданная для роли учета, будет включать список всех объектов, к которым может получить доступ роль учета, а также конкретные привилегии, назначенные роли учета для этих объектов. Напротив, списки ACL ориентированы на объекты. В списке ACL для файла будут перечислены все пользователи и/или группы, имеющие авторизованный доступ к файлу, а также конкретный доступ, предоставленный каждому.
1.1 Authorization Mechanisms
Constrained Interface Applications use constrained interfaces or restricted interfaces to restrict what users can do or see based on their privileges. Users with full privileges have access to all the capabilities of the application. Users with restricted privileges have limited access. The Clark–Wilson model discusses the technical details of how it implements a constrained interface.
Content-Dependent Control Content-dependent access controls restrict access to data based on the content within an object. A database view is a content-dependent control. A view retrieves specific columns from one or more tables, creating a virtual table.
Context-Dependent Control Context-dependent access controls require specific activity before granting users access. The system denies access to the download page if users don’t go through the purchase process first. It’s also possible to use date and time controls as context-dependent controls. If users attempt to access the resource outside the allowed time, the system denies them access.
Need to Know This principle ensures that subjects are granted access only to what they need to know for their work tasks and job functions. Subjects may have clearance to access classified or restricted data but are not granted authorization to the data unless they actually need it to perform a job.
Least Privilege The principle of least privilege ensures that subjects are granted only the privileges they need to perform their work tasks and job functions. This is sometimes lumped together with need to know. The only difference is that least privilege will also include rights to take action on a system.
Separation of Duties and Responsibilities The separation of duties and responsibilities principle ensures that sensitive functions are split into tasks performed by two or more employees. It helps prevent fraud and errors by creating a system of checks and balances.
Ограниченный интерфейс Приложения используют ограниченные или ограниченные интерфейсы, чтобы ограничить то, что пользователи могут делать или видеть, в зависимости от их привилегий. Пользователи с полными правами имеют доступ ко всем возможностям приложения. Пользователи с ограниченными привилегиями имеют ограниченный доступ. В модели Кларка–Уилсона ( обсуждаются технические детали реализации ограниченного интерфейса.
Управление, зависящее от содержимого Управление доступом, зависящее от содержимого, ограничивает доступ к данным на основе содержимого внутри объекта. Представление базы данных — это элемент управления, зависящий от содержимого. Представление извлекает определенные столбцы из одной или нескольких таблиц, создавая виртуальную таблицу.
Контекстно-зависимый контроль Контекстно-зависимый контроль доступа требует выполнения определенных действий, прежде чем предоставлять пользователям доступ. Система отказывает в доступе к странице загрузки, если пользователи сначала не проходят процесс покупки. Также можно использовать элементы управления датой и временем в качестве контекстно-зависимых элементов управления. Если пользователи попытаются получить доступ к ресурсу вне разрешенного времени, система откажет им в доступе.
Необходимость знать Этот принцип гарантирует, что субъектам предоставляется доступ только к тому, что им необходимо знать для выполнения своих рабочих задач и должностных функций. Субъекты могут иметь разрешение на доступ к секретным или ограниченным данным, но им не предоставляется разрешение на доступ к данным, если они действительно не нужны им для выполнения работы. Наименьшие привилегии
Принцип наименьших привилегий гарантирует, что субъектам предоставляются только те привилегии, которые им необходимы для выполнения своих рабочих задач и должностных функций. Иногда это смешивают с необходимостью знать. Единственное отличие состоит в том, что минимальные привилегии также включают права на выполнение действий в системе.
Разделение обязанностей и ответственности Принцип разделения обязанностей и ответственности обеспечивает разделение важных функций на задачи, выполняемые двумя или более сотрудниками. Это помогает предотвратить мошенничество и ошибки, создавая систему сдержек и противовесов.
- Defining Requirements with a Security Policy
A security policy is a document that defines the security requirements for an organization. It identifies assets that need protection and the extent to which security solutions should go to protect them.
Policies are an important element of access control because they help personnel within the organization understand what security requirements are important.
However, a security policy usually does not go into details about how to fulfill the security needs or how to implement the policy. For example, it may state the need to implement and enforce separation of duties and least privilege principles but not state how to do so. Professionals within the organization use the security policies as a guide to implement security requirements.
- Access Control Models
3.1 Discretionary Access Control
3.2 Role-Based Access Control
3.3 Rule-Based Access Control
3.4 Attribute-Based Access Control
3.5 Mandatory Access Control
3.6 Risk-Based Access Control
3.4 Attribute-Based Access Control
Attribute-Based Access Control A key characteristic of the Attribute-Based Access Control (ABAC) model is its use of rules that can include multiple attributes. This allows it to be much more flexible than a rule-based access control model that applies the rules to all subjects equally. Many software-defined networks (SDNs) use the ABAC model. Additionally, ABAC allows administrators to create rules within a policy using plain language statements such as “Allow Managers to access the WAN using a mobile device.”
However, an advanced implementation of a rule-based access control is an Attribute-Based Access Control (ABAC) model. ABAC models use policies that include multiple attributes for rules.
Attributes can be almost any characteristic of users, the network, and devices on the network. For example, user attributes can include group membership, the department where they work, and devices they use such as desktop PCs or mobile devices. The network can be the local internal network, a wireless network, an intranet, or a wide area network (WAN). Devices can include firewalls, proxy servers, web servers, database servers, and more.
Mobile device management (MDM) systems, discussed in can use attributes to identify mobile devices. Attributes: some attribute examples such as somewhere you are, somewhere you aren’t, and context-aware authentication.
Управление доступом на основе атрибутов Ключевой характеристикой модели управления доступом на основе атрибутов (ABAC) является использование правил, которые могут включать несколько атрибутов. Это позволяет ей быть гораздо более гибкой, чем модель управления доступом на основе правил, которая одинаково применяет правила ко всем субъектам. Многие программно-определяемые сети (SDN) используют модель ABAC. Кроме того, ABAC позволяет администраторам создавать правила в политике, используя простые формулировки, такие как «Разрешить менеджерам доступ к глобальной сети с помощью мобильного устройства».
3.5 Mandatory Access Control
Mandatory Access Control A key characteristic of the Mandatory Access Control (MAC) model is the use of labels applied to both subjects and objects. For example, if a user has a label of top secret, the user can be granted access to a top-secret document. In this example, both the subject and the object have matching labels. When documented in a table, the MAC model sometimes resembles a lattice (such as one used for a climbing rosebush), so it is referred to as a lattice-based model.
Each classification label represents a security domain, or a realm of security. A security domain is a collection of subjects and objects that share a common security policy. For example, a security domain could have the label Secret, and the MAC model would protect all objects with the Secret label in the same manner.
Users have labels assigned to them based on their clearance level, which is a form of privilege.
Using compartmentalization with the MAC model enforces the need to know principle. Users with the Confidential label are not automatically granted access to compartments within the Confidential section.
The MAC model is prohibitive rather than permissive, and it uses an implicit deny philosophy. The MAC model is more secure than the DAC model, but it isn’t as flexible or scalable.
Classifications within a MAC model use one of the following three types of environment:
- Hierarchical Environment A hierarchical environment relates various classification labels in an ordered structure from low security to medium security to high security, such as Confidential, Secret, and Top Secret, respectively. Each level or classification label in the structure is related. Clearance in one level grants the subject access to objects in that level as well as to all objects in lower levels but prohibits access to all objects in higher levels.
- Compartmentalized Environment In a compartmentalized environment, there is no relationship between one security domain and another. Each domain represents a separate isolated compartment. To gain access to an object, the subject must have specific clearance for the object’s security domain.
- Hybrid Environment A hybrid environment combines both hierarchical and compartmentalized concepts so that each hierarchical level may contain numerous subdivisions that are isolated from the rest of the security domain. A subject must have the correct clearance and the need to know data within a specific compartment to gain access to the compartmentalized object. A hybrid MAC environment provides granular control over access but becomes increasingly difficult to manage as it grows.
Мандатный контроль доступа Ключевой характеристикой модели обязательного контроля доступа (MAC) является использование меток, наносимых как на субъекты, так и на объекты. Например, если у пользователя есть гриф «Совершенно секретно», ему может быть предоставлен доступ к совершенно секретному документу. В этом примере и субъект, и объект имеют совпадающие метки. В таблице модель MAC иногда напоминает решетку (например, ту, которая используется для вьющегося розового куста), поэтому ее называют моделью на основе решетки.
3.6 Risk-Based Access Control
Risk-Based Access Control A risk-based access control model grants access after evaluating risk. It evaluates the environment and the situation and makes risk-based decisions using policies embedded within software code. It uses machine learning to make predictive conclusions about current activity based on past activity.
Risk-based access control is relatively new, and the implementation can be quite complex. The model attempts to evaluate risk by considering several different elements, such as:
The environment
The situation
Security policies
In this context, a security policy is software code that makes risk-based decisions based on available data. An organization would modify the choices within the software to support their needs.
Two other things can be checked or required before the policy grants access:
Multifactor Authentication The system will deny access to users logging on with just one factor of authentication.
Compliant Mobile Devices The policy may require that smartphones and tablets meet specific security requirements, such as an up-to-date operating system and device encryption.
A risk-based access control model that examines mobile devices for compliance may interact with an existing mobile device management (MDM) system.
Контроль доступа на основе рисков Модель управления доступом на основе рисков предоставляет доступ после оценки риска. Он оценивает окружающую среду и ситуацию и принимает решения с учетом рисков, используя политики, встроенные в программный код. Он использует машинное обучение, чтобы делать прогнозные выводы о текущей деятельности на основе прошлой деятельности.
3.1 Discretionary Access Control
Discretionary Access Control A key characteristic of the Discretionary Access Control (DAC) model is that every object has an owner and the owner can grant or deny access to any other subjects. For example, if you create a file, you are the owner and can grant permissions to any other user to access the file. The New Technology File System (NTFS), used on Microsoft Windows operating systems, uses the DAC model.
Within the DAC model, every object has an owner (or data custodian), and owners have full control over the objects they own. Permissions (such as read and modify for files) are maintained in an ACL, and owners can easily change permissions. This makes the model very flexible.
It does not offer a centrally controlled management system because owners can alter the ACLs on their objects at will.
Microsoft Windows systems use the DAC model to manage files. Each file and folder has an ACL (also known as a DACL) identifying the permissions granted to any user or group, and the owner can modify permissions.
In a nondiscretionary access control model, access does not focus on user identity. Instead, a static set of rules governing the whole environment manages access. Non-DAC systems are centrally controlled and easier to manage (although less flexible). In general, any model that isn’t a discretionary model is a nondiscretionary model.
Дискреционный контроль доступа Ключевой характеристикой модели дискреционного контроля доступа (DAC) является то, что у каждого объекта есть владелец, и владелец может предоставлять или запрещать доступ любым другим субъектам. Например, если вы создаете файл, вы являетесь его владельцем и можете предоставить любому другому пользователю разрешения на доступ к файлу. Файловая система новой технологии (NTFS), используемая в операционных системах Microsoft Windows, использует модель DAC.
3.2 Role-Based Access Control
A key characteristic of the Role-Based Access Control (RBAC) model is the use of roles or groups. Instead of assigning permissions directly to users, user accounts are placed in roles and administrators assign privileges to the roles. These roles are typically identified by job functions. If a user account is in a role, the user has all the privileges assigned to the role. Microsoft Windows operating systems implement this model with the use of groups.
Administrators often implement Role-Based Access Control (RBAC) using groups.
This approach helps enforce the principle of least privilege by preventing privilege creep. Privilege creep is the tendency for users to accrue privileges over time as their roles and access needs change.
Microsoft operating systems implement RBAC with the use of groups. Some groups, such as the local Administrators group, are predefined.
In the DAC model, objects have owners, and the owner determines who has access. In the RBAC model, administrators determine subject privileges and assign appropriate privileges to roles or groups.
Another method related to RBAC is task-based access control (TBAC). TBAC is similar to RBAC, but instead of being assigned to one or more roles, each user is assigned an array of tasks. As an example, Microsoft Project uses TBAC. Each project has multiple tasks. The project manager assigns tasks to project team personnel. Team personnel can address their own tasks (adding comments, indicating progress, and so on), but they cannot address other tasks. Microsoft Project handles the underlying details.
Управление доступом на основе ролей Ключевой характеристикой модели управления доступом на основе ролей (RBAC) является использование ролей или групп. Вместо того, чтобы назначать разрешения непосредственно пользователям, учетные записи пользователей помещаются в роли, а администраторы присваивают ролям привилегии. Эти роли обычно определяются должностными функциями. Если учетная запись пользователя входит в роль, у пользователя есть все привилегии, назначенные этой роли. Операционные системы Microsoft Windows реализуют эту модель с использованием групп.
3.3 Rule-Based Access Control
A key characteristic of the rule-based access control model is that it applies global rules to all subjects. As an example, a firewall uses rules that allow or block traffic to all users equally. Rules within the rule-based access control model are sometimes referred to as restrictions or filters.
A rule-based access control model uses a set of rules, restrictions, or filters to determine what can and cannot occur on a system. It includes granting a subject access to an object, or granting the subject the ability to perform an action. A distinctive characteristic about rule-based access control models is that they have global rules that apply to all subjects.
One common example of a rule-based access control model is a firewall. Firewalls include a set of rules or filters within an ACL, defined by an administrator. Firewalls include a final rule (referred to as the implicit deny rule), denying or blocking all other traffic.
Ключевой характеристикой модели управления доступом на основе правил является то, что она применяет глобальные правила ко всем субъектам. Например, брандмауэр использует правила, которые одинаково разрешают или блокируют трафик для всех пользователей. Правила в модели управления доступом на основе правил иногда называют ограничениями или фильтрами.
- Implementing Authentication Systems
Authentication systems simplify the management of authentication on the internet and in internal networks.
FIM ( federated identity management) allows different organizations to use federations for SSO (single sign-on).
4.1 Implementing SSO on the Internet
XML, SAML, OAuth, OpenID ( OIDC)
4.2 Implementing SSO on Internal Networks
AAA Protocols, Kerberos, RADIUS, TACACS+
4.1 Implementing SSO on the Internet
Imagine you want to transfer money from Bank A to Bank B. You could give Bank B your credentials to Bank A and have them transfer the money. Sound scary? You bet. You should never be required to give your credentials to any third party. Solutions such as SAML, OAuth, OpenID, and OIDC help solve this problem. They share authentication, authorization, or profile information about a user, and some solutions share all three.
4.1.1XML
Extensible Markup Language (XML) goes beyond describing how to display the data by actually describing the data. XML can include tags to describe data as anything desired.
Databases from multiple vendors can import and export data to and from an XML format, making XML a common language used to exchange information. Many specific schemas exist, and if companies agree on what schema to use, they can easily share information. Many cloud-based providers use XML-based languages to share information for authentication and authorization. They don’t use XML as it is but instead use other languages based on XML.
4.1.2 SAML
Security Assertion Markup Language (SAML) is an open XML-based standard commonly used to exchange authentication and authorization (AA) information between federated organizations. It provides SSO capabilities for browser access.
The SAML 2.0 specification utilizes three entities: the principal, the service provider, and the identity provider.
- Principal or User Agent For simplicity, think of Sally as the principal. She’s trying to access her investment account at ucanbeamillionaire.com.
- Service Provider (SP) In this scenario, the ucanbeamillionaire.com site is providing the service and is the service provider.
- Identity Provider (IdP) This is a third party that holds the user authentication and authorization information.
When Sally accesses the site, it prompts her to enter her credentials. When she does, the site sends her credentials to the IdP. The IdP then responds with XML messages validating (or rejecting) Sally’s credentials and indicating what she is authorized to access. The site then grants her access to her account.
The IdP can send three types of XML messages known as assertions:
- Authentication Assertion This provides proof that the user agent provided the proper credentials, identifies the identification method, and identifies the time the user agent logged on.
- Authorization Assertion This indicates whether the user agent is authorized to access the requested service. If the message indicates access is denied, it indicates why.
- Attribute Assertion Attributes can be any information about the user agent.
Many cloud service providers include SAML in their solutions because it simplifies the services for their customers. SAML provides authentication assertion, attribute assertion, and authorization assertion.
4.1.3 OAuth
OAuth 2.0 (implying open authorization) is an authorization framework described in RFC 6749 and maintained by the Internet Engineering Task Force (IETF). Many companies on the internet use it to share account information with third-party websites.
For example, imagine you have a Twitter account, and you download an app called Acme that can interact with your Twitter account and schedule Tweets in advance. When you try to use the feature in the Acme app, it redirects you to Twitter. Twitter prompts you to log on, shows you what permissions the Acme app will access, and then asks if you want to authorize the Acme app to access your Twitter app. If you approve, Twitter sends the Acme app an authorization token. The app may accept and enter the authorization token directly, or you may need to enter it into the app’s settings. When the app accesses the Twitter account, it sends an API message and includes the token. Note that this doesn’t provide authentication. Instead, it authorizes access to the account. A primary benefit is that you never provide your Twitter credentials to the Acme app. Even if the Acme app is compromised, it does not expose your credentials.
4.1.4 OpenID
OpenID is also an open standard, but it is maintained by the OpenID Foundation rather than as an RFC standard. It provides decentralized authentication, allowing users to log into multiple unrelated websites with one set of credentials maintained by a third-party service referred to as an OpenID provider.
When users go to an OpenID-enabled website (also known as a relying party), they are prompted to provide their OpenID identity as a URI. The OpenID-enabled website and an OpenID provider exchange data and create a secure channel. The user is then redirected to the OpenID provider and is prompted to provide the password. If correct, the user is redirected back to the OpenID-enabled site.
The site doesn’t support HTTPS so use HTTP. One thing you’ll see is that it’s always obvious when you’re using OpenID because you have to enter your OpenID identifier.
In contrast, other methods exchange data behind the scenes, so it isn’t as obvious what method is being used.
4.1.5 OpenID
Connect (OIDC) is an authentication layer using the OAuth 2.0 authorization framework. A key point is that it provides both authentication and authorization. Like OpenID, it is maintained by the OpenID Foundation.
It builds on the technologies created with OpenID but uses a JavaScript Object Notation (JSON) Web Token (JWT), also called an ID token. OpenID Connect uses a web service to retrieve the JWT. In addition to providing authentication, the JWT can also include profile information about the user.
Most of this occurs behind the scenes, but you can see it in action by logging onto eBay with a Google account.
OAuth and OIDC are used with many web-based applications to share information without sharing credentials. OAuth provides authorization. OIDC uses the OAuth framework for authorization and builds on the OpenID technologies for authentication. OIDC uses JSON Web Tokens.
4.1.6 Comparing SAML, OAuth, OpenID, and OIDC
The following bullets outline the key points about SAML:
SAML 2.0 is an open XML-based standard.
OASIS adopted it as a standard in 2005.
It utilizes three entities: a principal (such as a user), a service provider (such as a website), and an identity provider (a third party that holds the authentication and authorization information).
It can provide authentication, authorization, and attribute information on the principal.
The following bullets outline the key points about OAuth:
It’s an authorization framework, not an authentication protocol.
RFC 6749 describes OAuth 2.0.
It exchanges information using APIs.
An app obtains an access token from an identity provider.
Later, the app includes the access token for authorization.
The following bullets outline the key points about OpenID:
OpenID is an authentication standard.
It is maintained by the OpenID Foundation.
An OpenID provider provides decentralized authentication.
Users enter their Open ID identifier (such as bobsmith2021.myopenid.com) on a site and the OpenID provider verifies the identifier.
The following bullets outline the key points about OIDC:
OIDC is an authentication layer using OAuth 2.0.
It builds on the OpenID authentication standard.
It provides both authentication and authorization.
It builds on OpenID but uses a JSON Web Token.
4.2 Implementing SSO on Internal Networks
SSO solutions are also used on internal networks. Kerberos is the most common, and it’s an important authentication system to know for the CISSP exam. Network access methods allow users to access internal networks from remote locations (such as at home). Two common remote access protocols are RADIUS and TACACS+. In addition to supporting SSO, RADIUS and TACAS+ provide authentication, authorization, and accounting.
4.2.1 AAA Protocols
Several protocols provide authentication, authorization, and accounting and are referred to as AAA protocols. These provide centralized access control with remote access systems such as virtual private networks (VPNs) and other types of network access servers. They help protect internal LAN authentication systems and other servers from remote attacks.
These AAA protocols use the access control elements of identification, authentication, authorization, and accountability. They ensure that users have valid credentials to authenticate and verify that they are authorized to connect to the remote access server based on the user’s proven identity. Additionally, the accounting element can track the user’s network resource usage, which can be used for billing purposes. Some common AAA protocols are covered next.
4.2.2 Kerberos
Ticket authentication is a mechanism that employs a third-party entity to prove identification and provide authentication. The most common and well-known ticket system is Kerberos.
Kerberos offers a single sign-on solution for users and protects logon credentials. Kerberos version 5 relies on symmetric-key cryptography (also known as secret-key cryptography) using the Advanced Encryption Standard (AES) symmetric encryption protocol. Kerberos provides confidentiality and integrity for authentication traffic using end-to-end security and helps protect against eavesdropping and replay attacks
Kerberos uses several different elements that are important to understand:
Key Distribution Center The Key Distribution Center is the trusted third party that provides authentication services. Kerberos uses symmetric-key cryptography to authenticate clients to servers. All clients and servers are registered with the KDC, and it maintains the secret keys for all network members.
Kerberos Authentication Server The authentication server hosts the functions of the KDC: a ticket-granting service (TGS) and an authentication service (AS). However, it is possible to host the ticket-granting service on another server. The authentication service verifies or rejects the authenticity and timeliness of tickets. This server is often called the KDC.
Ticket A ticket is an encrypted message that provides proof that a subject is authorized to access an object. It is sometimes called a service ticket (ST). Subjects (such as users) request tickets to access objects (such as files), and if they have authenticated and are authorized to access the object, Kerberos issues them a ticket. Kerberos tickets have specific lifetimes and usage parameters. Once a ticket expires, a client must request a renewal or a new ticket to continue communications with any server.
Ticket-Granting Ticket A ticket-granting ticket (TGT) provides proof that a subject has authenticated through a KDC and is authorized to request tickets to access other objects. A TGT is encrypted and includes a symmetric key, an expiration time, and the user’s IP address. Subjects present the TGT when requesting tickets to access objects.
Kerberos Principal Kerberos issues tickets to Kerberos principals. A Kerberos principal is typically a user but can be any entity that can request a ticket.
Kerberos Realm Generically, a realm is an area controlled or ruled by something. A Kerberos realm is a logical area (such as a domain or network) ruled by Kerberos. Principals within the realm can request tickets from Kerberos, and Kerberos can issue tickets to principals in the realm.
The Kerberos login process works as follows:
1 The user types a username and password into the client.
2 The client encrypts the username with AES for transmission to the KDC.
3 The KDC verifies the username against a database of known credentials.
4 The KDC generates a symmetric key that will be used by the client and the Kerberos server. It encrypts this with a hash of the user’s password. The KDC also generates an encrypted timestamped TGT.
5 The KDC then transmits the encrypted symmetric key and the encrypted timestamped TGT to the client.
6 The client installs the TGT for use until it expires. The client also decrypts the symmetric key using a hash of the user’s password.
Note that the client’s password is never transmitted over the network, but it is verified. The server encrypts a symmetric key using a hash of the user’s password, and it can only be decrypted with a hash of the user’s password. As long as the user enters the correct password, this step works. However, it fails if the user enters the incorrect password.
When a client wants to access an object, such as a resource hosted on the network, it must request a ticket through the Kerberos server. The following steps are involved in this process:
1 The client sends its TGT back to the KDC with a request for access to the resource.
2 The KDC verifies that the TGT is valid and checks its access control matrix to verify that the user has sufficient privileges to access the requested resource.
3 The KDC generates a service ticket and sends it to the client.
4 The client sends the ticket to the server or service hosting the resource.
5 The server or service hosting the resource verifies the validity of the ticket with the KDC.
6 Once identity and authorization are verified, Kerberos activity is complete. The server or service host then opens a session with the client and begins communications or data transmission.
However, Kerberos presents a single point of failure—the KDC. If the KDC is compromised, the secret key for every system on the network is also compromised. Also, if a KDC goes offline, no subject authentication can occur.
4.2.3 RADIUS
Remote Authentication Dial-in User Service (RADIUS) centralizes authentication for remote access connections, such as with VPNs or dial-up access.
It is typically used when an organization has more than one network access server (or remote access server). A user can connect to any network access server, which then passes on the user’s credentials to the RADIUS server to verify authentication and authorization and to track accounting. In this context, the network access server is the RADIUS client, and a RADIUS server acts as an authentication server. The RADIUS server also provides AAA services for multiple remote access servers.
RADIUS uses the User Datagram Protocol (UDP) by default and encrypts only the password’s exchange. It doesn’t encrypt the entire session, but RADIUS can use other protocols to encrypt the data session. The current version is defined in RFC 2865. RFC 6614, designated as Experimental, defines how RADIUS can use Transport Layer Security (TLS) over Transmission Control Protocol (TCP).
4.2.4 TACACS+
Cisco developed Terminal Access Controller Access Control System Plus (TACACS+) and later released it as an open standard. It provides several improvements over the earlier versions and over RADIUS.
It separates authentication, authorization, and accounting into separate processes, which can be hosted on three different servers if desired. Additionally, TACACS+ encrypts all of the authentication information, not just the password, as RADIUS does. TACACS+ uses TCP port 49, providing a higher level of reliability for the packet transmissions.
