Part 3 Protocols 1 Part III: Protocols Part 3 Protocols 2 Protocol Human protocols the rules...

Part 3 Protocols 1

Part III: Protocols

Part 3 Protocols 2

Protocol Human protocols the rules followed in

human interactionso Example: Asking a question in class

Networking protocols rules followed in networked communication systemso Examples: HTTP, FTP, etc.

Security protocol the (communication) rules followed in a security applicationo Examples: SSL, IPSec, Kerberos, etc.

Part 3 Protocols 3

Protocols Protocol flaws can be very subtle Several well-known security

protocols have significant flawso Including WEP, GSM, and IPSec

Implementation errors can occuro Recent IE implementation of SSL

Not easy to get protocols right…

Part 3 Protocols 4

Ideal Security Protocol Must satisfy security requirements

o Requirements need to be precise Efficient

o Small computational requiremento Small bandwidth usage, minimal

delays… Robust

o Works when attacker tries to break ito Works even if environment changes

Easy to use & implement, flexible…

Difficult to satisfy all of these!

Chapter 9: Simple Security Protocols

“I quite agree with you,” said the Duchess; “and the moral of that is‘Be what you would seem to be’ or

if you'd like it put more simply‘Never imagine yourself not to be

otherwise than what it might appear to others that what you were

or might have been was not otherwise than what you

had been would have appeared to them to be otherwise.’ ”

Lewis Carroll, Alice in Wonderland

Seek simplicity, and distrust it.

Alfred North Whitehead

Part 2 Access Control 5

Part 3 Protocols 6

Secure Entry to NSA

1. Insert badge into reader2. Enter PIN3. Correct PIN?

Yes? EnterNo? Get shot by security guard

Part 3 Protocols 7

ATM Machine Protocol

1. Insert ATM card2. Enter PIN3. Correct PIN?

Yes? Conduct your transaction(s)No? Machine (eventually) eats card

Part 3 Protocols 8

Identify Friend or Foe (IFF)

NamibiaK

Angola

1. N

2. E(N,K)SAAFImpala

K

RussianMIG

Part 3 Protocols 9

MIG in the Middle

NamibiaK

Angola

1. N

2. N

3. N

4. E(N,K)

5. E(N,K)

6. E(N,K)

SAAFImpala

K

RussianMiG

Part 3 Protocols 10

Authentication Protocols

Part 3 Protocols 11

Authentication

Alice must prove her identity to Bobo Alice and Bob can be humans or computers

May also require Bob to prove he’s Bob (mutual authentication)

Probably need to establish a session key

May have other requirements, such aso Use public keyso Use symmetric keyso Use hash functionso Anonymity, plausible deniability, etc., etc.

Part 3 Protocols 12

Authentication

Authentication on a stand-alone computer is relatively simpleo Hash password with salt

o “Secure path,” attacks on authentication software, keystroke logging, etc., can be issues

Authentication over a network is challengingo Attacker can passively observe messages

o Attacker can replay messages

o Active attacks possible (insert, delete, change)

Part 3 Protocols 13

Simple Authentication

Alice Bob

“I’m Alice”

Prove it

My password is “frank”

Simple and may be OK for standalone system

But insecure for networked systemo Subject to a replay attack (next 2 slides)o Also, Bob must know Alice’s password

Part 3 Protocols 14

Authentication Attack

Alice Bob

“I’m Alice”

Prove it

My password is “frank”

Trudy

Part 3 Protocols 15

Authentication Attack

Bob

“I’m Alice”

Prove it

My password is “frank”Trudy

This is an example of a replay attack How can we prevent a replay?

Part 3 Protocols 16

Simple Authentication

Alice Bob

I’m Alice, my password is “frank”

More efficient, but… … same problem as previous version

Part 3 Protocols 17

Better Authentication

Alice Bob

“I’m Alice”

Prove it

h(Alice’s password)

Better since it hides Alice’s passwordo From both Bob and Trudy

But still subject to replay

Part 3 Protocols 18

Challenge-Response To prevent replay, use challenge-

responseo Goal is to ensure “freshness”

Suppose Bob wants to authenticate Aliceo Challenge sent from Bob to Alice

Challenge is chosen so that… o Replay is not possible

o Only Alice can provide the correct response

o Bob can verify the response

Part 3 Protocols 19

Nonce To ensure freshness, can employ a

nonceo Nonce == number used once

What to use for nonces?o That is, what is the challenge?

What should Alice do with the nonce?o That is, how to compute the response?

How can Bob verify the response? Should we rely on passwords or keys?

Part 3 Protocols 20

Challenge-Response

Bob

“I’m Alice”

Nonce

h(Alice’s password, Nonce)

Nonce is the challenge The hash is the response Nonce prevents replay, ensures freshness Password is something Alice knows Note: Bob must know Alice’s pwd to verify

Alice

Part 3 Protocols 21

Generic Challenge-Response

Bob

“I’m Alice”

Nonce

Something that could only be

Alice from Alice (and Bob can verify)

In practice, how to achieve this? Hashed password works, but… Encryption is better here (Why?)

Part 3 Protocols 22

Symmetric Key Notation Encrypt plaintext P with key K

C = E(P,K) Decrypt ciphertext C with key K

P = D(C,K) Here, we are concerned with attacks on

protocols, not attacks on cryptoo So, we assume crypto algorithms are secure

Part 3 Protocols 23

Authentication: Symmetric Key

Alice and Bob share symmetric key K

Key K known only to Alice and Bob Authenticate by proving knowledge

of shared symmetric key How to accomplish this?

o Cannot reveal key, must not allow replay (or other) attack, must be verifiable, …

Part 3 Protocols 24

Authentication with Symmetric Key

Alice, K Bob, K

“I’m Alice”

E(R,K)

Secure method for Bob to authenticate Alice Alice does not authenticate Bob

So, can we achieve mutual authentication?

R

Part 3 Protocols 25

Mutual Authentication?

Alice, K Bob, K

“I’m Alice”, R

E(R,K)

E(R,K)

What’s wrong with this picture? “Alice” could be Trudy (or anybody

else)!

Part 3 Protocols 26

Mutual Authentication Since we have a secure one-way

authentication protocol… The obvious thing to do is to use

the protocol twiceo Once for Bob to authenticate Aliceo Once for Alice to authenticate Bob

This has got to work…

Part 3 Protocols 27

Mutual Authentication

Alice, K Bob, K

