1

IC3 - Network Security

M.Sc. in Information Security

Royal Holloway, University of London

2

IC3 - Network Security

Lecture 4

Introduction to Secure Protocols

3

CINS/F1-01

Objectives of Lecture

• Define what a secure protocol is.

• Model the principals involved in secure protocols, and their capabilities.

• Demonstrate how basic cryptographic mechanisms can be used to build entity authentication and key distribution protocols suited to insecure networks.

• Appreciate how key distribution and entity authentication can be enabled using trusted third parties.

• Describe the main features of the Kerberos protocol suite and outline its application in Windows 2000.

4

Contents

4.1 Secure protocols

4.2 Entity Authentication and Key Agreement

4.3 Key Distribution via Trusted Third Parties

4.4 Kerberos

5

4.1 Secure Protocols

• A protocol is a set of rules for exchanging messages between 2 (or more) principals over a network.

• The word ‘protocol’ in the OSI model is reserved and refers to rules governing communication between a pair of peer entities.

• We’ll use it here in a more general way.

• In this lecture, we largely leave unspecified the OSI layer at which our protocols operate.– Lectures 5 and 6 will look at protocols for specific

layers.

6

Secure Protocols

So what is a secure protocol?

• When acting honestly, principals (participants) achieve the stated aim of the protocol (e.g. A successfully authenticates to B, or A and B exchange a fresh session key).

• Neither passive eavesdropper nor malicious, active adversary can defeat this objective (e.g. by successfully impersonating A in an authentication protocol with B).

7

The Principals – 1

• Alice and Bob who wish to authenticate one another or to share a key.

• In more complex protocols, Trent, a trusted third party who is trusted by both Alice and Bob– aka (depending on application) TTP, key distribution

centre (KDC), certification authority (CA),….– What Trent is trusted to do (and not do) depends on

the protocol and application.

8

The Principals – 2

Two kinds of adversary:

• Eve, a passive eavesdropper (‘sniffs’ messages at will).• Mallory, an active adversary, who can view, alter,

delete, replay and inject messages into the network, initiate protocol ‘runs’, take on the role of any principal in any protcol ‘run’, ….

Warning 1: ‘Alice’, ‘Bob’, etc are only semantic sugar: most protocols on networks don’t involve real people.

Warning 2: We’ll freely mix up A for Alice and B for Bob, etc.

9

The Principals – 3

Mallory is not all-powerful:• He cannot guess a random number chosen by

another principal from a sufficiently large space.• He cannot invert a one-way hash function.• Without the correct key, he cannot obtain the

plaintext for a given ciphertext. Nor can he compose ciphertexts for plaintexts of his choice.

• He cannot sign messages without having the appropriate private key.

• He cannot correctly compute a MAC on a message without knowing the correct secret key.

• In summary: Mallory cannot break strong cryptographic mechanisms.

10

Summary So Far

• So we equip Alice, Bob, Trent with strong cryptographic mechanisms to use on a completely untrusted network.

• The question then is:

How do we use these cryptographic mechanisms (signatures, public-key and symmetric key encryption, hash functions, MACs) to design secure protocols (providing security services)?

11

• The OSI security architecture (ISO 7498-2) distinguishes between origin authentication (verifying origin of received data) and entity authentication (identity verification).

• An origin authentication service can be built from a MAC.

• Here we consider entity authentication, a basic security service in networks (Lecture 1).

• Typically achieved by exchange of cryptographic messages called an authentication protocol (authentication exchange in ISO 7498-2).

4.2 Entity Authentication

12

• Entity authentication:– the corroboration that an entity is the one claimed at

a particular point in time (no guarantees after that time).

• Unilateral authentication:– entity authentication which provides one entity with

assurance of the other’s identity but not vice versa.

• Mutual authentication:– entity authentication which provides both entities

with assurance of each other’s identity.

Definitions

13

Basis for Authentication

• Suppose we want to design a protocol which authenticates Alice to Bob. Is the following secure?

A B: ‘Hi Bob, I’m Alice’

• No: Mallory can easily impersonate Alice in this protocol.

• So we need something stronger.

• Authentication protocols can be built from the assumption that Alice and Bob share a key, or that Alice and Bob have authentic copies of each others’ public keys.

