CMPT 471 Networking II

1. CMPT 471Networking II Authentication and Encryption 1

2. Network Security • When is a network or host secure: • System and software behave as expected • Only authorized use is occurring • Data and information are stored safely (including backups) and accessible only to those who have valid permission to see it • Applications available only to authorized users • Breach of security is not always malicious, It can be caused by ignorance of users, or accident just as easily.

3. Basics to Security • Keeping your network or host secure is not all a matter of firewalls and encryption and fancy security programs • In an organization computer security must be part of a larger information security policy • To keep information secure physical backups and printouts, disks, and other manners of transmitting the information must also be managed.

4. Basics to Security • Even something a simple as passwords for access control takes some thought • Users want something easy to remember, and don’t want to change passwords regularly • Assuring that common words and names are not used as passwords and that passwords must be changed regularly is important to sustained security

5. Aspects of a security policy • Privacy/Confidentiality: protection from unauthorized access to data • Data Integrity: data must be protected from unauthorized modification or deletion • Data Availability: data must be available and protected from denial or degradation of access (denial of service attacks) • Authentication: system must allow communicating parties to validate each others identities

6. Aspects of a security policy • Consistency: system must behave as expected, information should reside in a defined place. Changes should be well publicized before they occur • Access Control / Authorization: The system administrator and to a lesser extent the user should be able to regulate access to data and programs • Accountability: You should record activity or each users so you can determine when and why a problem / change occurs and be able to undo it

7. How much security • It is clear that implementing these aspects of security has a price in overhead • As the level of security increases the overhead or cost increases. • The individual aspects also have trade offs • Increased confidentiality control and audit will decrease availability • If data is not strictly confidential, recovery may be preferable to increased security • Are you annoyed by “do you really want to do this” messages

8. Network security • The internet is a primary source of security breaches. • Security can be compromised inside your own network too. • The only 100% solution is isolation, in most cases this is not efficient or practical • If you are administering a large network limiting access to the internet may or may not be practical • As the internet an connectivity for work at home become more a part of business connectivity it becomes less practical to isolate users from a valuable tool

9. Authentication, encryption • Authentication protects the integrity of the message by ensuring that the source of the data is valid (permitted) and that the data has not been altered in transit • Encryption provides a mechanism to hide the contents of the message from all network users except the sender and receiver of the information. • Together authentication and encryption can provide a secure communication channel

10. Why encrypt a channel? (1) • Any message sent on the internet, or any wired or wireless network (with the possible exception of optical fibre) can easily be eavesdropped. • We have done this for the network traffic in the network lab using ethereal and tcpdump • When we collect packet using these tools we can easily read the entire contents of the packets. • Encryption allows us to ‘scramble’ or ‘code’ the contents of the packet so it cannot be directly read. It needs a key to decipher it into readable form. Only the sender and receiver know that key

11. Why encrypt a channel? (2) • However, we cannot encrypt the entire IP header or the packets could not be delivered so some information will still need to be unencrypted and be available to used in IP forwarding • It is harder for an outsider to break the encryption if they cannot insert packets into the flow of data (eliciting expected responses)

12. Why Authenticate a Channel? (1) • We have seen that we can write an application to build and send packets • What if a destination X will not accept packets from our IP (our lP has previously spammed them!!) but will happily accept packets from Y • We can intercept packets traveling to X from Y and then build packets that look like they come from Y and insert our data into the flow to X.

