1 CMPT 471 Networking II Authentication and Encryption 1 © Janice Regan,

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.

© Janice Regan, 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.

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan, 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)

© Janice Regan, 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.

© Janice Regan, 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

© Janice Regan, 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.

© Janice Regan, 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.

© Janice Regan, 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

© Janice Regan, IPv4 Authentication (transport mode) authenticated Partially authenticated IPv4 header TCP header TCP data IPv4 header TCP header TCP data Authentication header  IPv4 packet: no authentication  IPv4 packet: IPsec authentication

© Janice Regan,  IPv4 packet: No Authentication  IPv4 packet: Tunnel mode Authentication IPv4 Authentication (tunnel mode) authenticated Partially authenticated IPv4 header TCP header TCP data IPv4 header TCP header TCP data Authentication header IPv4 tunnel header

© Janice Regan, 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

© Janice Regan, Authentication header Next Header Payload Length Reserved Security Parameter Index Sequence Number Authentication Data 01632

© Janice Regan, 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.

© Janice Regan, 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.

© Janice Regan, 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)

© Janice Regan, 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)

© Janice Regan, 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

© Janice Regan, IPv6 packet Structure IPv6 header Destination Options header Hop by Hop header Routing header Fragment header DATA Encapsulating Security header Destination Options header Authentication header Transport header

© Janice Regan, 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)

© Janice Regan, 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)

© Janice Regan, 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.

© Janice Regan, 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

© Janice Regan, 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).

© Janice Regan, 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

© Janice Regan, 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.

© Janice Regan, 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

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

© Janice Regan, ESP header and trailer for IPv4  ESP Header  ESP Trailer SEQUENCE NUMBER SECURITY PARAMETER INDEX (SPI) AUTHENTICATION DATA (Variable Length) PADDING (0-255 octets) PAD LENGTH NEXT HEADER

© Janice Regan, 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.

© Janice Regan, 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.

© Janice Regan, 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,

© Janice Regan, 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.

© Janice Regan, Security trailer fields  Pad Length:  indicates the number of pad bytes immediately preceding it. The range of valid values is  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.

© Janice Regan, 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.

© Janice Regan, IPsec transport mode IP header TCP headerTCP data TCP header TCP data IP header ESP header ESP trailer ESP auth encrypted authenticated Included in authentication calculation Not encrypted or authenticated

© Janice Regan, IPsec tunneling IP headerTCP headerTCP data New IP header TCP header TCP data IP header AHESP header ESP trailer ESP auth encrypted authenticated Included in authentication calculation Not encrypted or authenticated

© Janice Regan, IPsec tunneling IP headerTCP headerTCP data New IP header TCP header TCP data IP header ESP header ESP trailer ESP auth encrypted authenticated Included in authentication calculation Not encrypted or authenticated

© Janice Regan, 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

© Janice Regan, 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

© Janice Regan,  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