3.8 Given a scenario, implement authentication and authorization solutions

  • Authentication Management
    • Password Keys
    • Password Vaults
    • TPM
    • HSM
    • Knowledge-Based Authentication
  • Authentication / Authorization
    • EAP
    • Challenge-Handshake Authentication Protocol (CHAP)
    • Password Authentication Protocol (PAP)
    • 802.1X
    • RADIUS
    • Single Sign-On (SSO)
    • Security Assertion Markup Language (SAML)
    • Terminal Access Controller Access Control System Plus (TACACS+)
    • OAuth
    • OpenID
    • Kerberos
  • Access Control Schemes
    • Attribute-Based Access Control (ABAC)
    • Role-Based Access Control
    • Rule-Based Access Control
    • MAC
    • Discretionary Access Control (DAC)
    • Conditional Access
    • Privileged Access Management
    • Filesystem Permissions


Authentication Management

When we each have eight billion passwords and must change them every three months, it becomes a problem.  People start writing them down either on paper or in an Excel spreadsheet.  If either of those gets lost or if somebody finds it then we have a disaster.

So, we need a better way to store our passwords

  • Password Keys.  This is a USB key that stores all of our passwords.  When we want to log into a site or resource, we insert the USB key and the key gives the site the correct password.

  • Password Vaults.  This is a software app that stores all of our passwords.  The vault encrypts our passwords.  It can also sync our passwords between different devices such as our desktop, our laptop, and our smart phone. 

    When we first log in to our device, the vault decrypts our passwords.  When we attempt to log in to a resource, the vault presents the appropriate password to the resource.  When we log our or shut down the device, the vault automatically encrypts our passwords.

    We must be careful to choose a password vault that is secure.  It is difficult to know if a vault has a back door because most of them are not open source. 

    Since we don’t need to remember any more passwords, we can randomly generate long, secure passwords and store them.

  • TPM.  As mentioned earlier, a Trusted Platform Module is a chip, and the purpose of the TPM is to ensure that a piece of computer hardware boots up using trusted hardware and software.  A TPM prevents a malicious person from booting a computer with a modified operating system.  It can also store the encryption keys for the computer’s data.

    Those encryption keys are then further encrypted with the user’s password.

  • HSM.  A Hardware Security Module manages digital keys for cryptoprocessing.  It can be a physical chip on the computer’s system board or a separate card.

  • Knowledge-Based Authentication.  KBA is a procedure where we can verify a user’s identity based on what they know.  We might have a predetermined set of security questions and ask the user one of them.  Or we might choose a new question based on information that we collect from private databases such as a credit report.

Authentication / Authorization

Now that we covered user credentials, how do we actually validate them?  What is the mechanism that compares what the user provided against what is correct?  There are several ways

  • EAP.  EAP is a framework for providing authentication, but there are more than 40 possible methods that can be used.  We covered the variations of EAP earlier including LEAP, PEAP, EAP-TLS, etc.

  • Challenge-Handshake Authentication Protocol (CHAP).  CHAP is Challenge-Handshake Authentication Protocol.  It authenticates a network host with a server/ISP.  CHAP protects against replay attacks.

CHAP uses PPP (Point to Point Protocol) to validate the identity of each client through a three-way handshake.

  • The link is established between the client and the server

    • The authenticator sends a challenge message to the peer

    • The peer combines the challenge message with its secret, and calculates a one-way hash, which it returns

    • The authenticator calculates its own hash value, verifies that the hash sent by the peer matches

    • If the hashes match, then the client is authenticated

    • The authenticator will randomly send additional challenge messages to the peer while the connection is active.  Each challenge will have a new ID.

CHAP requires a shared secret between the client and the server.

  • Password Authentication Protocol (PAP).  PAP or Password Authentication Protocol is a protocol used to validate users.  PAP is considered weak but supported by almost all network operating systems.

    PAP sends usernames and passwords over plaintext.