“I’m Alice”, RA

RB, E(RA, K)

E(RB, K)

This provides mutual authentication… …or does it? See the next slide

Part 3 Protocols 28

Mutual Authentication Attack

Bob, K

1. “I’m Alice”, RA

2. RB, E(RA, K)

Trudy

Bob, K

3. “I’m Alice”, RB

4. RC, E(RB, K)

Trudy

5. E(RB, K)

Part 3 Protocols 29

Mutual Authentication Our one-way authentication protocol is

not secure for mutual authentication o Protocols are subtle!o The “obvious” thing may not be secure

Also, if assumptions or environment change, protocol may not be secureo This is a common source of security

failureo For example, Internet protocols

Part 3 Protocols 30

Symmetric Key Mutual Authentication

Alice, K Bob, K


RB, E(“Bob”,RA,K)

E(“Alice”,RB,K)

Do these “insignificant” changes help? Yes!

Part 3 Protocols 31

Public Key Notation Encrypt M with Alice’s public key: {M}Alice

Sign M with Alice’s private key: [M]Alice

Theno [{M}Alice ]Alice = M

o {[M]Alice }Alice = M

Anybody can use Alice’s public key Only Alice can use her private key

Part 3 Protocols 32

Public Key Authentication

Alice Bob

“I’m Alice”

{R}Alice

R

Is this secure? Trudy can get Alice to decrypt anything!

o So, should have two key pairs

Part 3 Protocols 33

Public Key Authentication

Alice Bob

“I’m Alice”

R

[R]Alice

Is this secure? Trudy can get Alice to sign anything!

o Same a previous should have two key pairs

Part 3 Protocols 34

Public Keys Generally, a bad idea to use the

same key pair for encryption and signing

Instead, should have…o …one key pair for

encryption/decryption…o …and a different key pair for

signing/verifying signatures

Part 3 Protocols 35

Session Key Usually, a session key is required

o I.e., a symmetric key for a particular sessiono Used for confidentiality and/or integrity

How to authenticate and establish a session key (i.e., shared symmetric key)?o When authentication completed, want Alice

and Bob to share a session keyo Trudy cannot break the authentication…o …and Trudy cannot determine the session

key

Part 3 Protocols 36

Authentication & Session Key

Alice Bob


{R,K}Alice

{R +1,K}Bob

Is this secure?o Alice is authenticated and session key is

secureo Alice’s “nonce”, R, useless to authenticate

Bobo The key K is acting as Bob’s nonce to Alice

No mutual authentication

Part 3 Protocols 37

Public Key Authentication and Session Key

Alice Bob


[R,K]Bob

[R +1,K]Alice

Is this secure?o Mutual authentication (good), but…o … session key is not secret (very bad)

Part 3 Protocols 38


Alice Bob


{[R,K]Bob}Alice

{[R +1,K]Alice}Bob

Is this secure? Seems to be OK Mutual authentication and session key!

Part 3 Protocols 39


Alice Bob


[{R,K}Alice]Bob

[{R +1,K}Bob]Alice

Is this secure? Seems to be OK

o Anyone can see {R,K}Alice and {R +1,K}Bob

Part 3 Protocols 40

Perfect Forward Secrecy Consider this “issue”…

o Alice encrypts message with shared key K and sends ciphertext to Bob

o Trudy records ciphertext and later attacks Alice’s (or Bob’s) computer to recover K

o Then Trudy decrypts recorded messages

Perfect forward secrecy (PFS): Trudy cannot later decrypt recorded ciphertexto Even if Trudy gets key K or other secret(s)

Is PFS possible?

Part 3 Protocols 41

Perfect Forward Secrecy

Suppose Alice and Bob share key K For perfect forward secrecy, Alice and

Bob cannot use K to encrypt

Instead they must use a session key KS and forget it after it’s used

Can Alice and Bob agree on session key KS in a way that ensures PFS?

Part 3 Protocols 42

Naïve Session Key Protocol

Trudy could record E(KS, K) If Trudy later gets K then she can get

KS o Then Trudy can decrypt recorded messages

Alice, K Bob, K

E(KS, K)

E(messages, KS)

Part 3 Protocols 43

Perfect Forward Secrecy We use Diffie-Hellman for PFS Recall: public g and p

But Diffie-Hellman is subject to MiM How to get PFS and prevent MiM?

Alice, a Bob, b

ga mod p

gb mod p

Part 3 Protocols 44

Perfect Forward Secrecy

Session key KS = gab mod p Alice forgets a, Bob forgets b So-called Ephemeral Diffie-Hellman Neither Alice nor Bob can later recover KS

Are there other ways to achieve PFS?

Alice: K, a Bob: K, b

E(ga mod p, K)

E(gb mod p, K)

Part 3 Protocols 45

Mutual Authentication, Session Key and PFS

Alice Bob


RB, [{RA, gb mod p}Alice]Bob

[{RB, ga mod p}Bob]Alice

Session key is K = gab mod p Alice forgets a and Bob forgets b If Trudy later gets Bob’s and Alice’s

secrets, she cannot recover session key K

Part 3 Protocols 46

Timestamps A timestamp T is derived from current

time Timestamps used in some security

protocolso Kerberos, for example

Timestamps reduce number of msgs (good)o Like a nonce that both sides know in advance

“Time” is a security-critical parameter (bad)

Clocks never exactly the same, so must allow for clock skew creates risk of replayo How much clock skew is enough?

Part 3 Protocols 47

Public Key Authentication with Timestamp T

Bob

“I’m Alice”, {[T, K]Alice}Bob

{[T +1, K]Bob}Alice

Alice

Secure mutual authentication? Session key? Seems to be OK

Part 3 Protocols 48


Bob

“I’m Alice”, [{T, K}Bob]Alice

[{T +1, K}Alice]Bob

Alice

Secure authentication and session key? Trudy can use Alice’s public key to find {T, K}Bob and then…

Part 3 Protocols 49


Bob

“I’m Trudy”, [{T, K}Bob]Trudy

[{T +1, K}Trudy]Bob

Trudy

Trudy obtains Alice-Bob session key K Note: Trudy must act within clock skew

Part 3 Protocols 50

Public Key Authentication Sign and encrypt with nonce…

o Secure Encrypt and sign with nonce…

o Secure Sign and encrypt with timestamp…

o Secure Encrypt and sign with timestamp…

o Insecure Protocols can be subtle!

Part 3 Protocols 51


