Chapter 22 Internet Security Protocols and Standards MIME

Chapter 22 Internet Security Protocols and Standards

MIME and S/MIME • Extension to the old RFC 822 specification of an Internet mail format o RFC 822 defines a simple heading with To, From, Subject o Assumes ASCII text format • Provides a number of new header fields that define information about the body of the message S/MIME • Secure/Multipurpose Internet Mail Extension • Security enhancement to the MIME Internet e-mail format o Based on technology from RSA Data Security • Provides the ability to sign and/or encrypt email messages

MIME Content Types S/MIME is defined as a set of additional MIME content types and provides the ability to sign and/or encrypt e-mail messages.

S/MIME Content Types S/MIME same functionality as PGP, that is, it provides: • Enveloped Data, to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient. • Signed Data, to provide authentication. Only a S/MIME enabled mailer can view this message. • Clear-signed Data, to provide authentication for users with S/MIME capabilities, but to retain readability other viewers. • Nesting of signed and encrypted data.

Signed & Clear-Signed Data • Default algorithms used for signing messages are DSS and SHA-1 • RSA public-key encryption algorithm can be used with SHA 1 or the MD 5 message digest algorithm forming signatures • Radix-64 or base 64 mapping is used to map the signature and message into printable ASCII characters • Default algorithms used for encrypting S/MIME messages are 3 DES and EIGamal • Basic tool that permits widespread use of S/MIME is the public-key certificate - S/MIME uses certificates that conform to the international standard X. 509 v 3

S/MIME Functions Enveloped data Signed data Clearsigned data Signed and enveloped data Encrypted content and associated keys Encoded message + signed digest Cleartext message + encoded signed digest Nesting of signed and encrypted entities

Domain. Keys Identified Mail (DKIM) • Specification of cryptographically signing e-mail messages permitting a signing domain to claim responsibility for a message in the mail stream • Has been widely adopted by a range of e-mail providers • Message recipients (or agents acting in their behalf) can verify the signature by querying the signer’s domain directly to retrieve the appropriate public key and thereby can confirm that the message was attested to by a party in possession of the private key for the signing domain • The default signing algorithm is RSA with SHA-256. RSA with SHA-1 also may be used.

Message user agent (MUA): Works on behalf of users. Typically, referred to as a client e-mail program or a local e-mail server. The author MUA formats a message and performs initial submission into the MHS via a MSA. The recipient MUA processes the mail for storage & display to the recipient user. • Mail submission agent (MSA): Accepts the message submitted by an MUA & enforces the policies of the hosting domain. This function may be located together with the MUA or as a separate functional model. Message transfer agent (MTA): Relays mail for 1 application-level hop. It is like a packet switch/router in that its job is to make routing assessments & to move message closer to recipients. An MTA adds trace information to header. SMTP is used between MTAs and between an MTA and an MSA or MDA. • Mail delivery agent (MDA): Transfers the message from the MHS to the MS. Message store (MS): An MUA can employ a long-term MS. An MS can be located on a remote server or on the same machine as the MUA. Typically, an MUA retrieves messages from a remote server using POP (Post Office. Protocol) or IMAP (Internet Message Access Protocol).

We begin with a message generated by a user & transmitted into the MHS to an MSA that is within the user’s administrative domain. An e-mail message is generated by an e-mail client. The content of the message, plus selected headers, is signed by the e-mail provider using the provider’s private key. The signer is associated with a domain, which could be a corporate network, an ISP, or a public e-mail facility such as Gmail. The signed message passes through the Internet via a sequence of MTAs. At the destination, the MDA retrieves the public key for the incoming signature and verifies the signature before passing the message on to the destination e -mail client.

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) • One of the most widely used security services • General-purpose service implemented as a set of protocols that rely on TCP • Subsequently became Internet standard RFC 4346: Transport Layer Security (TLS) Two implementation choices: Provided as part of the underlying protocol suite Embedded in specific packages

TLS Concepts TLS Session • An association between a client and a server • Created by the Handshake Protocol • Define a set of cryptographic security parameters • Used to avoid the expensive negotiation of new security parameters for each connection TLS Connection • A transport (in the OSI layering model definition) that provides a suitable type of service • Peer-to-peer relationships • Transient • Every connection is associated with one session