PAP protocol

  • Client sends the username/password to the server continually until a response is received
    • Server returns either “ack” if the credentials are correct or “nak” if the credentials are incorrect
  • 802.1X.  As mentioned earlier, IEEE 802.1X is a standard for Network Access Control.  It allows a device to authenticate when connecting to a LAN or WAN.

    • There are three devices

      • The supplicant is the device that chooses to connect to the LAN/WAN.  It could be a laptop, desktop, smartphone, tablet, or other computing device

      • The authenticator is a network device that allows/denies access.  It could be a switch, a router, a firewall, or a proxy server.

      • The authentication server is a server that decides whether a particular device should be granted access

    • The procedure

      • The supplicant connects to the network

      • The authenticator (switch) detects the new supplicant and automatically sets the port to an unauthenticated state.  Only traffic related to 802.1X is permitted.

      • The authenticator sends frames to the supplicant.  These frames demand that the supplicant provide credentials such as a user ID.  The frames are sent on the local network segment to a specific address (01:80:C2:00:00:03).  The supplicant listens for messages on this address.

      • The supplicant replies to the message with an EAP-Response Identity frame

      • The authenticator sends the supplicant’s response to an authentication server

      • The authentication server and the supplicant negotiate an authentication method.  The server and the supplicant may support different methods and must agree on one.  The negotiation methods are transported through the authenticator.

      • The authentication server attempts to authenticate the suppliant.  If successful, the authenticator changes the port status to authorized.  If unsuccessful, the authenticator keeps the port as unauthorized.

      • When the supplicant logs off or is disconnected, the authenticator changes the port status back to unauthorized.  When the supplicant logs off, it sends an EAPOL-Logoff message to the authenticator.


  • RADIUS.  RADIUS, or Remote Authentication Dial-In User Service, is a server that has three components

    • Protocol

    • Server

    • Client

The Network Access Server is a Client of the RADIUS Server.  It can be any device that the user wants to access.  When a user attempts to log in to the client, the client sends user information to the RADIUS server.  The client and server encrypt their data with a shared secret, but the communication between the user and the client are not encrypted.

The RADIUS server receives connection requests and authenticates the user.  RADIUS does not allow different privilege levels (all users are effectively superadmins).  A RADIUS server combines authentication and authorization. 

Authentication

  • Many methods are possible including PPP, PAP, and CHAP

    • The client sends the RADIUS server the user’s username and encrypted password

    • The RADIUS server replies with

      • Accept – the user is authenticated

      • Reject – the user is rejected (credentials invalid)

      • Challenge – the user must provide additional information

Authorization

  • Authorization tells the client what privileges to assign to the user

Accounting

  • Accounting data is transmitted at the beginning and end of a session
  • Single Sign-On.  Single Sign-On uses a central system to authenticate users across multiple applications.


For example, a user logs in to his computer via his Windows Active Directory password.  He is then able to access the corporate intranet, procurement application, online library, payroll, and e-mail without having to re-enter a username or password.

Once logged in, the remaining applications understand that the user is already authenticated.  In the background the applications receive authorization from the Active Directory server.

A user (and the organization) does not have to maintain separate usernames/passwords for each application.

If the single sign on system fails, then the user will not be able to access any of the applications.

Increasingly, social media sites such as Google and Facebook provide SSO services to other websites.  For example, a user can use their Facebook account to log in to another site.  Using Facebook for Single Sign On is a bad idea because Facebook will collect data about your visits to other websites and the websites will collect data from your Facebook account.

SAML.  Security Assertion Markup Language or SAML is a standard for exchanging authentication and authorization data. 

SAML is typically used to allow a user to log in through a web-browser Single Sign On

SAML has three roles

  • The Principal, also known as the user

    • The identity provider (IdP).  The IdP identifies the Principal.

    • The Service Provider (SP).  The SP provides a service to the Principal and requires proof of his identity.

