Z08 Lecture 1_2

8/13/2019 Z08 Lecture 1_2

1/14

Page 1

MSc in Data Communications Networks and Distributed Systems, UCL

DCNDS

Z08

Distributed Systems Security

Authentication Principles - 1

Prof. Steve Wilbur

[email protected]


DCNDS

Z08

1 - 2

Lecture Objectives

u Define authentication

u Identify types of protocols needed

u Identify threats

u

Examine classic protocols based on SKC andidentify weaknesses

8/13/2019 Z08 Lecture 1_2

2/14

Page 2


DCNDS

Z08

1 - 3

Authentication

u Assurance that messages are from claimedoriginator

u Generally implies that original message has notbeen tampered with - message integrity

u Does not necessarily imply secrecy

u Mutual authentication: Two parties satisfythemselves of each others identity usually for longterm (session or transaction) interaction

u One-way Authentication: One party isauthenticated, eg. your login to Unix


DCNDS

Z08

1 - 4

Cryptography

u Use cryptography to achieve these functions

u Need keys to be distributed

u Key distribution different for PKC and SKC

u Need Key Distribution Protocols

u Need PKC and SKC protocols

u Also, need message oriented (single-ended)protocols and stream oriented (two-way)protocols

8/13/2019 Z08 Lecture 1_2

3/14

Page 3


DCNDS

Z08

1 - 5

Basic Protocol Map

u We will use the following map to keep ourbearings as we explore the various protocols

Public Key

(PKC)

Shared Key

(SKC)

Two-way PKC

One-way PKC

Public KeyDistribution

Two-way SKC

One-way SKC

Shared KeyDistribution

Two-way

Authentication

One-way

Authentication

Key

Distribution


DCNDS

Z08

1 - 6

Notation

A, B

U, V

E

S

Kx

Ks

{Data}K

Principals - good guys eg. Alice, Bob

Domains - organisations eg. UCL, IBM

Eavesdropper - bad guys, eg. Eve

Security server/service

Personal key of x

Session key

Data encrypted with key K

8/13/2019 Z08 Lecture 1_2

4/14

Page 4


DCNDS

Z08

1 - 7

SKC Key Distribution

u For A, B to communicate securely they need toshare a key

u This could be achieved by:1. Providing pair-wise keys for all possible communications

to all relevant parties

2. Shared key selected by A and physically transmitted to B

3. Third party selects key and physically delivers it to Aand B

4. If A and B already have secure communication, one partycan select a new key and transmit using old key

5. If A and B have secure communication to third party S. Scan provide shared key via these secure connections


DCNDS

Z08

1 - 8

SKC Key Distribution - 2

u For a population of N users, approach 1 requiresN(N-1)/2 keys

u May be just about feasible for small populations,but e.g. N=1,000 needs about 500,000 keys andN=10,000 needs about 50M keys

u Also, keys used for long periods become morevulnerable to cryptanalysis, so would need tochange them periodically/frequently

u Physical delivery is generally inappropriate forroutine key distribution in distributed systems, 2 and 3 are not suitable

8/13/2019 Z08 Lecture 1_2

5/14

Page 5


DCNDS

Z08

1 - 9

SKC Key Distribution - 3

u Approach 4 can be used, but needs an existingsecure session

u Approach 5 is attractive. It requires that S sharesa key with each member of population

u Thus, need to distribute N-1 keys, not N(N-1)/2

u Hierarchy of keys:o Session keys

o End user/application personal keys shared with first

level KDCo Repeated for higher level KDCs


DCNDS

Z08

1 -10

Two-way SKC Authentication

u Assume A, B already have their own personal keys,Ka and Kb (do not know each others key)

u Each key is shared with trusted third party, S, suchthat S knows private keys of both A and B

u S known asAuthentication Server (AS) or KeyDistribution Centre (KDC)

u Protocol needed to distribute session key securelyand mutually authenticate A and B

u Note: A and B both trust S, since S holds theirpersonal keys

8/13/2019 Z08 Lecture 1_2

6/14

Page 6