The SSL Record Protocol provides two services for SSL connections: • Confidentiality: The Handshake Protocol defines a shared secret key that is used for symmetric encryption of SSL payloads. • Message integrity: The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC).

Change Cipher Spec Protocol • One of four TLS specific protocols that use the TLS Record Protocol • Is the simplest • Consists of a single message which consists of a single byte with the value 1 • Sole purpose of this message is to cause pending state to be copied into the current state • Hence updating the cipher suite in use

Alert Protocol Conveys TLS-related alerts to peer entity Alert messages are compressed and encrypted First byte takes the value warning (1) or fatal (2) to convey the severity of the message Each message consists of two bytes: Second byte contains a code that indicates the specific alert If the level is fatal, TSL immediately terminates the connection Other connections on the same session may continue, but no new connections on this session may be established

Handshake Protocol • Most complex part of TLS • Is used before any application data are transmitted • Allows server and client to: Authenticate each other Negotiate encryption and MAC algorithms Negotiate cryptographic keys to be used • Comprises a series of messages exchanged by client and server • Exchange has four phases

Handshake Protocol 4 Phases Phase 1 is initiated by the client, which sends a client_hello message with the following parameters: • Version: Highest SSL version understood by the client. • Random: A 32 -bit timestamp & 28 bytes used during key exchange to prevent replay attacks. • Session ID: A variable nonzero value indicating the client wishes to update the parameters of an existing connection or create a new connection on this session. • Cipher. Suite: List containing combinations of cryptographic algorithms supported by the client, in decreasing order of preference. • Compression method: This is a list of the compression methods the client supports. After sending the client_hello message, the client waits for the server_hello message, which contains the same parameters as the client_hello message. The details of phase 2 depend on the underlying public-key encryption scheme that is used. In some cases, the server passes a certificate to the client, possibly additional key information, and a request for a certificate from the client. The final message in phase 2, and one that is always required, is the server_done message, which is sent by the server to indicate the end of the server hello and associated messages. After sending this message, the server will wait for a client response.

Handshake Protocol 4 Phases In phase 3 , upon receipt of the server_done message, the client should verify that the server provided a valid certificate if required and check that the server_hello parameters are acceptable. If all is satisfactory, the client sends one or more messages back to the server, depending on the underlying public-key scheme. Phase 4 - Client sends a change_cipher_spec message and copies pending Cipher. Spec into current Cipher. Spec. Note that this message is not considered part of the Handshake Protocol but is sent using the Change Cipher Spec Protocol. The client immediately sends the finished message under the new algorithms, keys, and secrets. Finished message verifies that key exchange & authentication successful. In response to these two messages, server sends its change_cipher_spec message, transfers pending to the current Cipher. Spec, & sends its finished message. At this point, the handshake is complete and the client and server may exchange app layer data.

TLS handshake protocol Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated: the client and the server must agree on the version of the TLS protocol, choose the ciphersuite, and verify certificates if necessary. Unfortunately, each of these steps requires new packet roundtrips between the client and the server, which adds startup latency to all TLS connections. We assume the same 28 millisecond 1 -way "light in fiber" delay e. g. New York & London

Heartbeat Protocol • A periodic signal generated by hardware or software to indicate normal operation or to synchronize other parts of a system • Typically used to monitor the availability of a protocol entity • Runs on top of the TLS Record Protocol • Use is established during Phase 1 of the Handshake Protocol • Each peer indicates whether it supports heartbeats • Serves two purposes: o Assures the sender that the recipient is still alive o Generates activity across the connection during idle periods

SSL/TLS Attacks on the Handshake Protocol Attacks on the record and application data protocols Four general categories: Attacks on the PKI Other attacks

Heartbleed • The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the Open. SSL software. • Open. SSL is the most popular open source cryptographic library and TLS implementation used to encrypt traffic on the Internet. • The most notable software using Open. SSL are the open source web servers like Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% at the time. • This compromises the secret keys used to identify service providers & to encrypt traffic, the names & passwords of users & actual content. This allows attackers to eavesdrop on communications, steal data directly from the services & to impersonate services and users. • Open. SSL was patched quickly but OS vendors and appliance vendors, independent software vendors have to adopt the fix and notify their users. • This bug has left large amount of private keys & other secrets exposed on Internet.