14

Strong Authentication

• In strong authentication, one entity ‘proves’ its identity to another by demonstrating knowledge of a secret known to be associated with that entity, without revealing that secret itself during the protocol.

• Also called ‘challenge-response’ authentication.

• Use cryptographic mechanisms to protect messages in protocol:– Encryption.– Integrity mechanism (e.g. MAC).– Digital signature.

15

Example: Passwords

• Suppose Alice sends a password matching her user ID over the network, Bob compares to entry in password file.

• Is this a strong authentication protocol?

– Password transmitted in clear over network, so may be sniffable by Mallory – hence weak authentication.

– Not suitable for use over open networks.

– For a degree of added security, transmit only hashed passwords – still vulnerable to dictionary attack (hash an entire dictionary word by word and compare to hashed password).

16

Encryption-based Unilateral Authentication• Assume Alice (client) and Bob (server) share a secret

key K.

• Design goal: Bob to authenticate Alice.

• Alice sends an initiating message.

• Bob sends Alice a challenge message R.

• Alice responds with {R || B}K, message R concatenated with B, encrypted using shared key K.

• Bob checks that the message he received decrypts to give message R || B.

• If it does, then Alice is authenticated to Bob (or Bob authenticates Alice).

17

The Protocol

1. A B: ‘Hi Bob, I’m Alice’

2. B A: R(challenge)

3. A B: {R || B}K

(response)

(Here, {X}K means string X encrypted under key K, and || means concatenation of strings.)

18

Security of the Protocol – 1

1. Why can Bob be sure that message 3 in the protocol came from Alice?

2. Why can Bob be sure that message 3 in the protocol is not a replay of a message from an earlier run of the protocol between himself and Alice?

1. Only Alice (and Bob) know secret key K.

2. Bob chose R at random just before sending message 2. This R is fresh: it has never been used before. This means that message 3, which includes R in encrypted form, has never been produced before.

19

Security of the Protocol – 2

1. Why can Bob be sure that message 3 in the protocol is intended for him?

2. Can an attacker learn the value of secret key K by observing multiple runs of the protocol?

1. Alice includes Bob identity ‘B’ in the encrypted message. This prevents Mallory taking a message intended for Alice and sending it to Bob.

2. No, not if the encryption algorithm is strong.

20

Security of the Protocol – 3

1. Is Alice authenticated to Bob in this protocol?

2. Is Bob authenticated to Alice in this protocol?

3. Is the protocol a mutual authentication or a unilateral authentication protocol?

1. Yes.

2. No. (In fact Mallory could impersonate Bob in the protocol, but our design goal was a protocol in which Alice is authenticated, not Bob, so this is not a problem.)

3. Unilateral: Alice to Bob.

21

A Replay Attack

• Suppose Mallory wants to impersonate Alice in this protocol:

1. M(A) B: ‘Hi Bob, I’m Alice’

2. B M(A): R (challenge)

3. M(A) B: ???

• Now Mallory can’t prepare the correct response {R||B}K to Bob’s challenge because he doesn’t know the secret key K.

• But what if Mallory could predict R? Then we can find a serious replay attack….

22

A Replay Attack

1. A M(B): ‘Hi Bob, I’m Alice’2. M(B) A: R (M predicts which R will be used later by B)

3. A M(B): {R || B}K

1. M(A) B: ‘Hi Bob, I’m Alice’2. B M(A): R (M predicted this R would be used by B)

3. M(A) B: {R || B}K

Mallory keeps hold of {R || B}K: it’s going to come in handy later.

Mallory starts a protocol run, impersonating Bob to Alice:

23

Freshness and Liveness

• The replay attack shows that it is vital that the protocol contains a means of checking freshness of messages and liveness of principals.

• Freshness: assurance that message has not been used previously and originated within an acceptably recent timeframe.

• Liveness: assurance that message sent by a principal within an acceptably recent timeframe.

