Protocols

1

Complexities of email • text-based • distribution lists – local vs remote explosion

• store-and-forward

2

Possible features. How with secret vs public keys, dist lists? • • • • • • •

Privacy authentication integrity non-repudiation plausible deniability proof of submission proof of delivery 3

Integrity/Authentication • Public key, straightforward • Secret key: various possibilities – – – –

CBC residue computed with shared key. keyed hash with per-user shared secret MD encrypted with the shared secret What about taking a per-message secret S, and doing any of the above using S? 4

Non-repudiation/Plausible Deniability • • • •

Public keys: nonrepudiation easy, PD hard Secret keys: vice versa How to do PD with public keys? Secret key NR: with notary – Alice negotiates with notary to add “seal” to msg, f(SN, msg, “Alice”); SN is secret local to notary – Bob can’t tell if seal OK, but could ask – Or Notary can add second seal for Bob: Note: Bob’s seal better cover Alice’s. Why? 5

Proof of submission/delivery • post office signs MD of message • proves it received it, not that it was delivered • proof of delivery – signed by recipient – requires cooperation of recipient – can’t be sure. false negative, false positive, depending on order 6

Real Time Protocols • • • •

Kerberos, IPsec, SSL Kerberos secret-key based IPsec and SSL, PKI-based IPsec “layer 3”, SSL “layer 4”

7

IPsec vs SSL • IPsec: “Layer 3” security association • Idea: don’t change applications, just OS • vs SSL/SSH: don’t change OS, only change application. They run on top of layer 4 (TCP/UDP)

8

Layer 3 vs layer 4 • layer 3 technically superior • Rogue packet problem – TCP doesn’t participate in crypto, so attacker can inject bogus packet, no way for TCP to recover

• easier to do outboard hardware processing (since with IPsec, each packet independently encrypted) 9

But if don’t change apps • API just says which IP address talking to • So all the fancy PKI, names, etc… No authentication of anything but IP address • What you get (similar to firewalls between) – hides traffic from eavesdroppers – can do packet filtering like firewalls do – if authentication based on IP address, then OK 10

AH / ESP • extra header between layers 3 and 4 (IP and TCP) to give dest enough info to identify “security association” • AH does integrity only - includes source and destination IP addresses • ESP does encryption and integrity protection 11

ESP Encapsulating Security Payload IP Header

Next Header = ‘50’ (ESP)

ESP Header Encrypted Payload Encrypted Padding Pad Len NXT

MIC

TCP = 6 UDP = 17 ESP = 50 IP = 4

Session ID Sequence #

Over ESP Header, Encrypted Payload/Pad/Padlen/NXT 12

AH (Authentication Header) IP Header

Next Header = ‘51’ (AH)

AH Header Next Len

Payload

TCP = 6 UDP = 17 ESP = 50 IP = 4 AH = 51

MBZ

Session ID Sequence # MIC

Over “immutable” fields of IP Header, AH Header, and Payload 13

ESP / AH • Payload may be TCP, UDP, or some other ‘higher layer’ protocol (transport mode) • Payload may be IP datagram (tunnel mode) • Payload may be ESP/AH again (recursive encapsulation) • If it’s important to protect IP header, ESP with tunnel mode will do that 14

Why AH? • AH and ESP designed by different groups. AH designers were IPv6 supporters • AH looks more like IPv6 • AH also protects “immutable” fields in IP header. • Originally, ESP just encryption • Encryption without integrity has flaws 15

Why AH, con’t • Then integrity protection added to ESP. • Excuses for keeping AH – protects IP header (nobody has a credible security reason why, and ESP-tunnel can too. – Makes NAT harder, which pleases IPv6 fans) – with AH, firewalls and routers that want to look at layer 4 info (like ports) know it’s not encrypted. With ESP, can’t tell from packet 16

IPSEC Key Exchange Contenders • Photuris: Signed Diffie Hellman, stateless cookies, optional hiding endpoint ids • SKIP: Diffie-Hellman public keys, so if you know someone’s public key gB, you automatically know a shared secret gAB. Each msg starts with per-msg key S encrypted with gAB • And the winner was... 17

ISAKMP • Internet Security Association and Key Management Protocol • Gift to the IETF from NSA • A “framework”, not a protocol. Complex encodings. Flexible yet constraining. • Two “phases”. Phase 1 expensive, establishes a session key with which to negotiate multiple phase 2 sessions 18

Why Two Phases • We argued for removing this, but people wanted it for: – firewalls creating lots of VPNs for lots of customers…they feel safer if different SAs – different QOS, since might travel at different speeds, sequence numbers get far apart – makes rekeying faster – different SAs with different security properties 19

IKE • Two phases, like ISAKMP • Phase 1 is 8 protocols! – two “modes”: aggressive (3 msgs), and main (6 msgs) – Main does more, like hiding endpoint identifiers

• Phase 2 known as “quick mode” • So 9 protocols (8 for phase 1, + phase 2) 20