The procedure works as follows

  • The Principal requests a service from the SP.  For example, a user attempts to log in to his online banking account. 

    • The SP sends the user back to the IdP.  For example, the user’s bank accepts identity verification from Gmail and several other sources.  The user chooses Gmail, so the bank sends the user to the Gmail website.

    • The user requests a Single Sign On from the IdP.  This may happen automatically.  For example, the user is required to log in to Gmail and obtain the response.

    • The IdP responds with an XHTML form.  The form contains the IdP’s response to the SSO request (which may be positive or negative).

    • The SSO response is provided back to the SP.  This is handled through a process called an Assertion Consumer Service.

    • The user is redirected to the target resource.  The user returns to the online banking website.

    • This time, the target resource is provided to the user.  The user is not redirected to the IdP again because he has been authenticated.

  • Terminal Access Controller Access Control System Plus (TACACS+).  TACACS or Terminal Access Controller Access-Control System is a protocol for accessing/managing network devices.  It was developed by UNIX.

TACACS+ was developed by Cisco and is a separate protocol from TACACS.  Most network systems use TACACS+ or RADIUS.

TACAS uses port 49 to communicate.

TACACS+ encrypts the full content of each packet while RADIUS encrypts only the user passwords.  TACACS+ uses TCP, while RADIUS uses UDP (therefore RADIUS has more errors).  Cisco continues to support RADIUS, but TACACS+ is recommended.

TACACS+ uses the AAA (Authentication, Authorization, and Accounting) architecture, where each element is separate.  Therefore, a system could use a different form of authentication (such as Kerberos) with TACACS+ authorization and accounting.  Some forms of authentication

  • Point-to-Point
    • PAP
    • CHAP
    • EAP
    • Kerberos

Authentication Procedure

  • The client sends a START message to the server

    • The server sends a REPLY message

    • The client sends a CONTINUE message, if additional information is required for authentication

    • Otherwise, authentication is complete

Authorization Procedure

  • A default state of “unknown user” is created if the user’s identity is unknown

    • Otherwise, the TACAS+ server responds with a RESPONSE message, which contains the restrictions on the user that has logged in

Accounting

  • A START message records when the user started the connection

    • A STOP message records when the user stopped the connection

    • An UPDATE message says that a task is still being performed

TACACS+ allows an administrator to configure different privilege levels for each user (for example a user may not be permitted to modify an ACL on a router).  RADIUS does not allow different privilege levels (all users are effectively superadmins).

  • OAuth.  OAuth and OAuth 2.0 are services that allow a user to authenticate with a service provider.  OAuth 2.0 is the current version and is not compatible with OAuth 1.0.   OAuth is used with OpenID.

    OAuth is an authorization protocol.

    • The user visits a website or resource and tries to log in

    • The resource creates a request for the IdP

    • The resource sends the request for the IdP as part of a redirect URL to the user

    • The user goes to the redirect URL and accesses the IdP

    • The IdP authenticates the user if they are not already logged in

    • The IdP creates a response, which it gives to the user, as well as a redirect URL to the original resource

    • The user visits the redirect URL

    • The resource reviews the IdP’s response and either provides or denies access

OAuth is used by Google, Facebook, Microsoft, and Twitter among other companies.  When a website owner implements OAuth through one of those companies, then they can allow users to log in without having a username or password.  A user can log in to my website with their Facebook account for example, but they never have to enter their Facebook username or password into my website.

  • OpenID Connect.  OpenID Connect is a service that works on top of OAuth and OAuth 2.0, which is a standard for allowing users to connect to websites without having to provide passwords.

OAuth provides authorization, but not authentication.  The OpenID Connect provides authentication, but not authorization.  Thus, both are typically required.  OAuth operates on top of OpenID.

Typically, the OAuth service provider requires the user to authenticate.  As a result, OAuth should not be used for authentication, only for authorization.

The process

  • The user requests the resource from a service provider

    • The service provider requests authentication/authorization from the identity provider

    • The identity provider authenticates/authorizes the user

    • The user is redirected back to the service provider

    • The service provider reads the response from the identity provider and determines if the user should be provided with access

    • OpenID obtains additional user data from the Identity Provider through a RESTful API.  The data is provided in JSON format.


  • Shibboleth.  Shibboleth is a system that allows a user to identify themselves to different online services with one user ID.  It works like the other systems mentioned (OpenID).  This system is commonly used by universities.


