Table of Contents for

Cryptography and Network Security

Chapter 12

Authentication Applications

In the modern world of communication, Internet plays a vital role. But the major threat in Internet is many malicious users try to get unencrypted password communicated over the Internet with sniffing tools. With the different authentic services like Kerberos, X.509 and Public Key Infrastructure (PKI), only ­legitimate users will be allowed to access the intended services.

12.1 KERBEROS

Kerberos is an authentication protocol, which allows clients to communicate over a non-secure ­network environment based on the use of ‘tickets’ in order to prove their identity to one another in a secure manner. It is designed primarily for a client–server communication to provide mutual authentication by which the client and the server can verify each other’s identity in a secure manner. Hence, Kerberos authentication protocol gives protection against eavesdropping and replay attacks. Kerberos relies on the use of trusted third party during authentication and it is based on symmetric key cryptography and optionally use public key cryptography in certain forms of authentication.

For providing authenticated services in distributed computing environment, Massachusetts Institute of Technology (MIT) developed the Kerberos Authentication Service for Project Athena. Initial ­versions of Kerberos were used within the MIT. From Kerberos, Version 4 is widely used outside the MIT. ­Version 4 predominantly developed for Project Athena could not provide the functionalities that are required universally. Therefore, Version 5 was developed which could overcome the shortcomings of Version 4. Nowadays, the authentication problem can be overcome by bundling Kerberos with the operating system.

The major goals of Kerberos are authentication, authorization and accounting. It offers authentication both in one-way and mutual. Kerberos permits the services to utilize various authentication ­models. It also supports secure accounting system with reliability and integrity. For example, Kerberos can be implemented to provide authentication and authorization in various services such as remote login, remote file access and service management, etc.

12.1.1 Kerberos Terminologies

The following are the terminology or conventions that are used in Kerberos authentication service.

1. 1.Client: An entity who initiates the communication.
2. Authentication Server: An entity who verifies the identity of the client.
3. Ticket: It is a proof by which the client identifies itself to the server.
4. Plaintext: The actual text intended by the user to send as a message.
5. Encryption: The process of converting the plaintext to a meaningless form so that the attacker cannot realize the actual content of the message.
6. Ciphertext: With the help of encryption mechanism, the plaintext is converted to ciphertext.
7. Decryption: Retrieving the original plaintext from the ciphertext.
8. A secret-key cryptosystem: A single key called secret key is used for encryption and decryption.
9. A public-key cryptosystem: A key pair, namely, public and private key is used for encryption and decryption, respectively.

12.1.2 Kerberos Version 4

12.1.2.1 A Simple Authentication Protocol

If a network is not protected, any client can obtain unauthorized privileges from any server which leads to a security risk of impersonation. To counter this threat, the servers are required to authenticate the clients before providing the service. But, in the case of an open environment, the authentication of clients produce a considerable burden on each server. An alternative way to reduce the burden on each server is the use an Authentication Server (AS) which stores the passwords of all users in a centralized database. In addition to that, a unique secret key is shared between the AS and each server physically or in some other secure manner. Consider the following simple protocol:

Step 1: When the user (u) first logs on to the workstation, the client (C) module of the workstation sends a request message to AS which includes the user’s identity (UID), the user’s password (UP) and the server’s identity (SID).

Step 2: The AS verifies the user’s identity and its corresponding password in its database. If it holds, AS generates a ticket for the client which has the UID, network address (NA) and the SID. After generating the ticket, the ticket (T) is encrypted by the shared secret key (SSK) known to the AS and the server (S). Then the AS sends T to C. The main aim of encrypting T is to prevent from it alteration or forgery by an opponent.

Step 3: By using this T, the C can send a request to S for service. The request message of C contains UID2and T. Once the S receives the request message, it decrypts T and verifies UID in the ticket with unencrypted UID in the request message. If both are same, then S2considers that the user is authenticated and gives the requested service.

12.1.2.2 The Kerberos Version 4 Authentication Protocol