IKE Phase 1 Key types • For each of main and aggressive, protocols are defined for each of the following key types: – – – –

pre-shared secret key public signature keys public encryption keys (old crufty way) public encryption keys (new improved method)

21

Of the IKE Variants • The one required variant (main mode, preshared secret keys): nobody uses it – ID transmitted, encrypted with key which is a function of pre-shared key! Can’t decrypt unless you can guess who you’re talking to! – So ID=IP Address. Useless for “road warrier”

• Instead, the most commonly used one is aggressive mode, pre-shared secret keys 22

IKE Problems • • • • •

Terminal complexity Lost ability to do stateless cookies! Full of bugs: replay, DOS, reflection attacks Very inefficient We redesigned it from 9 msgs to 4, keeping all features, fixing all the problems, supporting sig keys and secret keys 23

IKEv1 vs IKEv2 • IKEv1: – 9 msgs (ID hiding) or 6 to set up IPsec SA – 8 different protocols – lots of networking issues

• What we did for IKEv2: – one protocol, 4 messages, ID hiding – cleaned it up and simplified it a lot – wrote the spec in English 24

General idea of IKEv2 Alice

Bob gA mod p, nonceA gB mod p, nonceB

{“Alice”, proof I’m Alice}gAB mod p {“Bob”, proof I’m Bob}gAB mod p

25

Traffic Restrictions • IPsec policy: Traffic between these sets of IP adds, and protocol types, and ports, must have this sort of cryptographic protection • Creating SA, specify “traffic selectors” • IKEv1: Initiator proposes. Responder (if has more restrictive policy) can just say “no” • IKEv2: allowed responder to narrow or say “single pair” 26

Lotus Notes • Some really cool ideas – Adding message to make handshake faster – Best exportability solution ever – Session resumption

27

Kerberos Authentication (Basic) Alice

KDC

Bob

Alice wants Bob {“Bob”, Kab, {“Alice”,Kab}Kb} Ka {“Alice”, Kab}Kb, {timestamp}Kab {timestamp+1}Kab 28

Getting rid of long term secrets • It is dangerous for the workstation to hold Alice’s secret for her entire login session • How can the long-term secret be turned into a session secret?

29

Ticket Granting Tickets • TGT looks just like ticket but encrypted with KDC’s key • WS keeps TGT = {“Alice”,S}Kkdc and S • Kerberos documentation refers to 3 things: – AS (authentication server) – TGS (ticket granting server) – KDC (the box that provides the 2 services)

• should just be “KDC” 30

Kerberos Authentication (with TGT={“Alice”,S}Kkdc) Alice

KDC

Bob

Alice wants Bob, TGT {“Bob”, Kab, {“Alice”,Kab}Kb} S {“Alice”, Kab}Kb, {timestamp}Kab {timestamp+1}Kab 31

Tickets • • • • • •

Alice’s name, instance, realm Alice’s layer 3 (IPv4) address session key KAlice-Bob ticket lifetime, units of 5 minutes (1 byte) time when ticket created Bob’s name, instance 32

Interesting Vulnerability • Cross-realm in Kerberos v4 • Encryption of ticket done with CBC, no IV

33

Replicated KDCs • One master • user secrets individually encrypted with KDC’s secret (shared by all replicas) • Update: create, change, or delete entry entry=(username, key) • Can replication be done without cryptographic protection (since keys are encrypted)? 34

Variants • Authentication with token, or S/KEY • Could client create its own TGT and session key? • What if non-synchronized clocks? • What if no clocks?

35

Kerberos v5 • spec now 133 pages long • specs are not fun to read “AuthorizationData is always used as an OPTIONAL field and should not be empty”

36

Kerberos v5 • Traded “B” bit for ASN.1 – Instead of 4 bytes for address, so only IPv4 – In Kerberos v5: SEQUENCE (2 octets: T=seq, L) { addr-type[0] INTEGER, – T=0, length, (for addr-type) = 2 – T=“integer”, length, value = 3

address[1] OCTET STRING } (4 octets+address) 2+5+8 = 15 bytes instead of 4 37

If ASN.1 guru... • security people don’t tend to think about ASN.1 • Using “IMPLICIT” as in: – addr-type[0] IMPLICIT INTEGER

• reduces overhead by 2 bytes • With “CHOICE”, can be just 2 bytes of overhead per type of address 38

PreAuthentication • Anyone can request a ticket on behalf of Alice, and the response will be encrypted under her password. Dictionary attack. • Kerberos V5 requires an encrypted timestamp on the request – Only an eavesdropper can guess passwords

• Unless get a ticket to a human... 39

Hierarchy of Realms • • • •

“Transited” field lists KDCs Left up to Alice to find path Left up to Bob to decide if he likes the path Could a bad KDC avoid being in the ticket?

40

Public Keys • PKINIT: public keys for users. How would you do this? How was it done? • If chain of certs, checks first is trust anchor, and the others are listed in Transited • How might public keys of servers be used?

41