An Identity Provider (IdP) supplies user information to a Service Provider (SP) which provides a user with required services.

Shibboleth 2.0 is the current version.  It allows the SP to request additional information from the IdP.

The process

  • A user requests a service from the SP

    • The SP sends the user a request (in a URL) that encodes the entityID, location, and page to return the user to

    • The user is sent to their IdP, where they can sign in.  The system that they are on will typically detect the user’s home IdP.  If not, the user might be prompted to identify where they are from.

    • The user authenticates themselves at the IdP

    • The Shibboleth creates a temporary handle that is linked to the IdP request

    • The user returns to the SP, which requests additional information about the user’s identity from the IdP

    • The IdP returns the requested data to the SP

    • The SP uses the information to decide whether to provide access

For example, a user at the University of Alberta is issued a single user ID known as a Campus Compute ID.  This ID provides the user with access to

  • Beartracks (a course registration website)

    • eClass (a website that contains course data such as notes, textbooks, and exams)

    • Library website (access to databases, etc.)

    • Finance website where they can pay their tuition

    • Many other websites, some of which may be internal, and some of which may be external.  The University would like to restrict access to only members of its community.

The University of Alberta operates a central authentication service.  This service allows the user to authenticate with their central service through Shibboleth, and then provide access to the other resources.

For example, a user visits the library website from a campus computer.  The user is asked to log in to their University of Alberta account.  In the background, the University’s authentication service communicates with the library’s website to identify the user who requires access.  It is not enough to authorize the user; the library also needs to know the identity of the user.  The library will want to inform the user of the books that he has checked out, holds, fines, etc..

  • Kerberos.  Kerberos is a protocol that allows clients and servers to authenticate with each other and prove their identities.  The Kerberos protocol protects against eavesdropping and replay attacks.  Kerberos uses UDP port 88.  Kerberos provides encryption over an unsecure network.

Kerberos’ current version is V5.  It was developed by MIT and made available for free.

All versions of Windows including Windows 2000 and later use Kerberos for authentication by default (although other protocols can be used).  Kerberos is used to join a client to a Windows domain.

Most common versions of UNIX also use Kerberos.

If a client wishes to connect, the following procedure is followed. 

  • The client calls the Authentication Server (AS) to obtain authentication. 

    • The authentication server takes the client’s username and sends it to another server called the Key Distribution Center (KDC). 

    • The KDC runs a service known as the Ticket-Granting Service (TGS), which maintains a secret key. 

    • The KDC issues a ticket known as the Ticket-Granting Ticket (TGT) and encrypts it with the secret key. 

    • The encrypted key is sent back to the client.

How it actually works

  • A user would like to log in to a Windows machine, with a username and password.  Even on a corporate network, the password should not be sent to the server (domain controller) in plain text.

    • The user enters his username and password

    • The Windows machine encrypts/hashes the password

    • The client sends the user ID to the authentication server (in plain text).

    • The Authentication Server verifies that the username is in the database.  If the user is in the database, the AS creates a secret key from the hash of the user’s password stored in the database and returns to the client the following messages

    • A TGS Session Key, which is encrypted with the newly created secret key (Message A)

    • A TGT, which includes an expiry date, the client’s network address, all encrypted with the TGS’s secret key (Message B)

    • The client takes the TGS Session Key and decrypts it with the hash of the password entered earlier.  If the client entered the wrong password, then the client will be unable to decrypt the TGS Session Key, and the user will have to try again.

    • The client uses the decrypted TGS Session Key to communicate with the TGS