13. Why Authenticate a Channel? (2) • Now imagine that instead of being the one sending the unwanted packets we are the one receiving them. • We need to authenticate, determine that the packets are really coming from our trusted IP (Y) and not from someone masquerading as the trusted IP (Y) (our host in the previous scenario

14. Necessary components • Both authentication and encryption are based on algorithms that require the end users to process the contents of the packets using a key known only to the sender and/or the receiver • This means that a third party, who does not have the key, will not be able to • Decrypt the packets encrypted contents to see what is in the packet • Make undetected changes to an authenticated packet, or make a packet appear to come from the authenticated sender.

15. IPsec • IPsec is used to add authentication and encryption to the existing IPv4 protocol • Rather than redefining the IP header IPsec uses • an authentication header that is inserted between the IP header and the contents of the IP packet to enable authentication only (transport mode) AND / OR • An encapsulating security payload header inserted between the IP header and the payload of the IP packet to enable authentication and encryption (transport mode) OR • One (or rarely both) of the above headers and tunneling.

16. IPsec usage • Host to host • May use transport mode • May use tunnel mode • Security Gateway to Security Gateway • Must use tunneling • Host to/from security gateway • For traffic destined to security gateway (for example SNMP message) the gateway is operating as a host and transport mode may be used • Otherwise, if the gateway is operating as a gateway tunneling mode must be used

17. IPv4 Authentication (transport mode) • IPv4 packet: no authentication • IPv4 packet: IPsec authentication IPv4 header TCP header TCP data Partially authenticated authenticated IPv4 header Authentication header TCP header TCP data

18. IPv4 Authentication (tunnel mode) • IPv4 packet: No Authentication • IPv4 packet: Tunnel mode Authentication IPv4 header TCP header TCP data IPv4 tunnel header Authentication header IPv4 header TCP header TCP data authenticated Partially authenticated

19. IPv4 Protocol Header Protocol will have a value of 51, indicating that the next information will be an IPsec authentication header Comer 2000: fig 7.3

20. Authentication header 0 16 32 Next Header Payload Length Reserved Security Parameter Index Sequence Number Authentication Data

21. Authentication header fields • Next Header:The Next header field in the authentication header contains the protocol in the message (TCP, UDP, ICMP … the value that would otherwise have been in the protocol field of the IPv4 header) • Sequence number:contains a unique packet number for each packet sent. Starts at zero when a authentication method is agreed upon and a security association (SA) is established. Used to prevent replay (denial of service) attacks.

22. Authentication header fields • Authentication Data:varies according to the authentication algorithm used. Most common algorithms are DESCBC (cipher Block Chaining mode of the Data Encryption Standard, default for IPv6), MD5 (Message Digest No. 5) and SHA1 (Secure Hash algorithm 1) • Payload Length:length in 32 bit words of the Sequence number and authentication data fields.

23. Authentication header fields • Security parameters index:One of the three parameters used to uniquely define a security association (SA). Used to identify the appropriate SA in the security association database (SAD)

24. Security Associations (1) • An SA describes one simplex connection. • If you are using both AH and ESP you need one SA for each. • For two way communication you need one SA for each direction • Three parameters used to uniquely define a security association (SA). • destination address • security protocol (AH or ESP) • Security parameters index (SPI)

25. Security Association (2) • SAs are stored in a database The SAD (Security Associations Database) also includes the following information: • Mode of communication (transport or tunnel) • Sequence Number Counter • Anti-Replay Window: to determine whether an inbound AH or ESP packet is a replay. • AH Authentication algorithm type, keys, etc. OR ESP Encryption algorithm and / or authentication, algorithm types, keys etc. • Lifetime of this Security Association

26. IPv6 packet Structure Hop by Hop header Destination Options header Routing header Fragment header IPv6 header Authentication header Encapsulating Security header Destination Options header Transport header DATA

27. Building authenticated packets • An Authentication header is added to the payload of the IP packet • The Authentication data in the header is set to 0 • The IP header is added to the front of the packet • Mutable fields in the IP header are set to 0 (see following slides)

28. Building authenticated packets • The IP header, the Authentication header and payload are hashed (and possibly encrypted (signed) as well) to create authentication data • Authentication data are put into the authentication header • Fields set to zero for calculation of the Authentication data are set back the their correct values (the fields are not actually zeroed and reset, the algorithm used just treats them as zero)

29. Authentication and IP header • The authentication data in the authentication header is determined using the IP header the authentication header and the data • The values in immutable or mutable and predictable fields in the IP header are used in the calculation of the authentication data. • The values in mutable fields in the IP header are set to zero for the purpose of calculating the authentication data.

30. Authentication and IP header • Immutable • Version • Internet Header Length • Total Length • Identification Protocol (This should be the value for AH.) • Source Address • Destination Address • Mutable but predictable with loose or strict source routing IPv4 or with routing header IPv6

31. Authentication and IP header • Mutable (zeroed prior to ICV calculation) IPv4 • Header Checksum TOS -- This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. • Fragment Offset -- Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable).