DCNDS

Z08

1 -11

Two-Way Authentication

Protocol is broadly of form below

Ka, Kb are Personal Keys

Ks is the Session KeyAuthentication

Server - S

Server - BClient - A

1

2

3

4

5

Ka Kb

KbKa

Ks Ks


DCNDS

Z08

1 -12

Needham & SchroederSKC Protocol

u A, B are parties involved

u S is Authentication Server

u Ka, Kb are personal keys of A,B known only to owner and S

u I is nonce used once only

u Ks is conversation key orsession key generated by S

u , indicates messagecomposition or concatenation

Authentication with SKC

1. A->S: A, B, Ia1

2. S->A: {Ia1, B, Ks, {Ks, A}Kb }Ka

3. A->B: {Ks, A}Kb

4. B->A: {Ib}Ks

5. A->B: {f(Ib)}Ks

6. AB: {Data}Ks

S

BA

8/13/2019 Z08 Lecture 1_2

7/14

Page 7


DCNDS

Z08

1 -13

Needham & SchroederSKC Protocol - 2

u Steps 1 to 3 are used to distribute session key to Aand B

u Step 3 also indicates to B that S has onlydistributed this key to A (and B)

u Steps 3 to 5 deal with mutual authenticationand live-ness indicating to both parties thatmessage 3 was not a replay

u Can extend it to deal with multiple domains (see

over)u KDCs use similar protocol with a super-KDC they

all trust


DCNDS

Z08

1 -14

Needham & SchroederMultiple Domains

u As before, plus:

u Su, Sv are AuthenticationServers

u Ka, Kb are secret keys ofA, B known only to owner

& Su, Sv resp.u Ksas is conversation key

between authenticationservers

Authentication with Secret Keys

1. A->Su: A, B, Ia1

1a. Su->Sv: {Ks, B, A, Ia1}Ksas

1b. Sv->Su: {{Ks, A}Kb, Ia1, A}Ksas

2. Su->A: {Ia1, B, Ks, {Ks, A}Kb }Ka

3. A->B: {Ks, A}Kb

4. B->A: {Ib}Ks

5. A->B: {f(Ib)}Ks

Su Sv

BA

8/13/2019 Z08 Lecture 1_2

8/14

Page 8


DCNDS

Z08

1 -15

Needham & SchroederProtocol Issues

u What is purpose of nonce?

u What forms of attack are possible?o Simple replay

o Backward replay

o Nonce attacks


DCNDS

Z08

1 -16

Needham & SchroederWeakness

u Simple replay of msg 3 to B by E may causeconfusion at A if session has closed, but otherwiseis relatively harmless

u However, if an old session key has beencompromised and E can suppress selectedmessages to A, then replay of msg 3 will cause Bto have session with E thinking it is A

u Denning suggested use of timestamps to

overcome thisu Because nonces give no indication of freshness of

message

8/13/2019 Z08 Lecture 1_2

9/14

Page 9


DCNDS

Z08

1 -17

DenningSKC Protocol




u T is timestamp




1. A->S: A, B

2.S->A: {T, B, Ks, {Ks, A, T}Kb }Ka

3. A->B: {Ks, A, T}Kb

4. B->A: {Ib}Ks

5. A->B: {f(Ib)}Ks

6. AB: {Data}Ks

S

BA


DCNDS

Z08

1 -18

DenningSKC Protocol - 2

u Basically same protocol as Needham &Schroeder,except timestamp generated by S used instead ofnonce

u Message considered valid if on receipt:Clock - T< t1 + t2

whereo t1 is max. allowed discrepancy between KDC and

local clock

o t2 is max. network delay

u Provided Bs personal key not compromised, onlyreplay of message 3 is possible and timestampthwarts this attack

8/13/2019 Z08 Lecture 1_2

10/14

Page 10


DCNDS

Z08

1 -19

DenningProtocol Issues

u Clocks must be synchronised, so need secure clocksynchronisation protocol

u If recipient clock can be advanced, accidentally orby sabotage, protocol messages could be replayedagain at a valid time