Bob

“I’m Alice”, [{T, K}Bob]Alice

[{T +1}Alice]Bob

Alice

Is this “encrypt and sign” secure?o Yes, seems to be OK

Does “sign and encrypt” also work here?

Part 3 Protocols 52

Authentication and TCP

Part 3 Protocols 53

TCP-based Authentication TCP not intended for use as an

authentication protocol But IP address in TCP connection

often used for authentication One mode of IPSec relies on IP

address for authentication

Part 3 Protocols 54

TCP 3-way Handshake

Alice Bob

SYN, SEQ a

SYN, ACK a+1, SEQ b

ACK b+1, data

Recall the TCP three way handshake Initial sequence numbers: SEQ a and SEQ b o Supposed to be selected at random

If not…

Part 3 Protocols 55

TCP Authentication Attack

Alice

BobTrudy

1. SYN, SEQ = t (as Trudy)2. SYN, ACK = t+1, SEQ = b1

3. SYN, SEQ = t (as Alice)

4. SYN, A

CK = t+1, S

EQ = b 2

5. ACK = b2+1, data

5.

5.

5.

5.

…

Part 3 Protocols 56


Random SEQ numbersInitial SEQ numbers

Mac OS X

If initial SEQ numbers not very random… …possible to guess initial SEQ number… …and previous attack will succeed

Part 3 Protocols 57


Trudy cannot see what Bob sends, but she can send packets to Bob, while posing as Alice

Trudy must prevent Alice from receiving Bob’s packets (or else connection will terminate)

If password (or other authentication) required, this attack fails

If TCP connection is relied on for authentication, then attack can succeed

Bad idea to rely on TCP for authentication

Part 3 Protocols 58

Zero Knowledge Proofs

Part 3 Protocols 59

Zero Knowledge Proof (ZKP)

Alice wants to prove that she knows a secret without revealing any info about it

Bob must verify that Alice knows secreto But, Bob gains no info about the secret

Process is probabilistico Bob can verify that Alice knows the secret to

an arbitrarily high probability

An “interactive proof system”

Part 3 Protocols 60

Bob’s Cave

Alice knows secret phrase to open path between R and S (“open sarsaparilla”)

Can she convince Bob that she knows the secret without revealing phrase?

P

Q

R S

Part 3 Protocols 61

Bob: “Alice come out on S side”

Alice (quietly): “Open sarsaparilla”

If Alice does not know the secret…

If Bob repeats this n times, then Alice (who does not know secret) can only fool Bob with probability 1/2n

…then Alice could come out from the correct side with probability 1/2

P

Q

R S

Bob’s Cave

Part 3 Protocols 62

Fiat-Shamir Protocol Cave-based protocols are inconvenient

o Can we achieve same effect without the cave?

Finding square roots modulo N is difficulto Equivalent to factoring

Suppose N = pq, where p and q prime Alice has a secret S N and v = S2 mod N are public, S is

secret Alice must convince Bob that she knows

S without revealing any information about S

Part 3 Protocols 63

Fiat-Shamir

Public: Modulus N and v = S2 mod N Alice selects random r, Bob chooses e

{0,1} Bob verifies: y2 = x ve mod N

o Why? Because… y2 = r2 S2e = r2 (S2)e = x ve mod N

Alicesecret Srandom r

Bobrandom e

x = r2 mod N

e {0,1}

y = r Se mod N

Part 3 Protocols 64

Fiat-Shamir: e = 1

Public: Modulus N and v = S2 mod N Alice selects random r, Bob chooses e =1 If y2 = x v mod N then Bob accepts it

o I.e., “Alice” passes this iteration of the protocol Note that Alice must know S in this case


Bobrandom e

x = r2 mod N

e = 1

y = r S mod N

Part 3 Protocols 65

Fiat-Shamir: e = 0

Public: Modulus N and v = S2 mod N Alice selects random r, Bob chooses e =

0 Bob must checks whether y2 = x mod N Alice does not need to know S in this

case!


Bobrandom e

x = r2 mod N

e = 0

y = r mod N

Part 3 Protocols 66

Fiat-Shamir Public: modulus N and v = S2 mod N Secret: Alice knows S Alice selects random r and commits to

r by sending x = r2 mod N to Bob Bob sends challenge e {0,1} to Alice Alice responds with y = r Se mod N Bob checks whether y2 = x ve mod N

o Does this prove response is from Alice?

Part 3 Protocols 67

Does Fiat-Shamir Work? If everyone follows protocol, math

works:o Public: v = S2 mod N o Alice to Bob: x = r2 mod N and y = r Se mod

N o Bob verifies: y2 = x ve mod N

Can Trudy convince Bob she is Alice?o If Trudy expects e = 0, she sends x = r2 in

msg 1 and y = r in msg 3 (i.e., follow the protocol)

o If Trudy expects e = 1, sends x = r2 v1 in msg 1 and y = r in msg 3

If Bob chooses e {0,1} at random, Trudy can only trick Bob with probability 1/2

Part 3 Protocols 68

Fiat-Shamir Facts Trudy can trick Bob with probability 1/2,

but…o …after n iterations, the probability that Trudy

can convince Bob that she is Alice is only 1/2n

o Just like Bob’s cave!

Bob’s e {0,1} must be unpredictable Alice must use new r each iteration, or

else…o If e = 0, Alice sends r mod N in message 3o If e = 1, Alice sends r S mod N in message 3o Anyone can find S given r mod N and r S mod

N

Part 3 Protocols 69

Fiat-Shamir Zero Knowledge?

Zero knowledge means that nobody learns anything about the secret So Public: v = S2 mod No Trudy sees r2 mod N in message 1o Trudy sees r S mod N in message 3 (if e = 1)

If Trudy can find r from r2 mod N, gets So But that requires modular square rooto If Trudy could find modular square roots, she

could get S from public v Protocol does not seem to “help” to find

S

Part 3 Protocols 70

ZKP in the Real World

Public key certificates identify userso No anonymity if certificates sent in plaintext

ZKP offers a way to authenticate without revealing identities

ZKP supported in MS’s Next Generation Secure Computing Base (NGSCB), where…o …ZKP used to authenticate software “without

revealing machine identifying data”

ZKP is not just pointless mathematics!

Part 3 Protocols 71

Best Authentication Protocol?

It depends on…o The sensitivity of the application/data

o The delay that is tolerable

o The cost (computation) that is tolerable