• Two main methods for providing freshness: – Nonce (Number used once).– Time-stamps (clock-based or `logical’ time-stamps).

24

Nonces

• Nonce also known as random challenge.

• In our protocol, we depend on B to make sure R is freshly generated.

• Main property is ‘one-time’ property, so could in theory use a counter.

• But many protocols need nonces to be unpredictable to Mallory. Generate at random from a large set (128 bits, say).

• Notice that in our protocol, R, the nonce is unpredictable but not secret.

25

Time-stamps – 1

• Inclusion of date/time-stamp in message allows recipient to check it for freshness (as long as time-stamp protected by cryptographic means).

• A B: ‘I’m Alice’, {T || B}K

– a single message instead of three.– Bob decrypts and checks that T is recent and that

his identity is included.– Only Alice knows K, so only Alice could have

prepared this message. It’s fresh, so Alice is live.

• But now we require securely synchronised clocks to prevent replay – non-trivial!

26

Time-stamps – 2

• Typical clock drift is 1s per day on work station.

• So need a window of acceptance for Alice’s messages either side of Bob’s current clock time (clock drift + variable network propagation time).

• Also need a log of recently received messages to prevent Mallory exploiting window with replay attack.

27

‘Logical’ Time-stamps

• Alternative to clocks: Alice and Bob could use pair of sequence numbers NAB and NBA in their communications.

• Every time A sends B a message she includes value NAB, and increments it. Likewise for B.

• Needs pair of sequence numbers for every pair of communicating parties.

• Sequence numbers may need to be kept secret in protocol runs: otherwise they become predictable to Mallory.

28

Using MACs for Entity Authentication

Replace encryption mechanism with a MAC:

1. A B: ‘Hi Bob, I’m Alice’2. B A: R (challenge)

3. A B: MACK(R || B) (response)Can argue security as for encryption-basedprotocol: Only Alice can prepare correct response for Bob, freshness of R guaranteesliveness of Alice.What properties of the MAC did we use?

29

Signature-based Entity Authentication

• Instead of challenge/response, now challenge/signature.

• Use nonces or time-stamps for freshness.

• Rather than a shared secret key, Bob needs to have authenticated version of Alice’s public key (and vice-versa for mutual authentication).

30

Signature-based Mutual Authentication – Example

1. B A: RB

2. A B: RA, SA{RA || RB || B}

3. B A: SB{RB || RA || A}

• Here, SA{X} denotes A’s signature on string X.• Protocol achieves mutual authentication (via

two signatures and two nonces). • A and B must of course check the signatures

to ensure their correctness.

31

• Alice and Bob have to be sure that they are verifying each other’s signatures.

• Hence need for trust in authenticity of public keys instead of shared secrets.

• Public keys can be certified by applying the digital signature of a Trusted Third Party (TTP) or Certificate Authority (CA).

• Result (public key + entity name + expiry date + TTP signature on three items) called a certificate.

Using Digital Signatures

32

• To check a certificate signed by a TTP requires an authentic copy of the TTP’s public key.

• If two entities have certificates signed by different TTPs, then a cross-certificate is needed (i.e. one TTP’s public verification key signed by the other TTP).

• Leads to notion of certification paths and public-key infrastructures (PKIs).

• Related protocols are used in SSL and IPSec (see Lectures 5 and 6).

Using Certificates

33

• Entity authentication only achieved for an instant in time, typically provided at start of a connection/session.

• Mallory could always hijack the connection after that point.

• What if a secure session is needed?– A combination of confidentiality, integrity, data origin

authenticity for remainder of communications session.

• Solution: agree session keys as part of the authentication protocol.

• Then use those session keys in encryption and MAC mechanisms to build a secure session.

• Bind the session keys to the entity auth. protocol run to get authenticated key establishment (AKE) protocol.

Authenticated Key Establishment – 1

34

Authenticated Key Establishment – 2

• As a simple example, we can adapt our one message time-stamp based protocol:

A B: {T || B}K

simply by adding a session key SK in Alice’s message:

A B: {T || B || SK}K

• Alice is authenticated to Bob and they now share session key SK.

• Because SK is agreed as part of the entity auth. protocol, it is bound to that protocol run.

• So Bob can be sure that only Alice knows SK.

• Alice can be sure that only Bob could know SK: only Bob could decrypt the message to extract SK.

35

Authenticated Key Establishment – 3

Public-key encryption can also be used to create authenticated session keys:• Alice checks the authenticity of Bob’s public

encryption key PKB using a certificate.

• A B: {SK}PKB

• Bob can obtain the session key SK by decrypting using his private key.

• Alice and Bob both use SK to derive encryption and MAC keys to protect their session.

• Alice can be sure that only Bob could know the session key.

36

Authenticated Key Establishment – 4

• In this protocol, Alice is not authenticated (anyone can encrypt for Bob).

• B is only implicitly authenticated to A: A is only assured he’s talking to B if messages in the subsequent session make sense (i.e. MAC and decrypt work properly with SK).

• A (much) more complicated version of this protocol is an option in SSL (see Lecture 6).

37

ISO/IEC 9798

• ISO/IEC 9798, a multi-part standard (currently five parts published), specifies a variety of standard authentication protocols (and derived key establishment protocols).

• Designed to be ‘generic’, i.e. suitable for most applications.

• ISO/IEC 9798 protocols are robust: designed by experts who learned from mistakes of earlier designers.

38

• A session key can be established as a by-product of an authentication protocol.

• Here we start from the other end, and look at key agreement protocols, then we consider how to add authentication.

• The main protocol we study is the Diffie-Hellman Key Exchange (DHKE) protocol.

• Scenario:– Alice and Bob don’t already share a key and can’t meet to

do so. How can they make their future communications confidential?

More on Key Agreement

39

Diffie-Hellman Key Exchange Set-up

• Alice and Bob agree on a large prime p (p has, say, 1024 bits) and a number g.

• Alice chooses a random x and computes

gx mod p.

• Bob chooses a random y and computes

gy mod p.

40

Diffie-Hellman Key Exchange

1. A B: gx mod p

2. B A: gy mod p

3. A computes (gy)x mod p

4. B computes (gx)y mod p

But (gx)y = gxy = (gy)x mod p.

So A and B now share a common key gxy !

41

Diffie-Hellman and Eve

• Eve sees only the public values, gx mod p and

gy mod p.

• But to get the key, Eve needs to compute

gxy mod p.

• If p and g are chosen properly, then this is a hard computational problem.

• Then Diffie-Hellman key exchange protocol will be secure against Eve, a passive adversary.

42

Diffie-Hellman and Mallory

Alice Mallory Bob

ga

gb

A,M

K1= (gb)x = (gx)b

M,BK2= (ga)y = (gy)a

gx

gyx a,b y

43

The Man-in-the-middle Attack

• Alice thinks she has exchanged key K1 with Bob.– Instead, it’s with Mallory.

• Bob thinks he has exchanged key K2 with Alice. – Instead, it’s with Mallory.

• Mallory can now – intercept all messages from A intended for to B, – decrypt them using K1, – read them, – re-encrypt them under K2 and – pass them on to B.

• And vice-versa for messages from B to A.

44

What went wrong?

• Simply this: Alice and Bob exchanged a key without any performing any entity authentication.

• So keys were exchanged, but Alice and Bob have no guarantees about with whom their exchange took place!

• So Diffie-Hellman key exchange protocol is not secure against Mallory, an active adversary.

45

Station-to-Station Protocol

The station-to-station protocol addsauthentication (via signatures) to DHKE:1. A B: gx

2. B A: gy, {SB{gy , gx}}K

3. A B: {SA{gx, gy}}K

• After step 1, B can compute the shared key K. • After step 2, so can A. • The additional messages are encrypted signatures on

everything fresh in the protocol run; these are intended to provide authentication and key confirmation.

• These signatures should be checked by A and B.

46

4.3 Key Distribution via TTPs

• Scenario: closed system (security domain) with n users, potentially n(n-1)/2 keys to allow all pairs to communicate securely with each other.

• Could use public-key techniques with trust in keys based on certificates (see SSL example).

• Alternatively, use a trusted third party called a Key Distribution Centre (KDC) who co-operates to enable users to authenticate one another and share session keys.

47

Keys and Trust

• Alice shares a long-term key KA,T with KDC, Trent.

• Bob also shares a long-term key KB,T with KDC.• But Alice and Bob do not share a key.• Alice and Bob use KDC Trent to help them

authenticate one another and agree a session key K.

• We have a security domain (or realm) formed by Trent and all the clients:

‘a system under the control of a single authority which the entities therein trust’

48

Application Scenarios

• A corporate network, with KDC being a server managed by IT department (say).

• Campus network: authentication controls access to different services (e-mail, printing, student records) located on the network– Now TTP is acting as an authorization server,

granting access to services, rather than as a pure key distribution centre.

49

Alice Bob

Trent(KDC)

1 2

3

4

5

1. A T: A || B || NA

2. T A: {NA || B || K || {K || A}KB,T}KA,T

3. A B: {K || A}KB,T

4. B A: {NB}K

5. A B: {NB-1}K

Needham-Schroeder Protocol

50

Needham-Schroeder – Step by Step

• In messages 1 and 2, Alice and Trent (the TTP) interact: Trent gives Alice a session key K and authenticates himself.

• In messages 3,4 and 5, the interaction is between Alice and Bob. Alice transfers an encrypted copy of the session key to Bob in message 3 and is authenticated to Bob in messages 4 and 5.

51

Security?

• T is authenticated by A and A is implicitly authenticated by T (recipient can only decrypt message 2 if he has the correct key KA,T).

• A is authenticated to B (challenge/response).• If key K is used for subsequent encryption or

MACing, then we get implicit authentication of B to A (recipient of message 3 can only obtain K if he knows correct key KB,T).

• Can make A,B authentication mutual by having A issue a challenge to B along with message 3.

• Session key established: chosen by T, the KDC.

52

Advantages

• Key storage efficiency: only n keys to look after at KDC.

• Only one long-term key per client (KA,T) instead of n-1.

• Only uses symmetric key cryptography.

• Bob can be off-line in steps 1&2 because TTP doesn’t forward session key K directly to Bob: Alice relays it to Bob (step 3).

• So K can be cached by Alice and used later.

53

Disadvantages

• KDC is a single point of failure – security and availability.

• Potential computation/communication bottleneck at KDC.

• How can we ensure clients look after their long-term keys properly?– If long-term key compromised, then entities can be

impersonated.

• Requirement for an on-line, trusted server.– TTP knows all session keys and all long-term keys.

54

• Kerberos is a TTP-aided authentication protocol developed from Needham-Schroeder.

• It’s also software implementing that protocol, currently Kerberos V5 Release 1.3.– Version 4 (still?) widely used, no longer under

development.

• Also a project at MIT which devised the protocols (properly called Project Athena).

• Also RFC 1510 – Kerberos V5 (1992).• A version of Kerberos exists in Windows 2000;

Kerberos is integrated into many versions of Unix.

4.4 Kerberos

55

Kerberos Principals

• Authentication Server (AS) – mutual authentication with client at login based on long-term key, gives client ticket granting ticket and short-term key.– AS provides an authentication service.

• Ticket Granting Server (TGS) – mutual authentication with client based on short-term key and ticket granting ticket. TGS then issues tickets giving clients access to further servers.– TGS provides an access control service.

56

• Separation of authentication and authorisation/access control (though AS and TGS usually implemented on same platform).

• Differentiated control over lifetime of ticket granting tickets (typically 10 hours) and session tickets for actual access to services (typically 5 minutes).

• A user only needs to use his long-term secret key once per 10 hour session, to establish short-term key and ticket granting ticket.

• Once the short-term key is established (with TGS) the long-term secret key can be erased from the client host.– Minimises risk of exposure of long-term secret key.

Kerberos – Motivations

57

C(client)

S(server)

AS(authentication

server)

TGS(ticket-

grantingserver)

1 2 3 4

5

6

Kerberos Protocol

58

Phase 1: In messages 1 and 2, C and AS authenticate and set up short-term key and ticket granting ticket.

Phase 2: In messages 3 and 4, C and TGS authenticate and set up session keys and (session) ticket.

Phase 3: In messaged 5 and 6, C and S use session key and ticket to authenticate and set up secure session.

Phases 2 and 3 will usually be repeated manytimes for each execution of Phase 1.

Kerberos Phases

59

1. CAS: TGS||from||to||NC

2. ASC: {KC,TGS||C||from||to}KAS,TGS|| {KC,TGS||NC||from||to||TGS}KAS,C

(Note that the first part of message 2 is the Ticket Granting Ticket for the TGS).

3. CTGS: S||from||to||N’C || {KC,TGS||C||from||to}KAS,TGS || {C||T1}KC,TGS

4. TGSC: {KC,S||C||from||to}KTGS,S || {KC,S|| N’C||from||to||S}KC,TGS

(Note that the first part in message 4 is the Ticket for the server S).

5. CS: {KC,S||C||from||to}KTGS,S || {C||T2}KC,S

6. SC : {T2}KC,S

Kerberos – Message Formats (Simplified)

60

Keys Used in Kerberos

• KAS,TGS is a long-term secret key shared by AS and TGS.

• KAS,C is a long-term secret key shared by AS and C.

• KTGS,S is a long-term secret key shared by TGS and S.

– These keys need to be established in advance.

• KC,TGS is a secret short-term key shared by C and TGS (established by messages 1 and 2).

• KC,S is a secret session key shared by C and S (established by messages 3 and 4).

61

Entity Authentication in Kerberos

• Entity authentications are achieved using a mixture of nonces and timestamps.

• Methods are similar to ones used in Section 4.2 and in Needham-Schroeder protocol.

• For example: AS is authenticated to C using challenge/response protocol based on encryption, shared key KAS,C and nonce NC in messages 1 and 2.

• Other authentications: C and TGS; C and S.

62

Tickets in Kerberos

• {KC,TGS||C||from||to}KAS,TGS

– Is the ticket granting ticket.

– Received by C in message 2 and sent to TGS in message 3.

– only TGS can decrypt it to obtain short-term key KC,TGS and validity period from||to. These parameters determine ticket given to C in message 4.

• {KC,S||C||from||to}KTGS,S

– Is the (session) ticket.

– Received by C in message 4 and sent to S in message 5.

– Only S can decrypt it to obtain session key KC,S and validity period from||to. These parameters determine access given to C in subsequent session with server S.

• These tickets are the equivalent of message 3 in Needham-Schroeder: {K || A}KB,T

63

Use of Cryptography in Kerberos

• Kerberos uses symmetric encryption and MACs.

• Specifically, Version 5 (as in RFC 1510) uses DES combined with one of MD4, MD5, or a CRC (not recommended).

• Releases 1.2 and higher of Kerberos Version 5 allow triple DES (3DES) in CBC-mode.

• Extensions supporting AES and other algorithms are under development – AES implemented but not fully enabled in Kerberos

v5 release 1.3.

64

Kerberos Issues – 1

• Revocation: ticket granting tickets valid until they expire, typically 10 hours. What if compromised?

• Key management: within realms (domains): long-term keys need to be established between AS and TGS, TGS and Servers and AS and clients.

• Scalability: authentication across realms is complicated.

• Synchronous clocks needed, protected against attacks. Caches of recent messages to protect against replay within clock skew.

65

Kerberos Issues – 2

• Availability: need for on-line AS and TGS, trusted by clients not to eavesdrop.

• Passwords: Client-AS long-term key usually based on password entered by user at start of session – vulnerable to dictionary attacks.

• Key storage: Short-term keys and ticket granting tickets located on largely unprotected client hosts.

• Denial of Service: Potential for DoS attacks on clock service or on AS/TGS?

66

Windows 2000 Network Authentication

• Microsoft have adopted and extended Kerberos for network authentication in Windows 2000.

• Supersedes Windows NTLM (unilateral authentication) in NT4.

• One extension: – support for public-key encryption to protect client/AS

messages (rather than password-based long-term key).

– allows use of authentication based on client smart cards.

67

Windows 2000 Network Authentication

• Second extension: – use of Kerberos data authorization field (normally

empty) – transports Win2K access privileges – in the form of SIDs, derived from Active Directory– these are compared to ACLs of remote objects to

make access decisions.

• Message formats published, but proprietary to Microsoft.

• Non-standard extension to Kerberos makes it difficult to interoperate Microsoft and non-Microsoft implementations.

68

Lessons Learned?

• Designing protocols is easy.• But designing secure protocols is hard

– there are many infamous failures in the literature.

• Some good protocols are already standardised (e.g. ISO 9798, ITU-T X.509, …) – use these rather than rolling your own!

• The problem of verifying security gets harder as the protocols get more complex.

• Security weaknesses arise from errors in specification, implementation, side-channels, lack of user training, host insecurities, poor random number generation…