Chapter 14. Authentication Applications NUIST School of Computer and Software Jian Shen, PhD, Professor

preface & introduction Kerberos – network authentication protocol X.509 directory authentication service – public-key certifications PKI and PKIX model – make use of X.509 certifications

14.1. Kerberos Kerberos is an authentication service (network authentication protocol) The problem that Kerberos addresses is this: Servers restrict access to authorized users And to be able to authenticate requests for service.

14.1. Kerberos Characteristic Version Kerberos provides a centralized authentication server whose function is to authenticate users to servers and servers to users. Kerberos relies exclusively on symmetric encryption, Kerberos makes no use of public-key encryption. Version Kerberos Version 4 Kerberos Version 5

14.1. Kerberos Motivation No network connections – physically security The operating system can enforce access control policies based on user identity and use the logon procedure to identify users. Today, more common is a distributed architecture consisting of dedicated user workstations (clients) and distributed or centralized servers.

14.1. Kerberos Kerberos Version 4 A Simple Authentication Dialogue The full protocol – hypothetical dialogue. A Simple Authentication Dialogue Impersonation. An opponent can pretend to be another client and obtain unauthorized privileges on server machines. Heavy burden in server An alternative is to use an authentication server (AS) that knows the passwords of all users and stores these in a centralized database. In addition, the AS shares a unique secret key with each server.

14.1. Kerberos Consider the hypothetical dialogue: (1) C →AS: IDC||PC||IDV (2) AS → C: Ticket (3) C → V: IDC||Ticket Ticket = E(Kv, [IDC||ADC||IDV])

14.1. Kerberos A More Secure Authentication Dialogue Two problems are still existing. First, we would like to minimize the number of times that a user has to enter a password. However, under this scheme it remains the case that a user would need a new ticket for every different service. The second problem is that the earlier scenario involved a plaintext transmission of the password. An eavesdropper could capture the password and use any service accessible to the victim. To solve these additional problems, we introduce a scheme for avoiding plaintext passwords and a new server, known as the ticket-granting server (TGS).

14.1. Kerberos The new scenario is as follows: Once per user logon session: (1) C → AS: IDC||IDtgs (2) AS → C: E(Kc, Tickettgs) Once per type of service: (3) C → TGS: IDC||IDV||Tickettgs (4) TGS → C: Ticketv Once per service session: (5) C → V: IDC||Ticketv Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1]) Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])

14.1. Kerberos TGS issues tickets to users who have been authenticated to AS. Thus, the user first requests a ticket-granting ticket (Tickettgs) from the AS and save it. Because only the correct user should know the password, only the correct user can recover the ticket. This new scenario satisfies the two requirements of only one password query per user session and protection of the user password.

14.1. Kerberos The Version 4 Authentication Dialogue Although the foregoing scenario enhances security compared to the first attempt, two additional problems remain. The heart of the first problem is the lifetime associated with the ticket-granting ticket. The second problem is that there may be a requirement for servers to authenticate themselves to users. The false server would then be in a position to act as a real server and capture any information from the user and deny the true service to the user. The actual Kerberos protocol shows in Table 14.1.

14.1. Kerberos

14.1. Kerberos AS gives both C and TGS a session key in Kerberos. Note that several additional pieces of information have been added to this first phase of the dialogue. Message (1) includes a timestamp, so that the AS knows that the message is timely. Message (2) includes several elements of the ticket in a form accessible to C. This enables C to confirm that this ticket is for the TGS and to learn its expiration time. Unlike the ticket, which is reusable, the authenticator is intended for use only once and has a very short lifetime. The TGS can decrypt the ticket with the key that it shares with the AS. This ticket indicates that user C has been provided with the session key Kc,tgs. It is the authenticator that proves the client's identity. Because the authenticator can be used only once and has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator for presentation later is countered.

14.1. Kerberos TGS gives both C and V a session key in Kerberos. C now has a reusable service-granting ticket for V. When C presents this ticket, as shown in message (5), it also sends an authenticator. The server can decrypt the ticket, recover the session key, and decrypt the authenticator. If mutual authentication is required, the server can reply as shown in message (6). The server returns the value of the timestamp from the authenticator, incremented by 1, and encrypted in the session key. Finally, at the conclusion of this process, the client and server share a secret key. This key can be used to encrypt future messages between the two or to exchange a new random session key for that purpose. Figure 14.1 provides a simplified overview of the action.

14.1. Kerberos

14.1. Kerberos Kerberos Realms and Multiple Kerberi Kerberos environment consisting of a Kerberos server, a number of clients, and a number of application servers Kerberos realm. Networks of clients and servers under different administrative organizations typically constitute different realms.

14.1. Kerberos Request for Service in Another Realm

