Cisco Live /11/2016

Transcription

1 1

2 Cisco Live

3 3

4 4

5 Connection Hijacking - prevents the authentication happening and then an attacker jumping in during the keyexchange messaging 5

6 6

7 7

8 8

9 9

10 Main Mode - (spoofing attack) DH performed after 3 rd packet Aggressive Mode - PSK Can be retrieved by an offline brute-force attack. Similar to a salted password file. - Trivial to DOS - DH done after receiving 1 st packet 10

11 11

12 CKY-I = md5{(src_ip, dest_ip), Random Number} CKY-R = md5{(src_ip, dest_ip), Random Number} 12

13 13

14 Nonce values prevent crendential replay attacks 14

15 15

16 16

17 17

18 18

19 19

20 Crypto validate previous messages prevents session hijack 20

21 21

22 22

23 23

24 Leads to an offline brute force attack because AUTH_R (in AM2) is: For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b Nr_b) HASH_R = prf(skeyid, g^xr g^xi CKY-R CKY-I SAi_b IDir_b ) Where g^xr and g^xi are the public portions of the DH exchange. All the values except for pre-shared-key are available in cleartext. 24

25 DOI Domain of Interpretation 25

26 How to be encapsulated (ESP/AH, Tunnel/Transport Mode) How to be encrypted (DES, 3DES, AES, AES-GCM) How to provide integrity (HMAC-[MD5,SHA1,SHA2],AES-GMAC) If new keying material needs to be generated (PFS) 26

27 27

28 28

29 29

30 30

31 31

32 Certificates are meant to make authentication scalable but need to configure which certificates to use for each connection. We need a better way to figure out which certificate to use 32

33 AH can t work through NAT since IP Addr is included in integrity check ESP can work through 1:1 NAT since only IP Address Header is changed ESP doesn t have ports can t go through PAT 33

34 34

35 35

36 36

37 37

38 38

39 Problem 1: each side needs to know which PKI infrastructures (CAs) are trusted by the peer in order to select which local certificate to use. Could be explicitly configured but reduces the potential to scale (due to configuration overhead). Solution 1: RFC Provide a list of subject names of trusted CAs to peer in the IKE exchange in the message prior to the AUTH payload. 39

40 40

41 SKEYID = prf(pre-shared-key, Initiator Nonce Responder Nonce) However the identities are shared after encryption has been established in MM5 and MM6. where identities are exchanged prior to key derivation. 41

42 if we haven t heard any IKE or IPsec traffic from peer. Periodic or on-demand 42

43 43

44 Unfortunately multiple RFCs have been defined to add additional features and clarifications to IKEv2. So that original point is lost. More Secure - to protect all IKEv2 packets. IKEv1 did integrity/auth check differently for each type of message. Built-in config exchange. Too many options in IKEv1, too complex. Implementations only supported subset of options. RFCs for IKEv1 confusing and too many different choices (ISAKMP defined 4 different phase-1 modes!) *Using only public key cryptography (Diffie-Hellman) means exchange is not Quantum Computer Resistant. There is an RFC draft to 44

45 In negotiation it is a selection of options not exact combinations more likely to have successful policy match smaller packet Keys are generated from Nonce, and DH values (no PSK). We reuse NAT-T, DH, and Nonce concepts 45

46 46

47 By reducing the number of exchanges, expensive cryptographic work is done after receiving 1 st packet Generate a cheap stateless cookie from secret + values from request. 47

48 48

49 49

50 Gives great flexibility to upgrade security/interoperability as EAP method must only match between the AAA server and the client 50

51 51

52 IKEv1 uses encryption to encapsulate each message but uses a HASH payload within the encrypted payload to provide authentication. The HASH payload construction is different for each message type. Wider set of rules for security analysis and potential attack surface Certificate requests are now sha-1 hashes of the public key of each CA rather than a list of the subject names - This provides the same functionality but hides the names of the CAs from any eavesdroppers. Reduces reconnaissance attacks. AEAD is Authenticated Encryption and Associated Data. This is encryption that includes integrity checks like AES- GCM. IKEv1 allowed group name/group password to build a secure phase-1. Then over that XAUTH was used to differentiate end users. EAP does this in the phase-1 establishment so no need to securely pre-deploy a group name/key. In IKEv1 aggressive mode responder must provide and prove identity first. Reconnaissance attack. AUTH payload can be offline brute-forced to recover crendentials. Suite-B has removed all IKEv1 references! Technically IKEv2 is not Quantum Computer Resistant because the session keys are based on the public key computation and do not include a secret value. RFC draft (draft-fluhrer-qr-ikev2-01) to allow for PSK to be included in key derviation. 52

53 53

54 Certificates that are revoked are a problem (or psk key change) since when you are in you are in forever 54

55 Exponential back-off. But when manually cleared via the cli IOS will delete sooner. Luckily this is mitigated if DPDs are used to detect dead peer sooner 55

56 With IOS/FlexVPN the routes are installed into RIB pointing out the P2P Virtual-Access or Tunnel interface. Allows to scale 56

57 Carrier Grade NAT typically block fragments IKEv1 vulnerable to re-assembly buffer attacks frags are unauthenticated IKEv2 standard protection (anti-replay) protect buffers. 57

58 58

59 59

60 track the protocol flow by looking that the source and destination IP/Port. Track the specific Security Association by the Initiator and Responder SPI Track the exchange that is happening (IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, NOTIFICATION) Track the exchange if it is a request or response. 60

61 61

62 Incompatible but can run side-by-side. Version number in IKE packet allows to demux the messages to the different services. 62

63 63

64 64

65 65

66 66

67 67

68 68

69 Cisco Live