The Code Segment The Heartbleed bug is in Open. SSL’s TLS heartbeat implementation. Recall - goal of this heartbeat is to be able to verify that a connection is still open by sending some sort of arbitrary message and expecting a response to it. When a TLS heartbeat is sent, it comes with a couple notable pieces of information: • Some arbitrary payload data. This is intended to be repeated back to the sender so the sender can verify the connection is still alive and the right data is being transmitted through the communication channel. • the length of that data, in bytes (16 bit unsigned int). We’ll call it len_payload.

The Code Segment The Open. SSL implementation is used to do the following: • Allocate a heartbeat response, using len_payload as the intended payload size • memcpy() len_payload bytes from the payload into the response. • Send the heartbeat response (with all len_payload bytes) happily back to the original sender. The problem is that the Open. SSL implementation never bothered to check that len_payload is actually correct, and that the request actually has that many bytes of payload. So, a malicious person could send a heartbeat request indicating a payload length of up to 2^16 (65536), but actually send a shorter payload. What happens in this case is that memcpy ends up copying beyond the bounds of the payload into the response, giving up to 64 k of Open. SSL’s memory contents to an attacker.

HTTPS (HTTP over SSL) • Combination of HTTP and SSL to implement secure communication between a Web browser and a Web server • Built into all modern Web browsers o URL addresses begin with https: // • Closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity on the remote side, which will involve closing the underlying TCP connection • The principal difference seen by a user of a Web browser is that URL (uniform resource locator) addresses begin with https: // rather than http: //. A normal HTTP connection uses port 80. If HTTPS is specified, port 443 is used, which invokes SSL. • When HTTPS is used, the following elements of the communication are encrypted: (1) URL of the requested document (2) Contents of the document (3) Contents of browser forms (filled in by browser user) (4) Cookies sent from browser to server and from server to browser (5) Contents of HTTP header

Chain of Trust/Certificate Authorities Authentication is an integral part of establishing every TLS connection. After all, it is possible to carry out a conversation over an encrypted tunnel with any peer, including an attacker, & unless we can be sure that the computer we are speaking to is the one we trust, then all encryption work could be for nothing. • So whom does your browser trust, and whom do you trust when you use the browser? … There at least three answers to this question: • Manually specified certificates - Every browser and operating system provides a mechanism for you to manually import any certificate you trust. How you obtain the certificate and verify its integrity is completely up to you. • Certificate authorities - A certificate authority (CA) is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate. • The browser and the operating system - Every operating system and most browsers ship with a list of well-known certificate authorities. Thus, you also trust the vendors of this software to provide and maintain a list of trusted parties.

Chain of Trust/Certificate Authorities • • • In practice, it would be impractical to store and manually verify each and every key for every website Hence, the most common solution is to use certificate authorities (CAs) to do this job for us: the browser specifies which CAs to trust (root CAs), and the burden is then on the CAs to verify each site they sign, and to audit and verify that these certificates are not misused or compromised. If the security of any site with the CA’s certificate is breached, then it is also the responsibility of that CA to revoke the compromised certificate.

Chain of Trust/Certificate Authorities A browser allows you to inspect the chain of trust of your secure connection, usually accessible by clicking on the lock icon beside the URL. • • • igvita. com certificate is signed by Start. Com Class 1 Primary Intermediate Server certificate is signed by the Start. Com Certification Authority is a recognized root certificate authority. The "trust anchor" for the entire chain is the root CA, which in the case just shown, is the Start. Com Certification Authority. Every browser ships with a pre-initialized list of trusted certificate authorities ("roots"), and in this case, the browser trusts and is able to verify the Start. Com root certificate. Hence, through a transitive chain of trust in the browser, the browser vendor, and the Start. Com certificate authority, we extend the trust to our destination site.

Certificate Revocation • Occasionally the issuer of a certificate will need to revoke or invalidate the certificate due to a number of possible reasons: the private key of the certificate has been compromised, the certificate authority itself has been compromised, or due to a variety of more benign reasons such as a superseding certificate, change in affiliation, and so on. To address this, the certificates themselves contain instructions on how to check if they have been revoked. • Hence, to ensure that the chain of trust is not compromised, each peer can check the status of each certificate by following the embedded instructions, along with the signatures, as it walks up the certificate chain.

