Module 4

Network & Application Security: Kerberos – X509 Authentication service – IP security Architecture –

Secure socket layer – Electronic mail security – Pretty Good privacy – S/MIME – secure Electronic Transactions – Firewalls - Security mechanisms in JAVA platform – Applet security – Security policy

and Security Manager.

Authentication Applications

• will consider authentication functions• developed to support application-level

authentication & digital signatures• will consider Kerberos – a private-key

authentication service• then X.509 directory authentication service

2

Kerberos• trusted key server system from MIT • provides centralised private-key third-party

authentication in a distributed network– allows users access to services distributed through

out the network– without needing to trust all workstations– rather all trust a central authentication server

• two versions in use: 4 & 5

3

Kerberos Requirements

• first published report identified its requirements as:– security– reliability– transparency– scalability

4

Kerberos 4 Overview• a basic third-party authentication scheme• have an Authentication Server (AS)

– users initially negotiate with AS to identify themselves

– AS provides a non-corruptible authentication credential (ticket granting ticket TGT)

• have a Ticket Granting server (TGS)– users subsequently request access to other services

from TGS on basis of users TGT

5

A Simple Authentication Dialogue

• (1) C -> AS : IDC || PC || IDV

– C = client – AS = authentication server– IDC = identifier of user on C– PC = password of user on C– IDV = identifier of server V– C asks user for the password– AS checks that user supplied the right password

6

Message 2

• (2) AS -> C : Ticket• Ticket = E K(V) [IDC || ADC || IDV]

– K(V) = secret encryption key shared by AS and V – ADC = network address of C

– Ticket cannot be altered by C or an adversary

7

Message 3

• (3) C -> V: IDC || Ticket– Server V decrypts the ticket and checks various

fields– ADC in the ticket binds the ticket to the network

address of C– However this authentication scheme has

problems

8

Problems

• Each time a user needs to access a different service he/she needs to enter their password– Read email several times– Print, mail, or file server– Assume that each ticket can be used only once

(otherwise open to replay attacks)

• Password sent in the clear

9

Authentication Dialogue II• Once per user logon session• (1) C -> AS: IDC || IDTGS

• (2) AS -> C: E (K(C), [TicketTGS])

• TicketTGS is equal to– E( K(TGS) [IDC || ADC || IDTGS || TS1 || Lifetime1 ])

• TGS = Ticket-granting server• IDTGS = Identifier of the TGS

• TicketTGS = Ticket-granting ticket or TGT

• K (C) = key derived from user’s password

• TS1 = timestamp

• Lifetime1 = lifetime for the TGT

10

Messages (3) and (4)• Once per type of service• (3) C -> TGS: IDC || IDV || TicketTGS

• (4) TGS -> C : TicketV

• TicketV is equal to– E K(V) [ IDC || ADC || IDV || TS2 || Lifetime2 ]

K(V): key shared between V and TGSIs called the service-granting ticket (SGT)

11

Message 5

• Once per service session• (5) C -> V: IDC || TicketV

• C says to V “I am IDC and have a ticket from the TGS” . Let me in!

• Seems secure, but..– There are problems

12

Problems• Lifetime of the TGT

– Short : user is repeatedly asked for their password– Long : open to replay attack– Oscar captures TGT and waits for the user to logoff– Sends message (3) with network address IDC

(network address is easy to forge)

• Same problem with SGT

13

What should we do?• A network service (TGS or server) should be able to

verify that – person using the ticket is the same as the person that the

ticket was issued to– Remedy : use an authenticator

• Server should also authenticate to user– Otherwise can setup a “fake” server– A “fake” tuition payment server and capture the student’s

credit card– Remedy : use a challenge-response protocol

14

Kerberos 4 Overview

Kerberos Realms• a Kerberos environment consists of:

– a Kerberos server– a number of clients, all registered with server– application servers, sharing keys with server

• this is termed a realm– typically a single administrative domain

• if have multiple realms, their Kerberos servers must share keys and trust

16

Kerberos Realms: Request for service in Another Realm

Kerberos Version 5• developed in mid 1990’s• provides improvements over v4

– addresses environmental shortcomings• encryption algorithm, network protocol, byte order,

ticket lifetime, authentication forwarding, inter-realm authentication

– and technical deficiencies• double encryption, non-standard mode of use, session

keys, password attacks

• specified as Internet standard RFC 1510

18

Kerberos v5 Dialogue

Kerberos v5 Dialogueauthentication service exchange. •Message (1) is a client request for a ticket-granting ticket. •Message (2) returns a ticket-granting ticket, identifying information for the client, and a block encrypted using the encryption key based on the user's password. This block includes the session key to be used between the client and the TGS.

Kerberos v5 Dialogueticket-granting service •message (3) for includes an authenticator, a ticket, and the name of the requested service.•includes requested times and options for the ticket and a nonce•Message (4) has the same structure as message (2), returning a ticket plus information needed by the client, the latter encrypted with the session key now shared by the client and the TGS.

Kerberos v5 Dialogueclient/server authentication exchange,• several new features appear in version 5, such as a request for mutual authentication. •If required, the server responds with message (6) that includes the timestamp from the authenticator. •The flags field included in tickets in version 5 supports expanded functionality compared to that available in version 4

X.509 Authentication Service • X.509 is the Internationally accepted standard

– to construct a public key certificate, – is becoming widely used.

• part of CCITT X.500 directory service standards– distributed servers maintaining some info database

• defines framework for authentication services – directory may store public-key certificates– with public key of user– signed by certification authority

• also defines authentication protocols • uses public-key cryptography & digital signatures

– algorithms not standardised, but RSA recommended It is used by S/MIME secure email, SSL/TLS secure Internet links (eg for secure

web).

Public-Key Certificate Use

X.509 Certificates

X.509 Certificates• issued 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)

• notation CA<<A>> denotes certificate for A signed by CA

26

Obtaining a Certificate

• any user with access to CA can get any certificate from it

• only the CA can modify a certificate • because cannot be forged, certificates can be

placed in a public directory

27

CA Hierarchy • if 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

28

CA Hierarchy Use

29

Track chains of certificates:A acquires B certificate using chain: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>> B acquires A certificate using chain: Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

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 but not expired certificates issued by CA

– the Certificate Revocation List (CRL)

• users should check the directory each time a certificate is received, with CA’s CRL

– To avoid delay user would maintain a local cache of certificates and list of revoked certificates. 30

Authentication Procedures

• X.509 includes three alternative authentication procedures: – One-Way Authentication

• for unidirectional messages (like email)

– Two-Way Authentication • for interactive sessions when timestamps are used

– Three-Way Authentication • for interactive sessions with no need for timestamps

• all use public-key signatures

31

One-Way Authentication

• A single transfer of information from 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

32

Nonce

• a nonce is a parameter that varies with time. – A nonce can be a time stamp, – a visit counter on a Web page, – or a special marker intended to limit or prevent

the unauthorized replay or reproduction of a file.

Two-Way Authentication

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

Three-Way Authentication

• 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks

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

• means that timestamps need not be checked or relied upon

tA –time stamp rA – nonce

X.509 Version 3• has 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 identifier– criticality indicator– extension value

37

Certificate Extensions• key and policy information

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

• certificate subject and issuer attributes– support alternative names, in alternative formats

for certificate subject and/or issuer• certificate path constraints

– allow constraints on use of certificates by other CA’s

38