32. Authentication and IP header • Mutable (zeroed prior to ICV calculation) IPv4 • TTL -- This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender. • Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. • Header Checksum -- This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender. • Mutable (IPv6) Class, Flow label, Hop limit

33. IPsec and fragmentation • Transport mode • A fragment will not be processed to add a transport mode AH or ESP header • A packet that has been built including a AH and/or ESP header can later be fragmented. Such a packet must be reassembled before IPsec processing at the destination can begin • Tunnel mode • AH and / or ESP can be applied to any IP packet, that packet may contain a fragment or a non fragmented IP packet.

34. Encapsulating security header • Required by IPv6 to be the last optional header, (other than destination options which are only important at the destination) otherwise following option headers would be unreadable because they were encrypted. • Retrofitted to IPv4, must follow the IPv4 header so that header is not encrypted. • The next header is payload type (next higher level protocol) for both IPv4 and IPv6 • Padding present for compatibility with encryption algorithms, alignment of authorization data on a 4 byte boundary, or the disguise contents of packets • Authentication is for encapsulating security protocol header, use an authentication header for general authentication

35. ESP header/payload for IPv6 SECURITY PARAMETER INDEX (SPI) SEQUENCE NUMBER encrypted INITIALIZATION VECTOR DATA PADDING (0-255 octets) PAD LENGTH NEXT HEADER AUTHENTICATION DATA (Variable Length)

36. ESP header and trailer for IPv4 • ESP Header • ESP Trailer SECURITY PARAMETER INDEX (SPI) SEQUENCE NUMBER PADDING (0-255 octets) PAD LENGTH NEXT HEADER AUTHENTICATION DATA (Variable Length)

37. Security header fields • Security Parameter Index: (SPI) • One of the three parameters used to define a security association (SA). The other two are destination address and security protocol (AH or ESP). • Sequence Number: • This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). • The sender's counter (sequence number) is initialized to 0 when an SA is established. The sequence number is incremented for each successive packet sent. If the sequence number has cycled a new SA must be established.

38. Security header fields • Sequence Number: (cont) • The sender's counter (sequence number) is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field for each packet sent. Thus the first packet sent using a given SA will have a Sequence Number of 1. The sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. If the sequence number has cycled a new SA must be established.

39. Security trailer fields • Padding: when is it needed? • To insure that the Payload Data, Pad Length and Next Header fields, as well as the Padding to be a multiple of some number of bytes (e. g. the block size of a block cipher). Some encryption algorithms require this condition. • To ensure that the encrypted data terminates on a 4-byte boundary. The Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above,

40. Security trailer fields • Padding: (cont) • to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary. • to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. • Note that the amount of padding is recorded in the ESP trailer and is thus encrypted, therefore someone intercepting the packet cannot determine the amount of padding that has been added • Inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care.

41. Security trailer fields • Pad Length: • indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255 • Next Header: • identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier in IPv4.

42. Security trailer fields • Authentication data: variable-length, contains an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. • The length of the field is specified by the authentication function selected. • The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. • The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.

43. IPsec transport mode IP header TCP header TCP data IP header ESP header TCP header TCP data ESP trailer ESP auth Not encrypted or authenticated encrypted authenticated Included in authentication calculation

44. IPsec tunneling IP header TCP header TCP data New IP header AH ESP header IP header TCP header TCP data ESP trailer ESP auth Not encrypted or authenticated encrypted authenticated Included in authentication calculation

45. IPsec tunneling IP header TCP header TCP data New IP header ESP header IP header TCP header TCP data ESP trailer ESP auth Not encrypted or authenticated encrypted authenticated Included in authentication calculation

46. Encapsulating Security Protocol • Add ESP trailer after payload • For transport mode add ESP header to start of payload • For tunnel mode add ESP header before original IP header

47. Encapsulating Security Protocol • Encrypts the result using the key, encryption algorithm, algorithm mode indicated by the SA • For transport mode Payload Data, Padding, Pad Length, and Next Header • For tunnel mode Payload Data, Padding, Pad Length, and Next Header and original IP header • Create authentication data (ICV) from ESP header payload and trailer, and then add after encrypted IP payload • Add IP header before ESP header, protocol value (next header) should be 50

48. If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV. RFC 2406