Online Certificate Status Protocol (OCSP) To address some of the limitations of the CRL mechanism, the Online Certificate Status Protocol (OCSP) was introduced by RFC 2560, which provides a mechanism to perform a real-time check for status of the certificate. Unlike the CRL, which contains all the revoked serial numbers, OCSP allows the verifier to query the certificate database directly for just the serial number in question while validating the certificate chain. As a result, the OCSP mechanism should consume much less bandwidth and is able to provide real-time validation. However, no mechanism is perfect! The requirement to perform real-time OCSP queries creates several problems of its own: • • The CA must be able to handle the load of the real-time queries. The CA must ensure that the service is up and globally available at all times. The client must block on OCSP requests before proceeding with navigation. Real-time OCSP requests may impair the client’s privacy because the CA knows which sites the client is visiting. In practice, CRL and OCSP mechanisms are complementary, and most certificates will provide instructions and endpoints for both.

IP Security (IPsec) • Various application security mechanisms o S/MIME, Kerberos, SSL/HTTPS • Security concerns cross protocol layers • Would like security implemented by the network for all applications • Authentication and encryption security features included in next-generation IPv 6 • Also usable in existing IPv 4

IPsec Authentication Confidentiality Key management • Assures that a received packet was, in fact, transmitted by the party identified as the source in the packet header and that the packet has not been altered in transit • Enables communicating nodes to encrypt messages to prevent eavesdropping by third parties • Concerned with the secure exchange of keys • Provided by the Internet exchange standard IKEv 2

Applications of IPsec The principal feature of IPsec that enables it to support these varied applications is that it can encrypt and/or authenticate all traffic at the IP level. Thus, all distributed applications, including remote logon, client/server, e-mail, file transfer, Web access, and so on, can be secured Secure branch office connectivity over the Internet Secure remote access over the Internet Establishing extranet and intranet connectivity with partners Enhancing electronic commerce security

Benefits of IPsec • When implemented in a firewall or router, it provides strong security to all traffic crossing the perimeter • In a firewall it is resistant to bypass • Below transport layer, hence transparent to applications • Can be transparent to end users • Can provide security for individual users • Secures routing architecture – not forged e. g. Routing protocols such as Open Shortest Path First (OSPF) should be run on top of security associations between routers that are defined by IPsec.

Provides two main functions: The Scope of IPsec • A combined authentication/encry ption function called Encapsulating Security Payload (ESP) • Key exchange function VPNs want both authentication and encryption Also an authenticationonly function, implemented using an Authentication Header (AH) • Because message authentication is provided by ESP, the use of AH is included in IPsecv 3 for backward compatibility but should not be used in new applications Specification is quite complex • Numerous RFC’s 2401/4302/ 4303/4306

Security Associations • A one-way relationship between sender and receiver that affords security for traffic flow o If a peer relationship is needed for two-way secure exchange then two security associations are required • Is uniquely identified by the Destination Address in the IPv 4 or IPv 6 header and the SPI in the enclosed extension header (AH or ESP) Defined by 3 parameters: Security Parameter Index (SPI) IP Destination Address Protocol Identifier

Transport and Tunnel Modes Transport Mode Tunnel Mode • • Extends to the payload of an IP packet Provides protection to the entire IP packet • • Typically used for end-to-end communication between two hosts The entire original packet travels through a tunnel from one point of an IP network to another • Used when one or both ends of a security association are a security gateway • A number of hosts on networks behind firewalls may engage in secure communications without implementing IPsec • ESP encrypts and optionally authenticates the IP payload but not the IP header

IPv 6 Sub netting & CIDR strategies have helped to slow down the process of running out of IP addresses, however with the continuing growth in the number of Internet hosts/users, the IP in its current version (IPV 4) won’t be able to meet the high demands and interest in the Internet. IETF defined a version for IP (IPv 6) with other advantages over IPv 4. • IPv 6 Important features : Wish-list • Faster Packet Processing • Enhanced QOS • Improved Security • Greater protocol Flexibility • Dual-Stack approach

The IPv 6 Header 40 Octets, 8 fields 0 4 Version 12 Class 16 24 31 Flow Label Payload Length Next Header 128 bit Source Address 128 bit Destination Address Hop Limit

