5.6 Implement authentication systems

  • OpenID Connect (OIDC) / Open Authorization (Oauth)
  • Security Assertion Markup Language (SAML)
  • Kerberos
  • Remote Authentication Dial-In User Service (RADIUS) / Terminal Access Controller Access Control System Plus (TACACS+)

Some authentication systems

  • 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
  • Diameter.  Diameter is a more advanced version of RADIUS.  Its advantages include

    • It provides end-to-end security

    • It provides a connection-oriented protocol over TCP, which makes it more reliable

    • It can allow us to negotiate application-level security protocols
  • 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).

  • 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.

  • NTLM 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.

  • 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..