When the user is requesting additional services

  • Client sends additional messages to TGS

    • Message C is the TGT from Message B and the ID number for the requested service

    • Message D is the authenticator (client ID and time stamp), encrypted with the Client/TGS

    • TGS obtains Message B from Message C and decrypts it (Only TGS has the encryption key for Message B).  TGS uses this to decrypt Message D.

    • If the Client ID in Message C and Message D match, then the client is authenticated

    • TGS sends additional messages

      • Message E is the Client-to-Server Ticket, which includes the client ID, network address, and expiry, encrypted using the service’s secret key

      • Message F is the Client/Server Session Key, encrypted with the Client/TGS Session Key

    • The client takes Message E and Message F and uses them to authenticate with the Service Server

    • The client sends

      • Message E from before

      • Message G, which is an authenticator, including the client ID, and timestamp

    • The SS decrypts Message E with its own secret key and obtains the Client/Server session Key.  It uses this key to decrypt Message G.  If they match, then the client is authenticated with the service

    • The SS sends Message H to the client, which includes the timestamp in Message E, encrypted with the Client/Server Session Key

    • The client decrypts Message H.  If the timestamp on Message H is correct, then the client knows it can trust the server.  A rogue agent could issue a fake message but would not be able to match the timestamp.


The encrypted key will expire, but if the user is logged in, the key will renew (the client will automatically contact the server and obtain an updated key).

To communicate with another node, the ticket is sent back to the service.    The TGS verifies that the user is permitted to access the service and then sends the ticket to the Service Server (SS).

Kerberos has a single point of failure, which is the authentication server. 

Kerberos also requires the clients, servers, and services to be responsive (since timestamps must match on all devices).  That means that all devices must have synchronized clocks.  If a client/server issues a ticket/message with a timestamp that doesn’t match due to a clock that is out of sync, then the system will fail.  Clocks must not be more than five minutes apart.

  • or New Technology LAN Manager is a Microsoft system that allows users to authenticate with a server.  NTLM is considered weak and should not be used.

Access Control Schemes

There are different models for access control in an organization.  The specific control chosen depends on the needs of the organization, the type of data being protected, and the type of users.  An organization may implement multiple access control models.

Access Control permissions usually relate to being able to read, write, delete, and/or modify a file, and list contents of a folder.  Additional, more extensive permissions, can apply to a database (such as the ability to read, write, delete, or modify entries in a database, create tables in a database, or create users in the database).

The permissions can apply to the entire system or granularly to specific files.

MAC – Mandatory Access Control

  • Each user has certain permissions on the system

  • The user cannot grant his permissions to other users

  • For example, if a user has read access to a file, the user cannot grant another user with read access to the file

  • The user cannot modify any of the permissions on the file

DAC – Discretionary Access Control

  • A user has certain permissions

  • The user can grant his permissions to other users

  • For example, if a user has read access to a file, the user can grant another user with read access to the file

  • An example of when DAC is better than MAC: a project manager has access to files related to his projects; the project manager grants access to other members of the team.  The project manager does not have to contact an IT person to obtain access for members of his team.

  • An example of when MAC is better than DAC: an intelligence analyst needs to grant a co-worker access to classified documents; the analyst should not be able to do so; the individual requesting access must have a need-to-know basis and appropriate security clearances, which need to be verified by a central authority

ABAC – Attribute-Based Access Control

  • Each user has certain attributes (for example, the user’s role in the organization, age, security clearance, department, etc.)

  • Each resource has certain attributes (for example, the contents, department, owner, etc.)

  • When the user attempts to access the resource, the system uses the user’s attributes and the resource’s attributes to determine whether to provide access.

  • ABAC is more complicated because the system requires many rules to decide whether to permit/deny a user.  If a rule does not exist, then the default action is to deny the access.  It might take a substantial amount of work to set up all the rules.

Role-Based Access Control

  • Permissions are not assigned to individual users or to objects

  • Permissions are assigned to operations/actions (known as roles)

  • A user can be assigned to a specific role; the user inherits the permissions assigned to the role

  • The organization can define the operations and actions that are relevant to their organization.  For example:

    • Sales person (can access sales data)

    • Accountant (can enter data into the accounting system)

    • Accounts payable clerk (can approve invoices and issue payments)