The IPv 4 Header 20 octets + options : 13 fields, including 3 flag bits 0 4 Ver 8 IHL 16 Service Type Identifier Time to Live 24 Total Length Flags Protocol Fragment Offset Header Checksum 32 bit Source Address 32 bit Destination Address Options and Padding Shaded fields are absent from IPv 6 header 31

IPv 6 The new features introduced with the IPv 6 protocol are summarised as: 1. A new header format 2. A much larger address space (128 -bit in IPv 6, compared to the 32 -bit address space in IPv 4) 3. An efficient and hierarchical addressing and routing infrastructure 4. Both stateless and stateful address configuration IPv 6 Security v 1. 16 5. IP Security 6. Better Quality of Service (Qo. S) support 7. A new protocol for neighbouring node interaction 8. Extensibility These enhancements in IPv 6 provide better security in certain areas, but some of these areas are still open to exploitation by attackers.

Massive Size of the IP Address Space Makes Port Scanning Harder When they start, attackers usually employ port scanning as a reconnaissance technique to gather as much information as possible. Estimates are the entire IPv 4 based Internet can be scanned in about 10 hours with enough bandwidth, given IPv 4 addresses re only 32 bits. IPv 6 dramatically increases limit by expanding the # of bits in address fields to 128 bits. By itself, such a massive address space creates a significant barrier for attackers wanting to conduct port scanning. However, it should be noted that the port scanning reconnaissance technique used in IPv 6 is basically the same as in IPv 4, apart from larger IP address space. Therefore, best practices used with IPv 4, such as filtering internal-use IPv 6 addresses in border routers, & filtering un-used services at firewall, should be continued in IPv 6 networks.

Replacing ARP by Neighbour Discovery Protocol In IPv 4, a layer two (L 2) address is not statically bound to a layer three (L 3) IP address. Therefore, it can run on top of any L 2 media without making significant change to the protocol. Connection between L 2 & L 3 addresses is established with a protocol named Address Resolution Protocol (ARP), which establishes mapping between L 2 & L 3 addresses on local network segment. ARP has its own security vulnerabilities (such as ARP Spoofing). In IPv 6, there is no need for ARP as the interface identifier portion of an L 3 IPv 6 address is directly derived from device-specific L 2 MAC Address. The L 3 IPv 6 address, together with its locally derived interface ID portion, is then used at the global level across the whole IPv 6 network. As a result, the security issues related to ARP no longer apply to IPv 6. A new protocol - Neighbour Discovery (ND) Protocol is a replacement to ARP.

Concerns, Potential Threats & Measures The IEEE EUI-64 address 12 represents a new standard for network interface addressing in IPv 6. Physical address of the network interface (MAC address) is an input to the algorithm that generates EUI-64 address for network interfaces. With the capability of auto-configuration, a global IPv 6 address for the interface can be generated by combining the network identifier with the EUI 64 address. By using a EUI-64 address, an attacker could potentially reveal the make and model of a remote machine, and use the information to target attacks. To mitigate the risk, non-predictable addresses should be used by making use of cryptographic algorithm (e. g. Cryptographically Generated Address) or assigning addresses with DHCPv 6.

Common Attacks In Both IPv 4 & IPv 6 cannot solve all security problems. It cannot prevent attacks on layers above network layer. Possible attacks that IPv 6 cannot address include: 1. Application layer attacks: Attacks performed at application layer such as buffer overflow, viruses and malicious codes, web application attacks. . . 2. Brute-force attacks & password guessing attacks on authentication modules. 3. Rogue devices: Devices introduced into the network that are not authorised. A device may be a single PC, but it could be a switch, router, DNS server, DHCP server or even a wireless access point. 4. Denial of Service: The problem of DOS attacks is still present with IPv 6. 5. Attacks using social networking techniques such as email spamming, phishing, etc. …

Summary • Secure E-mail and S/MIME o S/MIME • Domain. Keys identified mail o Internet mail architecture o DKIM strategy • SSL and TLS o o TLS architecture TLS protocols TLS attacks SSL/TLS attacks • HTTPS o Connection institution o Connection closure • IPv 4 and IPv 6 security o IP security overview o The scope of IPsec o Security associations o Encapsulating security payload o Transport and tunnel modes