The simple authentication protocol contains various problems. First problem with the foregoing ­scenario is that the servers have not authenticated themselves to users. Without such authentication, an opponent can configure a false server in a different location to act as a real server so that messages from the user to a server were directed to different location. Hence, the false server located in a ­different position can deny the true service to the user. Second problem is that each user is asked to enter the ­password for accessing various services from various servers. For example, if the user wants to access mail server in the morning, file server in the afternoon and print server in the evening, then the user has to enter the same User Password (UP) three times. In such cases, opponent may get a greater ­oppurtunity to capture the password. Finally for getting, different services from different servers, different tickets are required in simple authentication protocol. These problems can be eliminated by introducing a new server called as Ticket Provider (TP).

The Kerberos version 4 authentication protocol is explained in Figure 12.1 and the six steps involved in this diagram are explained as follows.

Figure 12.1 Kerberos version 4 authentication protocol

Step 1: The C sends a message to the AS requesting access to the ticket provider (TP). The TP, ­provides tickets to authenticated users from the AS. The request message of C contains UID, the TP identity (TPID), and the time stamp (ts).

Step 2: Afer receiving this message, the AS generates a secret key (SK) from the UP, a session key (SEK) and the ticket (TTP) to communicate with TP. The ticket is encrypted using the TP’s secret key (STP). The AS responds to C with a message, encrypted using SK as shown below:

Step 3: The message is then decrypted by C2using its SK and then the session key and TTP are taken to approach the TP. For that, C sends a message to TP that includes the TTP plus the SID. In addition to that, C transmits an Authen message, which contains the ID of C’s user and a timestamp.

Where , which is used only once and it is not reusable unlike the ticket. This has a short life time.

Step 4: The TP then gets the SEK2by decrypting TTP using its STP which it shared between the TP and the AS.

Then, the TP uses the SEK to decrypt the Authen message. The TP can then verify the user identity and network address from the Authen message with that of the ticket TTP and ­network address with incoming message. If all are matched, then the TP2is assured that the user is the ­authenticated user. Then TP sends a message to C by encrypting it using the session key shared between TP and C. The TP includes a session key (SEKS) to be shared between C and the server S, SID, the timestamp and the ticket (TTS) used for a server through which a client can communicate with the server.

Where SKS is the secret key of the server.

Step 5: After receiving the message, the C decrypts the certificate using the session key SEK and gets the following.

Then, the C sends a message to server which includes the ticket TTS and a Authen message1.

Where

Step 6: The server can decrypt the ticket TTS using its secret key SKS, and gets the session key SEKS, and decrypt the Authen message1. Then S increment the timestamp by one for mutual authentication and finally, the client and server share a secret key for future message communications.

12.1.3 Kerberos Version 5

Kerberos Version 4 was developed to use in the MIT campus and later expanded to the world ­outside. To provide security mechanism in Kerberos, DES algorithm was mainly used. So, the weakness of DES impacted a lot in running Version 4 universally. In Version 5, it is overcome by tagging ­encryption-identifier with the cipher text and allowing other encryption algorithms to use.

In Kerberos Version 4, the hacker can get the ticket from AS by guessing the password and also, no authentication is required. Authentication in Version 5 is provided by other services rather than by itself, which helps to diversify the authorization facility.

Regarding the ordering of byte in message structures of Version 4, no specific standard followed by the sender. But in Version 5, the structures of message abide by standard such as Basic Encoding Rules (BER) and Abstract Syntax Notation one (ASN.1).

Version 5 has the capability of supporting different types of network address whereas Version 4 supports only Internet Protocol. Thus, Version 5 claims major advantages in the areas of security, authentication and interoperability over Version 4.

12.2 X.509 AUTHENTICATION SERVICES

ITU-T recommendation X.509 is a portion of the X.500 series of endorsements describing directory services. X.509 is an authentication service used for directories. X.509 is the international standard for constructing public key certificate and, used by S/MIME and SSL/TLS. This standard has gone through several versions. This standard not only recommends the use of RSA algorithm, but also other public key algorithms can be used.

X.509 works under asymmetric key cryptography, digital signatures and PKI in which the major trust is on the key pairs. For example, if the key pair is 4Key 1, Key 24, where Key 1 and Key 2 are distinct values; either of the keys can be used for encrypting the data. In case if Key 1 is used for encryption, then Key 2 is used for decryption or vice versa. Once the key pair is generated, one of the keys is publicly announced and the other is kept secret.