Rule-Based Access Control

  • Permissions are not assigned to individual users or objects

  • Instead, a set of rules exist; the rules may permit or deny specific actions depending on the attributes

  • Each time an action is attempted, the system evaluates the action against the set of rules

  • The rules do not consider who is attempting the action, only what the action is

Conditional Access

  • We can use AI to make more complicated access decisions when a user needs to access a resource.

  • Some factors that the AI might consider

    • User role.  Does the user have permission to access this resource?

    • IP address.  Where is the user currently located?

    • Device type.  Is the user attempting to access the resource from a smartphone, a corporate device, or a personal device?

    • Application type.  What application is the user attempting to access?

    • Risky sign in behavior. 

  • AI and machine learning can gather data over time to create a threat assessment that can more accurately predict whether access to a resource is legitimate.

Privileged Access Management

  • Privileged Access Management determines whether a user account can access a privileged resource

  • We might create a set of privileged user accounts for use by administrators.  An administrator might have a privileged account in additional to his normal user account.

  • We can apply the same AI rules to privileged accounts that we did to regular accounts.

Filesystem Permissions

File system permissions vary from operating system to operating system and from file system to file system.

In a UNIX file system, we can set permissions on each file and directory

The permission is encoded as a 10-character string that looks like this

-|—|—|—|

Each dash is a character.

  • The first character is a – if the file is a regular file, a ‘c’ if the file is a character special file, or a ‘d’ if the file is a directory

  • The next three characters tell us the permissions that the owner has on a file

    • The first one is either – or r (r if the owner is permitted to read the file)

    • The second one is either – or w (w if the owner is permitted to write (modify)to the file)

    • The third one is either – or x (x if the owner is permitted to execute the file)

  • The next three characters tell us the permissions that a group has on a file.  Each file must be assigned to a group.  Members of that group now have the permissions assigned to that file or directory.

    • The first one is either – or r (r if the group member is permitted to read the file)

    • The second one is either – or w (w if the group member is permitted to write (modify)to the file)

    • The third one is either – or x (x if the group member is permitted to execute the file)

  • The last three characters tell us the permissions that other users have on a file

    • The first one is either – or r (r if the other users are permitted to read the file)

    • The second one is either – or w (w if the other users are is permitted to write (modify)to the file)

    • The third one is either – or x (x if the other users are is permitted to execute the file)

  • When a file is a directory

    • The r (or read) attribute tells us whether the user/group can list the files in the directory (view the directory contents)

    • The w attribute tells whether a user/group can create/modify/delete files in a directory.  The x attribute must also be set with the w attribute, or the user won’t be able to do anything.

In conclusion

  • We have permissions for whether a user or group member can read, write, and/or execute a file

  • We have permissions for whether a user or group can view the contents of a directory and whether a user or group member can create or delete files in a directory

UNIX allows us to set only one group per file/directory.  Windows is more complicated, especially when using the NTFS file system.

  • Each file or directory can have permissions set for an unlimited number of users and groups.

  • Permissions can be inherited.  If we set permissions on a directory, all of the files and directories within it can inherit the same permissions.

  • The Windows permissions that can be set for each file/user/group combination

    • Full Control

    • Modify

    • Read & Execute

    • List Folder Contents

    • Read

    • Write

  • More advanced permissions include

    • Full Control

    • Traverse Folder / Execute File

    • List Folder / Read Data

    • Read Attributes

    • Read Extended Attributes

    • Create Files / Write Data

    • Create Folders / Append Data

    • Write Attributes

    • Write Extended Attributes

    • Delete Subfolders and Files

    • Delete

  • Each permission/user/group combination can have an “Allow” or a “Deny” setting.  Deny always takes priority over Allow.  Consider the following.  We want to give Read access to everybody in a group but one person.

    • We give the group read access by adding the group to the file permissions, and checking the Allow box next to Read

    • We deny the user read access by adding the user to the file permissions, and checking the Deny box next to Read

    • The user is denied access

    • If we did this the other way around (deny access to the group but allow access to the user), the user will not have access.