o What crypto is supported (public key, symmetric key, …)

o Whether mutual authentication is required

o Whether PFS, anonymity, etc., are concern

…and possibly other factors

Chapter 10: Real-World Protocols

The wire protocol guys don't worry about security because that's really

a network protocol problem. The network protocol guys don't

worry about it because, really, it's an application problem.

The application guys don't worry about it because, after all,

they can just use the IP address and trust the network.

Marcus J. Ranum

In the real world, nothing happens at the right place at the right time.

It is the job of journalists and historians to correct that.

Mark Twain

Part 2 Access Control 72

Part 3 Protocols 73

Real-World Protocols

Next, we look at real protocolso SSH a simple & useful security protocolo SSL practical security on the Webo IPSec security at the IP layero Kerberos symmetric key, single sign-ono WEP “Swiss cheese” of security

protocolso GSM mobile phone (in)security

Secure Shell (SSH)

Part 3 Protocols 74

SSH Creates a “secure tunnel” Insecure command sent thru SSH

tunnel are then secure SSH used with things like rlogin

o Why is rlogin insecure without SSH?o Why is rlogin secure with SSH?

SSH is a relatively simple protocol

Part 3 Protocols 75

SSH SSH authentication can be based

on:o Public keys, oro Digital certificates, oro Passwords

Here, we consider certificate modeo Other modes, see homework

problems We consider slightly simplified

SSH…

Part 3 Protocols 76

Simplified SSH

CP = “crypto proposed”, and CS = “crypto selected” H = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gb mod p,gab

mod p) SB = [H]Bob

SA = [H, Alice, certificateA]Alice

K = gab mod p Part 3 Protocols 77

Alice Bob

Alice, CP, RA

CS, RB

ga mod p

gb mod p, certificateB, SB

E(Alice, certificateA, SA, K)

MiM Attack on SSH?

Where does this attack fail? Alice computes:

o Ha = h(Alice,Bob,CP,CS,RA,RB,ga mod p,gt mod p,gat mod p)

But Bob signs:o Hb = h(Alice,Bob,CP,CS,RA,RB,gt mod p,gb mod p,gbt mod p)

Part 3 Protocols 78

Alice Bob

Alice, RA

RB

ga mod pgb mod p, certB, SB

E(Alice,certA,SA,K)

Alice, RA

RB

gt mod pgt mod p, certB, SB

E(Alice,certA,SA,K)Trudy

Part 3 Protocols 79

Secure Socket Layer

Part 3 Protocols 80

Socket layer “Socket

layer” lives between application and transport layers

SSL usually between HTTP and TCP

application

transport

network

link

physical

Socket“layer”

OS

User

NIC

Part 3 Protocols 81

What is SSL? SSL is the protocol used for majority of

secure transactions on the Internet For example, if you want to buy a book

at amazon.com…o You want to be sure you are dealing with

Amazon (authentication)o Your credit card information must be

protected in transit (confidentiality and/or integrity)

o As long as you have money, Amazon does not care who you are

o So, no need for mutual authentication

Part 3 Protocols 82

Simple SSL-like Protocol

Alice Bob

I’d like to talk to you securely

Here’s my certificate

{K}Bob

protected HTTP

Is Alice sure she’s talking to Bob? Is Bob sure he’s talking to Alice?

Part 3 Protocols 83

Simplified SSL Protocol

Alice Bob

Can we talk?, cipher list, RA

certificate, cipher, RB

{S}Bob, E(h(msgs,CLNT,K),K)

Data protected with key K

h(msgs,SRVR,K)

S is known as pre-master secret K = h(S,RA,RB) “msgs” means all previous messages CLNT and SRVR are constants

Part 3 Protocols 84

SSL Keys

6 “keys” derived from K = h(S,RA,RB)o 2 encryption keys: send and receiveo 2 integrity keys: send and receiveo 2 IVs: send and receiveo Why different keys in each direction?

Q: Why is h(msgs,CLNT,K) encrypted? A: Apparently, it adds no security…

Part 3 Protocols 85

SSL Authentication Alice authenticates Bob, not vice-versa

o How does client authenticate server?

o Why would server not authenticate client?

Mutual authentication is possible: Bob sends certificate request in message 2o Then client must have a valid certificate

o But, if server wants to authenticate client, server could instead require password

Part 3 Protocols 86

SSL MiM Attack?

Alice Bob

RA

certificateT, RB

{S1}Trudy,E(X1,K1)

E(data,K1)

h(Y1,K1)

Q: What prevents this MiM “attack”? A: Bob’s certificate must be signed by a

certificate authority (CA) What does browser do if signature not valid? What does user do when browser complains?

Trudy

RA

certificateB, RB

{S2}Bob,E(X2,K2)

E(data,K2)

h(Y2,K2)

Part 3 Protocols 87

SSL Sessions vs Connections

SSL session is established as shown on previous slides

SSL designed for use with HTTP 1.0 HTTP 1.0 often opens multiple

simultaneous (parallel) connectionso Multiple connections per session

SSL session is costly, public key operations

SSL has an efficient protocol for opening new connections given an existing session

Part 3 Protocols 88

SSL Connection

Alice Bob

session-ID, cipher list, RA

session-ID, cipher, RB,

h(msgs,SRVR,K)

h(msgs,CLNT,K)

Protected data

Assuming SSL session exists So, S is already known to Alice and Bob Both sides must remember session-ID Again, K = h(S,RA,RB) No public key operations! (relies on

known S)

Part 3 Protocols 89

SSL vs IPSec IPSec discussed in next section

o Lives at the network layer (part of the OS)o Encryption, integrity, authentication, etc.o Is overly complex, has some security “issues”

SSL (and IEEE standard known as TLS)o Lives at socket layer (part of user space)o Encryption, integrity, authentication, etc.o Relatively simple and elegant specification

Part 3 Protocols 90

SSL vs IPSec IPSec: OS must be aware, but not apps SSL: Apps must be aware, but not OS SSL built into Web early-on (Netscape) IPSec often used in VPNs (secure tunnel) Reluctance to retrofit applications for SSL IPSec not widely deployed (complexity,

etc.) The bottom line… Internet less secure than it should

be!

Part 3 Protocols 91

IPSec

Part 3 Protocols 92

IPSec and SSL IPSec lives at

the network layer

IPSec is transparent to applications

application

transport

network

link

physical

SSL

OS

User

NIC

IPSec

Part 3 Protocols 93