For an entity E, an X.509 certificate is produced which holds the public key for it. Entity E can prove its identity by presenting its X.509 certificate and sample encrypted data using its private key. The ­reason behind is that, only the owner can encrypt the data using the private key. By proving the identity, the owner of the certificate becomes trusted and the transaction can be preceded safely with the assurance of no masquerading. Mutual authentication can be organized naturally by making everyone to hold a copy of the certificates for all the entities they trust and checking the list of all trusted certificates when an entity is presented with a certificate. The scalability of this scheme does not hold good for a legitimate user whose trusted list is very large and keeping update of list is too hard. The solution for this scenario is to have a certificate issuer, Certification Authority (CA) who is common to all. By issuing a certificate to an entity, the CA guarantees the legitimacy of the owner of the certificate. When an entity trusts CA, it apparently trusts the certificates issued by CA. Entity transacts with the certificates received from CA having CA’s identity. The common form of the certificate is shown in Figure 12.2.

The fields given in the above format cover all the three versions of X.509. In Section 12.2.1, elaborate explanation about fields is given. Mandatory information of X.509 certificate is the identity of the issuer, i.e. the CA, expiry or termination date of the certificate, distinguished name of the entity that the certificate belongs to and public key of the entity.

12.2.1 X.509 Formats

The following section describes the fields available in X.509 Version 1 and Version 2 for public key ­certificates. In 1988, X.509 Version 1 was approved and in 1993, Version 2 was approved, where ­Version 2 contained only minor enrichments to the X.509 Version 1. Figure 12.3 depicts the fields in the Version 1 certificate standards.

The following text describes the fields in X.509 certificate Version 1 and Version 2.

1. 1. Version: The version field depicts the version of the corresponding certificate format; as of now, there are three versions, namely, 1, 2 and 3; it also has provisions for future versions of the X.509 authentication service standard.
2. Serial number: The serial number field states the numerical identifier of the certificate which is unique in the domain of all public key certificates issued by the CA. At the time of certificate revocation, this serial number is the identifier which is posted on the certificate revocation list (CRL) signed by the CA because posting the entire certificate in the CRL is inefficient and unwanted. As it is used as identifier for revocation of certificate, this identifier has to be unique.
3. Signature algorithm: The signature algorithm field finds the algorithm the CA used to sign the certificate. This algorithm identifier states both the public key and the hashing algorithm, and this number is registered with an internationally registered organization.
4. Issuer X.500 name: The issuer X.500 field denotes the X.500 DN of the CA which issued the certificate. To denote the CA which issues certificate to the employees of the MIOT corporation in the United States, the DN c=US, o=MIOT Corporation can be used.
5. Validity period: The validity period field indicates the start and expiry date of the certificate. Whenever a certificate is used, its validity period has to be checked upon.
6. Subject X.500 name: The subject X.500 name field tells the X.500 DN of the entity which holds the private key matching to the public key identified in the certificate. For example, DN for the employee John Smith of the MIOT Corporation is c=US, o=MIOT Corporation, cn=John Smith.
7. Subject public key information: The subject public key information field points out two vital pieces of information, the former id the value of the public key owned by the subject and the latter is the algorithm identifier pointing out the algorithm with which the public key is to be used.

   Figure 12.4 depicts the fields in the Version 2 certificate standards.

8. Issuer unique identifier: The issuer unique identifier field was incorporated to the X.509 certificate definition as part of the Version 2 X.509 standard. This is an optional field which provides a location to specify a bit string to uniquely identify the issuer X.500 name, when at the same time that particular X.500 been assigned to more than one CA over time.
9. Subject unique identifier (Version 2 only): This field was included in Version 2 of X.509 certificate definition. The field, which is non-compulsory, delivers a location to specify a bit string to uniquely identify the subject X.500 name, when the same X.500 name has been assigned to more than one subject over time.

12.2.2 Version 3 X.509 Certificates