u Frequent clock synchronisation with KDC is onesolution

u Neuman and Stubblebine [1993] proposed

protocol to remove this requirement using noncesagain


DCNDS

Z08

1 -20

Neuman and StubblebineSKC Protocol




u Tb is time limit for session key

u Ia, Ib are nonces




1. A->B: A, Ia

2. B->S: B, Ib, {A, Ia, Tb}Kb

3. S->A: {B, Ia, Ks, Tb}Ka,

{A, Ks, Tb}Kb, Ib

4. A->B: {A, Ks, Tb}Kb, {Ib}Ks

5. AB: {Data}Ks

S

BA

8/13/2019 Z08 Lecture 1_2

11/14

Page 11


DCNDS

Z08

1 -21

Neuman and StubblebineSKC Protocol - 2

u Impervious to clock sabotage or session keycracking

u Assumes Ka and Kb not compromised

u Nonce Ia is bound to Ks within short space of timevia protocol synchronisation not clock sync.

u Similarly, Ib is bound to Ks

u Tb provides a validity period for the session key

u {A, Ks, Tb}Kb acts as a ticket or authenticator forA with B, indicating session key and validityperiod


DCNDS

Z08

1 -22

Neuman and StubblebineSKC Protocol - 3

u Can avoid repeatedKDC exchanges byuse of ticket withinvalidity period

u Tb is relative to Bs

clock so no clocksync. issue

Creation of new session

1. A->B: {A, Ks, Tb}Kb, Ia

2. B->A: Ib, {Ia}Ks

3. A->B: {Ib}Ks

4. AB: {Data}Ks

BA

8/13/2019 Z08 Lecture 1_2

12/14

Page 12


DCNDS

Z08

1 -23

Single-ended Authentication

u In some applications parties are not necessarilyavailable simultaneously, e.g. e-mail

u Ideally, we would like to have mutualauthentication so that A knows only B can readmessage and B knows that it could only havecome from A

u If not possible to have 2-way dialogue, assurancesmay be weaker

u Note: this is not strictly one-way authentication


DCNDS

Z08

1 -24

Needham & SchroederSingle-ended Authentication

u Single-ended system, e.g. e-mail

u As before, plus:

u TS is senders timestamp

u Sn is serial number ofmessage fragment

u Recipient must check forpossible replays (via max.clock asynchrony andestimated delivery delay)

Authentication with Secret Keys

1. A->S: A, B, Ia1

2. S->A: {Ia1, B, Ks, {Ks, A}Kb }Ka

3. A->B: {Ks, A}Kb, {TS,S1, Mess1}Ks,

{S2,Mess2}Ks, ..

S

BA

8/13/2019 Z08 Lecture 1_2

13/14

Page 13


DCNDS

Z08

1 -25

E-mail Protocols

u This can form the basis of secure e-mail protocols

u However, e-mail is often distributed by theoriginator to several recipients so there areadditional threats and additional servicerequirements

u What might they be?

u See Pretty Good Privacy (PGP) and PrivacyEnhanced Mail (PEM) for more details


DCNDS

Z08

1 -26

Further Reading

u W Stallings, Cryptography and Network Security:Principles and Practice, 2ed, Prentice Hall, 1999, 0-13-869017-0

o Key Distribution: pp 141-149

o Authentication: pp 303-311

o Pretty Good Privacy: pp 356-374

u C Pfleeger, Security in Computing, 2ed, Prentice Hall,1997, 0-13-185794-0

o Privacy Enhanced Mail: pp 422-426

8/13/2019 Z08 Lecture 1_2

14/14

Page 14


DCNDS

Z08

1 -27

Further Reading - 2

u R Needham & M Schroeder, Using Encryption forAuthentication in Large Networks of Computers, CACM,Dec 1978

u D Denning, Cryptography and Data Security, Addison-Wesley, 1982

u B Neuman & S Stubblebine, A Note on the use ofTimestamps as Nonces, ACM Operating Systems Review,1993

Z08 Lecture 1_2

Documents