IPSec and Complexity IPSec is a complex protocol Over-engineered

o Lots of (generally useless) features

Flawedo Some significant security issues

Interoperability is serious challengeo Defeats the purpose of having a standard!

Complex And, did I mention, it’s complex?

Part 3 Protocols 94

IKE and ESP/AH Two parts to IPSec IKE: Internet Key Exchange

o Mutual authenticationo Establish session keyo Two “phases” like SSL session/connection

ESP/AHo ESP: Encapsulating Security Payload for

encryption and/or integrity of IP packetso AH: Authentication Header integrity only

Part 3 Protocols 95

IKE

Part 3 Protocols 96

IKE IKE has 2 phases

o Phase 1 IKE security association (SA)o Phase 2 AH/ESP security association

Phase 1 is comparable to SSL session Phase 2 is comparable to SSL

connection Not an obvious need for two phases in

IKE If multiple Phase 2’s do not occur, then

it is more costly to have two phases!

Part 3 Protocols 97

IKE Phase 1 Four different “key” options

o Public key encryption (original version)o Public key encryption (improved version)o Public key signatureo Symmetric key

For each of these, two different “modes”o Main mode and aggressive mode

There are 8 versions of IKE Phase 1!

Need more evidence it’s over-engineered?

Part 3 Protocols 98

IKE Phase 1 We discuss 6 of 8 Phase 1 variants

o Public key signatures (main & aggressive modes)

o Symmetric key (main and aggressive modes)

o Public key encryption (main and aggressive)

Why public key encryption and public key signatures?o Always know your own private key

o May not (initially) know other side’s public key

Part 3 Protocols 99

IKE Phase 1 Uses ephemeral Diffie-Hellman to

establish session keyo Provides perfect forward secrecy (PFS)

Let a be Alice’s Diffie-Hellman exponent Let b be Bob’s Diffie-Hellman exponent Let g be generator and p prime Recall that p and g are public

Part 3 Protocols 100

IKE Phase 1: Digital Signature (Main Mode)

CP = crypto proposed, CS = crypto selected IC = initiator “cookie”, RC = responder “cookie” K = h(IC,RC,gab mod p,RA,RB) SKEYID = h(RA, RB, gab mod p) proofA = [h(SKEYID,ga mod p,gb mod

p,IC,RC,CP,“Alice”)]Alice

Alice Bob

IC, CP

IC,RC, CS

IC,RC, ga mod p, RA

IC,RC, E(“Alice”, proofA, K)

IC,RC, gb mod p, RB

IC,RC, E(“Bob”, proofB, K)


IKE Phase 1: Public Key Signature (Aggressive Mode)

Main difference from main modeo Not trying to protect identitieso Cannot negotiate g or p

Alice Bob

IC, “Alice”, ga mod p, RA, CP

IC,RC, “Bob”, RB,

gb mod p, CS, proofB

IC,RC, proofA


Main vs Aggressive Modes Main mode MUST be implemented Aggressive mode SHOULD be

implementedo So, if aggressive mode is not implemented,

“you should feel guilty about it”

Might create interoperability issues For public key signature authentication

o Passive attacker knows identities of Alice and Bob in aggressive mode, but not in main mode

o Active attacker can determine Alice’s and Bob’s identity in main mode


IKE Phase 1: Symmetric Key (Main Mode)

Same as signature mode excepto KAB = symmetric key shared in advance o K = h(IC,RC,gab mod p,RA,RB,KAB)o SKEYID = h(K, gab mod p)o proofA = h(SKEYID,ga mod p,gb mod

p,IC,RC,CP,“Alice”)

AliceKAB

BobKAB

IC, CP

IC,RC, CS

IC,RC, ga mod p, RA

IC,RC, E(“Alice”, proofA, K)

IC,RC, gb mod p, RB

IC,RC, E(“Bob”, proofB, K)


Problems with Symmetric Key (Main Mode)

Catch-22o Alice sends her ID in message 5o Alice’s ID encrypted with Ko To find K Bob must know KAB

o To get KAB Bob must know he’s talking to Alice!

Result: Alice’s ID must be IP address!

Useless mode for the “road warrior” Why go to all of the trouble of trying to

hide identities in 6 message protocol?


IKE Phase 1: Symmetric Key (Aggressive Mode)

Same format as digital signature aggressive mode

Not trying to hide identities… As a result, does not have problems of main

mode But does not (pretend to) hide identities

Alice Bob

IC, “Alice”, ga mod p, RA, CP

IC,RC, “Bob”, RB,

gb mod p, CS, proofB

IC,RC, proofA


IKE Phase 1: Public Key Encryption (Main Mode)

CP = crypto proposed, CS = crypto selected IC = initiator “cookie”, RC = responder “cookie” K = h(IC,RC,gab mod p,RA,RB) SKEYID = h(RA, RB, gab mod p) proofA = h(SKEYID,ga mod p,gb mod

p,IC,RC,CP,“Alice”)

Alice Bob

IC, CP

IC,RC, CS

IC,RC, ga mod p, {RA}Bob, {“Alice”}Bob

IC,RC, E(proofA, K)

IC,RC, gb mod p, {RB}Alice, {“Bob”}Alice

IC,RC, E(proofB, K)


IKE Phase 1: Public Key Encryption (Aggressive

Mode)

K, proofA, proofB computed as in main mode

Note that identities are hiddeno The only aggressive mode to hide identitieso So, why have a main mode?

Alice Bob

IC, CP, ga mod p,{“Alice”}Bob, {RA}Bob

IC,RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proofB

IC,RC, proofA


Public Key Encryption Issue?

In public key encryption, aggressive mode…

Suppose Trudy generateso Exponents a and b

o Nonces RA and RB

Trudy can compute “valid” keys and proofs: gab mod p, K, SKEYID, proofA and proofB

This also works in main mode


Public Key Encryption Issue?

Trudyas Alice

Trudyas Bob

Trudy can create exchange that appears to be between Alice and Bob

Appears valid to any observer, including Alice and Bob!

IC,RC, CS, gb mod p, {“Bob”}Alice, {RB}Alice, proofB

IC,RC, proofA

IC, CP, ga mod p,{“Alice”}Bob, {RA}Bob


Plausible Deniability Trudy can create “conversation” that

appears to be between Alice and Bob Appears valid, even to Alice and Bob! A security failure? In this IPSec key option, it is a

feature…o Plausible deniability: Alice and Bob can