To include additional information, Version 3 introduced a mechanism in which certificates can be extended in a generic and standardized fashion. Version 3 X.509 standard defined some broadly ­applicable extensions to the Version 2 certificate; this is referred as ‘standard extensions’. Anybody can register extensions with appropriate authorities like ISO. New broadly applicable extensions are used to augment with the set of standard extensions.

Figure 12.4 X.509 Version 2 with sample field values

Each extension comprises three fields: type, criticality and value. Figure 12.5 shows the structure of an extension.

Figure 12.5 Structure of standard extension

The type of the data in the extension type field is defined by the extension type field. The type extension can be a simple text string, a numerical value, a date, a graphic or a complex data structure. Registering all extensions with an internationally recognized standards organization will help to promote interoperability. To make some information more importance when an application is processing some certificate, that information’s extension field can be flagged as extension criticality field and if that application could not handle such type of extension, it has to reject the certificate.

Required information in a certificate is distinct from critical extension in a certificate. There are some adequate extension fields for an application to process a certificate, and it is not required to flag them as critical, critical information is the information which must be understood by all applications. Majority of the extensions fields are not critical only. The extension value field holds the actual data for the extension. The format of the data is mirrored in the extension type field. Figure 12.6 shows the format of Version 3.

X.509 certificates with the extension mechanism:

12.3 PUBLIC KEY INFRASTRUCTURE

PKI allows efficient and secure identification of public keys. It can be used within or between organizations with the help of Internet. Different types of PKI can be deployed by varying the essential configuration details, trust rules.

12.3.1 PKI Management Model

PKI management model involves in specifying the rules for message formats and procedures used to communicate. The major entities of PKI management are as follows:

1. 1. End Entity (EE): It can be a user or software application to which the certificate is served. It needs secure access at least to its name and private key.
2. Certification Authority (CA): It may be a third party or from the EE’s organization that issues certificate to the EE.
3. Registration Authority (RA): It is a subset of EE and is an optional component. If RA is not present, then CA performs RA’s functions. RA carries out the functions such as key generation, key pair management, token distribution, etc.
4. CRL (Certificate Revocation Lists) issuer: If some certificates have to be revoked, the CRL issuer will take care of it. It is also an optional component.
5. Repository: Storage unit to define how to store certificates and CRLs and how it can be accessed by the EE.

12.3.2 PKI Management Operations

PKI management operations explain how various entities communicate with each other. PKI management operations are depicted in Figure 12.7 and are enumerated below:

1. 1. Registration: EE registers directly or through an RA to CA for receiving certificates.
2. Initialization: EE initializes with its key pair, securely with the CA’s public key for certificate validation.
3. Certification: CA issues the certificate to EE and stores in the repository.
   

   Figure 12.7 PKI management operations

4. Key pair recovery: As the name indicates, if the key pair is to be recovered, it can be accessed from CA or a key backup system.
5. Key pair update: Periodically all key pairs have to be updated.
6. Revocation request: CA revokes a particular certificate when a request is received is from an authorized EE.
7. Cross-certification: It is issued from one CA to another for information exchange.

Key Terms

Authentication

Authentication server

Certificate revocation list

Certification authority

CRL Issuer

Cross-Certification

Issuer X.500 name

Kerberos

Key pair recovery

Key pair update

Public key infrastructure

Registration authority

Repository

Revocation request

Signature algorithm

Subject X.500 name

Ticket

X.509

Summary

User authentication is one of the primary steps to have a secure communication over Internet. Here, this chapter explains about one of the powerful authentic service, Kerberos and its different versions. It deals with how an authentic service developed to serve the need in the MIT lab, transformed to cater the needs across the territory. The next session gives a brief idea of X.509, a user authentication service for constructing public key certificate. X.509 works under asymmetric key cryptography and used by S/MIME and SSL/TLS. Chapter concludes with giving an idea how to have secure identification of public key using PKI, which can be used within or between organizations.

Review Questions

1. With the help of a diagram, explain the operations in Kerberos.
2. List out the advantages of Kerberos Version 5 over Version 4.
3. What do you mean by X.509 authentication services?
4. Explain X.509 formats.
5. Define standard extensions of X.509 and its structure.
6. Write short note on PKI management model.
7. Explain PKI management operations with the help of a diagram.