Chapter 14

From Cryptography and Network Security Fourth Edition written by William Stallings,

and Lecture slides by Lawrie Brown, the Australian Defence Force Academy, University College, UNSW

Authentication ApplicationsDeveloped to support application-level

authentication and digital signaturesMost widely used services:

Kerberos X.509

Kerberos – a private-key authentication service

X.509 – a public-key directory authentication service

Kerberos

KerberosDeveloped as part of Project Athena at MITSymmetric encryption

using no public keysProvides centralised private-key third-party

authentication in a distributed networkVersion 4 and 5

Kerberos MotivationProvide security in a distributed architecture

consisting of dedicated user workstations (clients), and distributed or centralized servers

Require the user to prove his identity for each service invoked

Require that servers prove their identity to clients

Secure, Reliable, Transparent, and Scalable

Kerberos SchemeTrusted third party authentication serviceUses a protocol based on Needham and

Schroeder [NEED78], see Chapter 7Clients and servers trust Kerberos to mediate

their mutual authentication

Kerberos Version 4Uses DES, in a rather elaborate protocol, to

provide authenticationUses an Authentication Server (AS)

Knows all user passwords, and stores in a DBShares a unique secret key with each serverSend an encrypted ticket granting ticketTGT contains a lifetime and timestamp

Kerberos Version 4Uses a Ticket Granting Server (TGS)

Issues tickets to users authenticated by ASEncrypted with a key only known by AS and

TGSReturns a service granting ticket

Service granting ticket contains timestamp and lifetime

Kerberos DialogProblem: lifetime and no server authenticate to

userUses a session keyMessage Exchanges (see table 14.1)

AS exchange to obtain ticket-granting ticketTGS exchange to obtain service granting ticketClient/Server authentication exchange to obtain

service

See table 14.2, Elements of the Kerberos Version 4 Protocol

Kerberos Overview

Kerberos Realmsa Kerberos environment consists of:

a Kerberos servera number of clients, all registered with serverapplication servers, sharing keys with server

A Kerberos RealmSet of managed nodes that share the same

Kerberos database

Multiple KerberiKerberos server in each realm shares a

secret key with one anotherThere must be trust between the serversi.e. each server are registered with one

another

Does not scale well

Kerberos Realms

Kerberos Version 5Fixes version 4 environmental shortcomingsNew elements for AS exchange:

Realm, Options, Times, NonceClient/server authentication exchange

Subkey, sequence number

Kerberos Ticket Flags (see table 14.4)

X.509part of X.500 series

distributed servers maintaining user information database

defines framework for authentication services directory may store public-key certificateswith public key of user signed by certification

authority

also defines authentication protocols

X.509uses public-key cryptology & digital signatures

algorithms not standardised, but RSA recommendedX.509 certificates are widely used

Public key certificate associated with each userGenerated by some trusted CA

Certification Authority (CA) issues certificatesThe notation CA<<A>> represents a certificate for a

client A signed by CA

X.509 Certificatesissued by a Certification Authority (CA),

containing: version 1, 2, or 3 serial number (unique within CA) identifying certificate signature algorithm identifier issuer X.500 name (CA) period of validity (from - to dates) subject X.500 name (name of owner) subject public-key info (algorithm, parameters, key) issuer unique identifier (v2+) subject unique identifier (v2+) extension fields (v3) signature (of hash of all fields in certificate)

X.509 Certificates

Obtaining a User CertificateCertificate notation: CA{…}

Any user with CA’s public key can verify the user public key that was certified

No party other than the CA can modify the certificate without being detected

because cannot be forged, certificates can be placed in a public directory

CA Hierarchyif both users share a common CA then they

are assumed to know its public key otherwise CA's must form a hierarchy use certificates linking members of

hierarchy to validate other CA's each CA has certificates for clients (forward)

and parent (backward) each client trusts parents certificates enable verification of any certificate from

one CA by users of all other CAs in hierarchy

CA Hierarchy

Certificate Revocation certificates have a period of validity may need to revoke before expiry:

1. user's private key is compromised2. user is no longer certified by this CA3. CA's certificate is compromised

CA’s maintain list of revoked certificates the Certificate Revocation List (CRL)

users should check certificates with CA’s CRL

Authentication ProceduresX.509 includes three alternative

authentication procedures: One-Way Authentication Two-Way Authentication Three-Way Authentication all use public-key signatures

See Figure 14.6 for Authentication Procedures

One-Way Authentication1 message ( A->B) used to establish

the identity of A and that message is from A message was intended for B integrity & originality of message

message must include timestamp, nonce, B's identity and is signed by A

may include additional info for Beg session key

Two-Way Authentication2 messages (A->B, B->A) which also

establishes in addition:the identity of B and that reply is from B that reply is intended for A integrity & originality of reply

reply includes original nonce from A, also timestamp and nonce from B

may include additional info for A

Three-Way Authentication3 messages (A->B, B->A, A->B) which

enables above authentication without synchronized clocks

has reply from A back to B containing signed copy of nonce from B

means that timestamps need not be checked or relied upon

X.509 Version 3has been recognised that additional

information is needed in a certificate email/URL, policy details, usage constraints

rather than explicitly naming new fields defined a general extension method

extensions consist of:extension identifiercriticality indicatorextension value

Certificate Extensionskey and policy information

convey info about subject & issuer keys, plus indicators of certificate policy

certificate subject and issuer attributessupport alternative names, in alternative

formats for certificate subject and/or issuercertificate path constraints

allow constraints on use of certificates by other CA’s

Public Key Infrastructure