deny that any conversation took place! In some cases it might create a problem

o E.g., if Alice makes a purchase from Bob, she could later repudiate it (unless she had signed)


IKE Phase 1 Cookies IC and RC cookies (or “anti-clogging

tokens”) supposed to prevent DoS attackso No relation to Web cookies

To reduce DoS threats, Bob wants to remain stateless as long as possible

But Bob must remember CP from message 1 (required for proof of identity in message 6)

Bob must keep state from 1st message ono So, these “cookies” offer little DoS protection


IKE Phase 1 Summary Result of IKE phase 1 is

o Mutual authenticationo Shared symmetric keyo IKE Security Association (SA)

But phase 1 is expensiveo Especially in public key and/or main mode

Developers of IKE thought it would be used for lots of things not just IPSeco Partly explains the over-engineering…


IKE Phase 2

Phase 1 establishes IKE SA Phase 2 establishes IPSec SA Comparison to SSL

o SSL session is comparable to IKE Phase 1

o SSL connections are like IKE Phase 2

IKE could be used for lots of things… …but in practice, it’s not!


IKE Phase 2

Key K, IC, RC and SA known from Phase 1 Proposal CP includes ESP and/or AH Hashes 1,2,3 depend on SKEYID, SA, RA and RB

Keys derived from KEYMAT = h(SKEYID,RA,RB,junk) Recall SKEYID depends on phase 1 key method Optional PFS (ephemeral Diffie-Hellman exchange)

Alice Bob

IC,RC,CP,E(hash1,SA,RA,K)

IC,RC,CS,E(hash2,SA,RB,K)

IC,RC,E(hash3,K)


IPSec

After IKE Phase 1, we have an IKE SA After IKE Phase 2, we have an IPSec SA Both sides have a shared symmetric key Now what?

o We want to protect IP datagrams

But what is an IP datagram?o Considered from the perspective of IPSec…


IP Review

Where IP header is

IP header data

IP datagram is of the form


IP and TCP Consider Web traffic

o IP encapsulates TCP and…o …TCP encapsulates HTTP

IP header TCP hdr HTTP hdr app data

IP header data

IP data includes TCP header, etc.


IPSec Transport Mode IPSec Transport Mode

IP header data

IP header ESP/AH data

Transport mode designed for host-to-host

Transport mode is efficiento Adds minimal amount of extra header

The original header remainso Passive attacker can see who is talking

IPSec: Host-to-Host IPSec transport mode


There may be firewalls in betweeno If so, is that a problem?


IPSec Tunnel Mode IPSec Tunnel Mode

IP header data

new IP hdr ESP/AH IP header data

Tunnel mode for firewall-to-firewall traffic

Original IP packet encapsulated in IPSec Original IP header not visible to attacker

o New IP header from firewall to firewallo Attacker does not know which hosts are talking

IPSec: Firewall-to-Firewall IPSec tunnel mode


Local networks not protected Is there any advantage here?


Comparison of IPSec Modes

Transport Mode

Tunnel Mode

IP header data

IP header ESP/AH data

IP header data

new IP hdr ESP/AH IP header data

Transport Modeo Host-to-host

Tunnel Modeo Firewall-to-

firewall

Transport Mode not necessary…

…but it’s more efficient


IPSec Security What kind of protection?

o Confidentiality?o Integrity?o Both?

What to protect?o Data?o Header?o Both?

ESP/AH do some combinations of these


AH vs ESP AH Authentication Header

o Integrity only (no confidentiality)

o Integrity-protect everything beyond IP header and some fields of header (why not all fields?)

ESP Encapsulating Security Payloado Integrity and confidentiality both

required

o Protects everything beyond IP header

o Integrity-only by using NULL encryption

http://www.faqs.org/rfcs/rfc2410.html


ESP’s NULL Encryption According to RFC 2410

o NULL encryption “is a block cipher the origins of which appear to be lost in antiquity”

o “Despite rumors”, there is no evidence that NSA “suppressed publication of this algorithm”

o Evidence suggests it was developed in Roman times as exportable version of Caesar’s cipher

o Can make use of keys of varying lengtho No IV is requiredo Null(P,K) = P for any P and any key K

Bottom line: Security people can be strange


Why Does AH Exist? (1)

Cannot encrypt IP headero Routers must look at the IP headero IP addresses, TTL, etc.o IP header exists to route packets!

AH protects immutable fields in IP headero Cannot integrity protect all header fieldso TTL, for example, will change

ESP does not protect IP header at all



ESP encrypts everything beyond the IP header (if non-null encryption)

If ESP-encrypted, firewall cannot look at TCP header (e.g., port numbers)

Why not use ESP with NULL encryption?o Firewall sees ESP header, but does not know

whether null encryption is used

o End systems know, but not the firewalls



The real reason why AH exists:o At one IETF meeting “someone from

Microsoft gave an impassioned speech about how AH was useless…”