14.1. Kerberos One problem presented by the foregoing approach It does not scale well to many realms. If there are N realms, then there must be N(N-1)/2 secure key exchanges so that each Kerberos realm can interoperate with all other Kerberos realms.

14.1. Kerberos Kerberos Version 5 Differences between Versions 4 and 5 Environmental shortcomings Encryption system dependence Internet protocol dependence Message byte ordering Ticket lifetime Authentication forwarding Interrealm authentication Technical deficiencies Double encryption PCBC encryption Session keys Password attacks

14.1. Kerberos The Version 5 Authentication Dialogue

14.1. Kerberos Authentication service exchange Realm: Indicates realm of user Options: Used to request that certain flags be set in the returned ticket Times: Used by the client to request the following time settings in the ticket: Nonce: A random value to be repeated in message (2) to assure that the response is fresh and has not been replayed by an opponent (mistake?)

14.1. Kerberos Ticket Flags

14.2. X.509 Authentication Service Directory service. A server or distributed set of servers (maintains info. about users) The directory may serve as a repository of public-key certificates certificate contains the public key of a user and is signed with the private key of a trusted certification authority. In addition, X.509 defines alternative authentication protocols based on the use of public-key certificates. X.509 is an important standard because the certificate structure and authentication protocols defined in X.509 are used in a variety of contexts. X.509 has three kinds of version. X.509 is based on the use of public-key cryptography and digital signatures.

14.2. X.509 Authentication Service Figure 14.3 illustrates the generation of a public-key certificate.

14.2. X.509 Authentication Service Certificates Figure 14.4a shows the general format of a certificate

14.2. X.509 Authentication Service The standard uses the following notation to define a certificate: CA<<A>> = CA {V, SN, AI, CA, TA, A, Ap} Where Y <<X>> = the certificate of user X issued by certification authority Y Y {I} = the signing of I by Y. It consists of I with an encrypted hash code appended The CA signs the certificate with its private key. If the corresponding public key is known to a user, then that user can verify that a certificate signed by the CA is valid.

14.2. X.509 Authentication Service Obtaining a User's Certificate User certificates generated by a CA have the following characteristics: 1. The user John who get the public key of the CA can verify the user Mary’s public key that was certified. 2. No party other than the CA can modify the certificate without this being detected. E.g. CA X1 <<A>> and CA X2 <<B>> A does not securely know the public key of X2 B's certificate is useless to A. A can read B's certificate, but A cannot verify the signature. If the two CAs have securely exchanged their own public keys 1. A obtains, from the directory, the certificate of X2 signed by X1. 2. A then goes back to the directory and obtains the certificate of B signed by X2 A can verify the signature and securely obtain B's public key.

14.2. X.509 Authentication Service Chain of certificates A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is expressed as X1<<X2>> X2 <<B>> In the same fashion, B can obtain A's public key with the reverse chain: X2<<X1>> X1 <<A>> An arbitrarily long path of CAs can be followed to produce a chain. A chain with N elements would be expressed as X1<<X2>> X2 <<X3>>... XN<<B>>

14.2. X.509 Authentication Service X.509 suggests that CAs be arranged in a hierarchy. Forward certificates Reverse certificates In this example, user A can acquire the following certificates from the directory to establish a certification path to B: X<<W>> W <<V>> V <<Y>> Y<<Z>> Z <<B>>

14.2. X.509 Authentication Service Revocation of Certificates Revocation reasons: The user's private key is assumed to be compromised. The user is no longer certified by this CA. The CA's certificate is assumed to be compromised. Each CA must maintain a list consisting of all revoked but not expired certificates issued by that CA, including both those issued to users and to other CAs. These lists should also be posted on the directory. Certificate revocation list (CRL)

14.2. X.509 Authentication Service Procedures

14.2. X.509 Authentication Service One-Way Authentication The identity of A and that the message was generated by A That the message was intended for B The integrity and originality of the message The nonce can be used to detect replay attacks Two-Way Authentication The identity of B and that the reply message was generated by B That the message was intended for A The integrity and originality of the reply Three-Way Authentication signed copy of the nonce rB

14.2. X.509 Authentication Service X.509 Version 3 Key and Policy Information Certificate Subject and Issuer Attributes Certification Path Constraints

14.3. Public-Key Infrastructure Public-key infrastructure (PKI) as the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography Public Key Infrastructure X.509 (PKIX) working group has been the driving force behind setting up a formal (and generic) model based on X.509 that is suitable for deploying a certificate-based architecture on the Internet Interrelationship among the key elements of the PKIX model End entity, Certification authority (CA), Registration authority (RA), CRL issuer, Repository PKIX Management Functions PKIX Management Protocols (CMP, CMC)

14.3. Public-Key Infrastructure

The end Thank you !!