o “…everyone in the room looked around and said `Hmm. He’s right, and we hate AH also, but if it annoys Microsoft let’s leave it in since we hate Microsoft more than we hate AH.’ ”


Kerberos


Kerberos In Greek mythology, Kerberos is 3-

headed dog that guards entrance to Hadeso “Wouldn’t it make more sense to guard the

exit?”

In security, Kerberos is an authentication protocol based on symmetric key cryptoo Originated at MITo Based on work by Needham and Schroedero Relies on a Trusted Third Party (TTP)


Motivation for Kerberos

Authentication using public keyso N users N key pairs

Authentication using symmetric keyso N users requires (on the order of) N2 keys

Symmetric key case does not scale Kerberos based on symmetric keys but

only requires N keys for N users- Security depends on TTP + No PKI is needed


Kerberos KDC Kerberos Key Distribution Center or

KDCo KDC acts as the TTPo TTP is trusted, so it must not be

compromised KDC shares symmetric key KA with Alice,

key KB with Bob, key KC with Carol, etc. And a master key KKDC known only to

KDC KDC enables authentication, session

keyso Session key for confidentiality and integrity

In practice, crypto algorithm is DES


Kerberos Tickets KDC issue tickets containing info

needed to access network resources KDC also issues Ticket-Granting

Tickets or TGTs that are used to obtain tickets

Each TGT containso Session keyo User’s IDo Expiration time

Every TGT is encrypted with KKDC

o So, TGT can only be read by the KDC


Kerberized Login Alice enters her password Then Alice’s computer does following:

o Derives KA from Alice’s password

o Uses KA to get TGT for Alice from KDC

Alice then uses her TGT (credentials) to securely access network resources

Plus: Security is transparent to Alice Minus: KDC must be secure it’s

trusted!


Kerberized Login

Alice

Alice’s

Alice wants

password a TGT

E(SA,TGT,KA)

KDC

Key KA = h(Alice’s password) KDC creates session key SA

Alice’s computer decrypts SA and TGTo Then it forgets KA

TGT = E(“Alice”, SA, KKDC)

Computer


Alice Requests “Ticket to Bob”

Alice

Talk to Bob

I want totalk to Bob

REQUEST

REPLY

KDC

REQUEST = (TGT, authenticator)o authenticator = E(timestamp, SA)

REPLY = E(“Bob”, KAB, ticket to Bob, SA)o ticket to Bob = E(“Alice”, KAB, KB)

KDC gets SA from TGT to verify timestamp

Computer


Alice Uses Ticket to Bob

ticket to Bob, authenticator

E(timestamp + 1, KAB)

ticket to Bob = E(“Alice”, KAB, KB) authenticator = E(timestamp, KAB) Bob decrypts “ticket to Bob” to get KAB

which he then uses to verify timestamp

Alice’s Computer

Bob


Kerberos Key SA used in authentication

o For confidentiality/integrity Timestamps for authentication and

replay protection Recall, that timestamps…

o Reduce the number of messageslike a nonce that is known in advance

o But, “time” is a security-critical parameter


Kerberos Questions When Alice logs in, KDC sends E(SA, TGT,

KA) where TGT = E(“Alice”, SA, KKDC)

Q: Why is TGT encrypted with KA?

A: Extra work for no added security!

In Alice’s “Kerberized” login to Bob, why can Alice remain anonymous?

Why is “ticket to Bob” sent to Alice?o Why doesn’t KDC send it directly to Bob?


Kerberos Alternatives Could have Alice’s computer remember

password and use that for authenticationo Then no KDC requiredo But hard to protect passwordso Also, does not scale

Could have KDC remember session key instead of putting it in a TGTo Then no need for TGTo But stateless KDC is major feature of

Kerberos


Kerberos Keys In Kerberos, KA = h(Alice’s password) Could instead generate random KA

o Compute Kh = h(Alice’s password)

o And Alice’s computer stores E(KA, Kh)

Then KA need not change when Alice changes her passwordo But E(KA, Kh) must be stored on computer

This alternative approach is often usedo But not in Kerberos

WEP


WEP WEP Wired Equivalent Privacy The stated goal of WEP is to make

wireless LAN as secure as a wired LAN

According to Tanenbaum:o “The 802.11 standard prescribes a data link-

level security protocol called WEP (Wired Equivalent Privacy), which is designed to make the security of a wireless LAN as good as that of a wired LAN. Since the default for a wired LAN is no security at all, this goal is easy to achieve, and WEP achieves it as we shall see.” Part 3 Protocols

143

WEP Authentication

Bob is wireless access point Key K shared by access point and all

userso Key K seldom (if ever) changes

WEP has many, many, many security flaws Part 3 Protocols

144

Alice, K Bob, K

Authentication Request

R

E(R, K)

WEP Issues WEP uses RC4 cipher for confidentiality

o RC4 is considered a strong cipher

o But WEP introduces a subtle flaw…

o …making cryptanalytic attacks feasible

WEP uses CRC for “integrity”o Should have used a MAC or HMAC instead

o CRC is for error detection, not crypto integrity

o Everyone knows NOT to use CRC for this… Part 3 Protocols 145

WEP Integrity Problems WEP “integrity” gives no crypto integrity

o CRC is linear, so is stream cipher (XOR)o Trudy can change ciphertext and CRC so

that checksum remains correcto Then Trudy’s introduced errors go

undetectedo Requires no knowledge of the plaintext!

CRC does not provide a cryptographic integrity checko CRC designed to detect random errorso Not able to detect intelligent changes


More WEP Integrity Issues Suppose Trudy knows destination IP Then Trudy also knows keystream used

to encrypt IP address, since…o … C = destination IP address keystream

Then Trudy can replace C with…o … C = Trudy’s IP address keystream

And change the CRC so no error detected!o Then what happens??

Moral: Big problem when integrity fails Part 3 Protocols 147

WEP Key Recall WEP uses a long-term secret key:

K RC4 is a stream cipher, so each packet

must be encrypted using a different keyo Initialization Vector (IV) sent with packet

o Sent in the clear, that is, IV is not secret

o Note: IV similar to “MI” in WWII ciphers

Actual RC4 key for packet is (IV,K)o That is, IV is pre-pended to long-term key

K Part 3 Protocols 148

WEP Encryption

KIV = (IV,K)o That is, RC4 key is K with 3-byte IV pre-

pended

Note that the IV is known to Trudy Part 3 Protocols 149

Alice, K Bob, K

IV, E(packet,KIV)

WEP IV Issues WEP uses 24-bit (3 byte) IV

o Each packet gets a new IVo Key: IV pre-pended to long-term key, K

Long term key K seldom changes If long-term key and IV are same,

then same keystream is usedo This is bad, bad, really really bad! o Why?


WEP IV Issues Assume 1500 byte packets, 11 Mbps

link Suppose IVs generated in sequence

o Since 1500 8/(11 106) 224 = 18,000 seconds…

o …an IV must repeat in about 5 hours

Suppose IVs generated at randomo By birthday problem, some IV repeats in

seconds

Again, repeated IV (with same K) is bad! Part 3 Protocols 151

Another Active Attack Suppose Trudy can insert traffic and

observe corresponding ciphertexto Then she knows the keystream for some IV

o She can decrypt any packet(s) that uses that IV

If Trudy does this many times, she can then decrypt data for lots of IVso Remember, IV is sent in the clear

Is such an attack feasible? Part 3 Protocols 152

Cryptanalytic Attack WEP data encrypted using RC4

o Packet key is IV and long-term key Ko 3-byte IV is pre-pended to Ko Packet key is (IV,K)

Recall IV is sent in the clear (not secret)o New IV sent with every packeto Long-term key K seldom changes (maybe

never)

So Trudy always knows IVs and ciphertexto Trudy wants to find the key K Part 3 Protocols

153

Cryptanalytic Attack 3-byte IV pre-pended to key Denote the RC4 key bytes…

o …as K0,K1,K2,K3,K4,K5, …o Where IV = (K0,K1,K2) , which Trudy knowso Trudy wants to find K = (K3,K4,K5, …)

Given enough IVs, Trudy can find key Ko Regardless of the length of the key!o Provided Trudy knows first keystream byteo Known plaintext attack (1st byte of each

packet)o Prevent by discarding first 256 keystream

bytes Part 3 Protocols 154

WEP Conclusions Many attacks are practical Attacks have been used to recover keys

and break real WEP traffic How to prevent WEP attacks?

o Don’t use WEPo Good alternatives: WPA, WPA2, etc.

How to make WEP a little better?o Restrict MAC addresses, don’t broadcast ID,

…



GSM (In)Security


Cell Phones First generation cell phones

o Brick-sized, analog, few standardso Little or no securityo Susceptible to cloning

Second generation cell phones: GSMo Began in 1982 as “Groupe Speciale Mobile”o Now, Global System for Mobile

Communications Third generation?

o 3rd Generation Partnership Project (3GPP)


GSM System Overview

Mobile

HomeNetwork

“land line”

air interface

BaseStation

BaseStation

Controller

PSTNInternet

etc.Visited Network

VLR

HLR

AuC


GSM System Components

Mobile phoneo Contains SIM (Subscriber

Identity Module)

SIM is the security moduleo IMSI (International Mobile

Subscriber ID)

o User key: Ki (128 bits)o Tamper resistant (smart card)o PIN activated (usually not

used)

SIM


GSM System Components Visited network network where

mobile is currently locatedo Base station one “cell”o Base station controller manages many cellso VLR (Visitor Location Register) info on all

visiting mobiles currently in the network

Home network “home” of the mobileo HLR (Home Location Register) keeps track of

most recent location of mobile

o AuC (Authentication Center) has IMSI and Ki


GSM Security Goals Primary design goals

o Make GSM as secure as ordinary telephone

o Prevent phone cloning Not designed to resist an active attacks

o At the time this seemed infeasibleo Today such an attacks are feasible…

Designers considered biggest threats to beo Insecure billingo Corruptiono Other low-tech attacks


GSM Security Features Anonymity

o Intercepted traffic does not identify usero Not so important to phone company

Authenticationo Necessary for proper billingo Very, very important to phone company!

Confidentialityo Confidentiality of calls over the air interfaceo Not important to phone companyo May be important for marketing


GSM: Anonymity IMSI used to initially identify caller Then TMSI (Temporary Mobile

Subscriber ID) usedo TMSI changed frequently

o TMSI’s encrypted when sent

Not a strong form of anonymity But probably sufficient for most uses


GSM: Authentication Caller is authenticated to base station Authentication is not mutual Authentication via challenge-response

o Home network generates RAND and computes XRES = A3(RAND, Ki) where A3 is a hash

o Then (RAND,XRES) sent to base stationo Base station sends challenge RAND to

mobileo Mobile’s response is SRES = A3(RAND, Ki)o Base station verifies SRES = XRES

Note: Ki never leaves home network!


GSM: Confidentiality Data encrypted with stream cipher Error rate estimated at about 1/1000

o Error rate is high for a block cipher Encryption key Kc

o Home network computes Kc = A8(RAND, Ki) where A8 is a hash

o Then Kc sent to base station with (RAND,XRES)

o Mobile computes Kc = A8(RAND, Ki)o Keystream generated from A5(Kc)

Note: Ki never leaves home network!


GSM Security

SRES and Kc must be uncorrelatedo Even though both are derived from RAND and Ki

Must not be possible to deduce Ki from known RAND/SRES pairs (known plaintext attack)

Must not be possible to deduce Ki from chosen RAND/SRES pairs (chosen plaintext attack)o With possession of SIM, attacker can choose RAND’s

Mobile Base Station

4. RAND

5. SRES

6. Encrypt with Kc

1. IMSI

HomeNetwork

3. (RAND,XRES,Kc)

2. IMSI


GSM Insecurity (1) Hash used for A3/A8 is COMP128

o Broken by 160,000 chosen plaintextso With SIM, can get Ki in 2 to 10 hours

Encryption between mobile and base station but no encryption from base station to base station controllero Often transmitted over microwave link

Encryption algorithm A5/1o Broken with 2 seconds of known

plaintext

BaseStation

BaseStation

Controller

VLR


GSM Insecurity (2) Attacks on SIM card

o Optical Fault Induction could attack SIM with a flashbulb to recover Ki

o Partitioning Attacks using timing and power consumption, could recover Ki with only 8 adaptively chosen “plaintexts”

With possession of SIM, attacker could recover Ki in seconds


GSM Insecurity (3) Fake base station exploits two flaws

o Encryption not automatico Base station not authenticated

Mobile Base Station

RAND

SRES

Fake Base Station

Noencryption

Call to

destination

Note: GSM bill goes to fake base station!


GSM Insecurity (4) Denial of service is possible

o Jamming (always an issue in wireless)

Can replay triple: (RAND,XRES,Kc)o One compromised triple gives attacker

a key Kc that is valid forevero No replay protection here


GSM Conclusion Did GSM achieve its goals?

o Eliminate cloning? Yes, as a practical matter

o Make air interface as secure as PSTN? Perhaps…

But design goals were clearly too limited GSM insecurities weak crypto, SIM

issues, fake base station, replay, etc. PSTN insecurities tapping, active attack,

passive attack (e.g., cordless phones), etc.

GSM a (modest) security success?


3GPP: 3rd Generation Partnership Project

3G security built on GSM (in)security 3G fixed known GSM security problems

o Mutual authenticationo Integrity-protect signaling (such as “start

encryption” command)o Keys (encryption/integrity) cannot be reusedo Triples cannot be replayedo Strong encryption algorithm (KASUMI)o Encryption extended to base station

controller


Protocols Summary Generic authentication protocols

o Protocols are subtle! SSH SSL IPSec Kerberos Wireless: GSM and WEP


Coming Attractions…

Software and securityo Software flaws buffer overflow, etc.o Malware viruses, worms, etc.o Software reverse engineeringo Digital rights managemento OS and security/NGSCB

Part 3 Protocols 1 Part III: Protocols Part 3 Protocols 2 Protocol Human protocols the rules...

Documents

Transcript of Part 3 Protocols 1 Part III: Protocols Part 3 Protocols 2 Protocol Human protocols the rules...