0% found this document useful (0 votes)
13 views39 pages

15.+Internet+Security+Protocols+and+Standards (1)

Internet Security Protocols

Uploaded by

chehabb2003
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views39 pages

15.+Internet+Security+Protocols+and+Standards (1)

Internet Security Protocols

Uploaded by

chehabb2003
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 39

Internet Security Protocols and Standards

Read Chapter 22

1
S/MIME (Secure/Multipurpose Internet Mail Extensions)
• MIME extends the old RFC 822 specification of Internet mail format
– RFC 822 defines a simple heading with To, From, Subject, and other fields
– Assumes ASCII text format

• MIME provides a number of new header fields that define


information about the body of the message
– MIME provided support for varying content types and multi-part messages
– With encoding of binary data to textual form
– S/MIME added security enhancements

• Secure/Multipurpose Internet Mail Extension (S/MIME ): Security


enhancement to the MIME Internet e-mail format
– Based on technology from RSA Data Security

• Provides the ability to sign and/or encrypt e-mail messages


MIME Types
Type Subtype Description
Text Plain Unformatted text; may be ASCII or ISO 8859.
Enriched Provides greater format flexibility.
Multipart Mixed The different parts are independent but are to be transmitted together.
They should be presented to the receiver in the order that they appear
in the mail message.
Parallel Differs from Mixed only in that no order is defined for delivering the
parts to the receiver.
Alternative The different parts are alternative versions of the same information.
They are ordered in increasing faithfulness to the original, and the
recipient's mail system should display the "best" version to the user.
Digest Similar to Mixed, but the default type/subtype of each part is
message/rfc822.
Message rfc822 The body is itself an encapsulated message that conforms to RFC 822.
Partial Used to allow fragmentation of large mail items, in a way that is
transparent to the recipient.
External-body Contains a pointer to an object that exists elsewhere.
Image jpeg The image is in JPEG format, JFIF encoding.
gif The image is in GIF format.
Video mpeg MPEG format.
Audio Basic Single-channel 8-bit ISDN mu-law encoding at a sample rate of 8
kHz.
Application PostScript Adobe Postscript
octet-stream General binary data consisting of 8-bit bytes.
S/MIME Types

Type Subtype smime Parameter Description


Multipart Signed A clear-signed message in
two parts: one is the message
and the other is the signature.
Application pkcs7-mime signedData A signed S/MIME entity.
pkcs7-mime envelopedData An encrypted S/MIME
entity.
pkcs7-mime degenerate signedData An entity containing only
public-key certificates.
pkcs7-mime CompressedData A compressed S/MIME
entity.
pkcs7-signature signedData The content type of the
signature subpart of a
multipart/signed message.
S/MIME Functions
• S/MIME is defined as a set of additional
MIME content types and provides the
ability to sign and/or encrypt e-mail
messages.
• These content-types support four new
functions:
– Enveloped data: Consists of encrypted content and associated keys
– Signed data: digital signature is formed by taking the message digest of the content to
be signed and then encrypting that with the private key of the sender .
• content plus signature are then encoded using base64 encoding
• can be view by recipient with S/MIME
– Clear-signed data : digital signature of the content is formed as in signed data.
However, only signature is encoded using base64.
• recipients without S/MIME capability can view
– Signed & enveloped data: Signed-only and encrypted-only entities may be
nested, so that encrypted data may be signed and signed data or clear-signed
data may be encrypted.
Simplified S/MIME Functional Flow
Typical S/MIME Process for Creating and
S/MIME Message
Base64 encoding
• Encodes binary data by treating it numerically and translating it into a
base 64 representation
• General rule: choose a set of 64 characters that is part of a subset
common to most encodings, and also printable.
• Join every 3 bytes together and encode them as 4*6bits using the chosen subset
Example: encoded value of Man is TWFu.
• M, a, n ASCII codes are 77, 97, 110 (i.e., 01001101, 01100001, 01101110).
• These 3 bytes are joined together in 24 bit buffer as 010011010110000101101110
• Packs of 6 bits are converted into 4 numbers (24 = 4 * 6 bits) which are then
converted to their corresponding values in Base64.

"Man is distinguished, not only by his reason, but ..."


TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCAuLi4
Base64 index table
S/MIME Functions (Summary)
Signed and Clear-Signed Data
• Preferred algorithms for signing messages uses either RSA or DSA
signature of a SHA-256 message hash
– Map msg into fixed-length code of 256 bits, using SHA-256 producing a unique
256-bit message digest.
– Then, S/MIME encrypts digest using RSA and sender’s private RSA key.
– result : digital signature, which is attached to the message.
– Receiver can re-compute message digest and then decrypt signature using RSA
and the sender’s public RSA key.
– If message digest in the signature matches the message digest that was
calculated, then the signature is valid.
– Since this operation only involves encrypting and decrypting a 256-bit block, it
takes up little time

• Radix-64 or base64 mapping can be used to map the signature and


message into printable ASCII characters
S/MIME Enveloped Data
• Default algorithms used for encrypting S/MIME messages are AES
and RSA
– S/MIME generates a pseudorandom secret key to encrypt the message using
AES or some other conventional encryption scheme.
– This pseudorandom key is used only once. i.e., new pseudorandom key is
generated for each new message encryption. key is bound to message and
transmitted with it (encrypted)
– The secret key is used as input to the public-key encryption algorithm, RSA,
which encrypts the key with the recipient’s public RSA key
– On the receiving end, S/MIME uses receiver’s private RSA key to recover the
secret key and then uses it and AES to recover the plaintext message.

• If encryption is used alone, radix-64 is used to convert ciphertext to


ASCII format
DomainKeys Identified Mail (DKIM)
• DKIM is specification of cryptographically signing e-mail messages,
permitting a signing domain to claim responsibility for a message in
the mail stream

• Message recipients can verify signature by querying the signer’s


domain directly to retrieve the appropriate public key
– thereby can confirm that message was attested to by a party possession of the
private key for the signing domain

• Proposed Internet Standard (RFC 6376: DomainKeys Identified Mail


Signatures)

• Has been widely adopted by a range of e-mail providers such as


gmail, yahoo, and many Internet service providers (ISPs)
Internet E-Mail Architecture
Function Modules and Standardized Protocols Used Between Them
• Internet mail architecture
consists of user world
(MUAs) and transfer world (
MHS composed of many
MTAs)
• MHS creates a virtual MUA-
to-MUA exchange
environment that accepts a
message from one user and
deliver it to one or more other
users
• MUA: is user representative within the e-mail service, housed in the
user’s computer, is referred to as a client e-mail program or a local
network e-mail server
• MSA: Accepts the message submitted by an MUA and enforces policies. SMTP is used
between the MUA and the MSA (if they are not co-located)
• MTA: Relays mail for one application-level hop (like an IP router) until the message reaches
a destination MDA
• MDA: transfers the message from MHS to MS (message store), so MUA retrieves messages
from a remote server using POP or IMAP
DKIM Purpose
• Administrative management domain (ADMD): Internet e-mail
provider. Each ADMD can have different operating policies.
• Domain name system (DNS) provides mapping between the domain
name and its IP address
• S/MIME depends on both sender and receiver users using S/MIME
(many users however don’t use it) and only signs the contents;
– But email header may be compromised

• DKIM is designed to provide an email authentication between hosts


– DKIM is not implemented in client programs and it is transparent to end user
– DKIM applies to all emails
– At the sending end, each email is signed by the private key of the
administrative domain from which the e-mail originates
– At the receiving end, Mail delivery agent (MDA) can access the
corresponding public key via a DNS and verify the signature to authenticate that
the message comes from the claimed administrative domain
Domain Keys Identified Mail (DKIM) Deployment
Secure Sockets Layer (SSL) and Transport
Layer Security (TLS)
• SSL and the follow-on Internet standard TLS is one of the most
widely used transport layer security service
– TLS Subsequently became Internet standard (RFC 8446)

• General-purpose service implemented as a set of protocols that rely on


TCP
– designed to make use of TCP to provide a reliable end-to-end secure service

• There are two implementation choices:


– For full generality, TLS may be provided in underlying protocol suite
transparent to applications
– Or it can be embedded in specific package
• For example, most browsers come equipped with SSL, and most Web servers have
implemented the protocol
SSL/TLS Protocol Stack
• TLS is not a single protocol but rather two layers of protocols
– Record Protocol provides basic security services to various higher-layer
protocols (eg, HTTP):
• HTTP which provides transfer service for Web client/server interaction, can operate
on top of TLS
– Other three protocols are used in management of TLS
• Handshake Protocol
• Change Cipher Spec Protocol
• Alert Protocol
TLS Concepts
• Two important TLS concepts:
– TLS Session
• Session is an association between a client and a server
• Sessions are created by the Handshake Protocol
• Session define a set of cryptographic security parameters that can be shared
among multiple connections
• Sessions are used to avoid the expensive negotiation of new security
parameters for each connection

– TLS Connection
• Connection is a transport (in the OSI layering model definition) that
provides a suitable type of service
• For TLS, connections are peer-to-peer relationships
• Connections are transient
• Every connection is associated with one session
TLS/SSL Record Protocol Operation
• Record Protocol provides two services for SSL connections:
– Confidentiality: Handshake Protocol defines shared secret key that is used for
symmetric encryption of SSL payloads.
– Message integrity: Handshake Protocol also defines a shared secret key that is
used to form a message authentication code (MAC)

Steps:
1. Fragment the message into blocks of 214
bytes or less
2. Compress (optional)
3. Compute and add MAC
4. Encrypt msg and MAC using symmetric
encryption
5. Prepend SSL header which includes version
and length fields
TLS/SSL Record Protocol Operation

content types

• Record Protocol then transmits the resulting unit in a TCP segment.


• Received data are decrypted, verified, decompressed, and
reassembled, and then delivered to higher-level users.
TLS Change Cipher Spec Protocol
• Simplest protocol of the four TLS specific protocols that use the TLS
Record Protocol
• 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
TLS Alert Protocol
• used to convey TLS-related alerts to peer entity
– Alert messages are compressed and encrypted
• Each alert protocol message consists of two bytes:
– First byte takes the value warning (1) or fatal (2) to convey the
severity of the message
• If the level is fatal, TLS immediately terminates the connection
• Other connections on the same session may continue, but no new
connections on this session may be established

– Second byte contains a code that indicates the specific alert


• Examples:
– fatal alert is an incorrect MAC
– nonfatal alert is a close_notify message which notifies the recipient that the
sender will not send any more messages on this connection
TLS Handshake Protocol
• It is the most complex part of TLS
• It is used before any application data are transmitted
• It allows server & client to:
– authenticate each other
– negotiate encryption & MAC algorithms
– negotiate cryptographic keys to be used to protect data sent in an TLS record

• It comprises a series of messages exchanged by client and server in


four phases
1. Establish Security Capabilities
2. Server Authentication and Key Exchange
3. Client Authentication and Key Exchange
4. Finish
Intuition of SSL/TLS Handshake Protocol
SSL/TLS
Handshake
Protocol
Heartbeat Protocol
• In computer networks, a heartbeat is 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
• Defined in 2012 for SSL/TLS use in RFC 6250
• Heartbeat Protocol runs on top of the TLS Record Protocol
• Use of Heartbeat protocol is established during Phase 1 of Handshake
• Each peer indicates whether it supports heartbeats
– If heartbeats are supported,
• peer indicates whether to receive heartbeat_request messages and respond
with heartbeat_response messages
• or only to send heartbeat_request messages
• Serves two purposes:
– Assures the sender that the recipient is still alive
– Generates activity across the connection during idle periods
SSL/TLS Attacks
• Four general categories:
– Attacks on the Handshake Protocol
– Attacks on the record and application data protocols
– Attacks on the PKI (Public Key Infrastructure )
– Other attacks:
• Example: attack creates a heavy processing load on a server by
overwhelming target with SSL/TLS handshake requests
A recently discovered bug in open-source OpenSSL
implementation of the Heartbeat Protocol (it is not a
The Heartbleed
design flaw but a programming mistake) Exploit
• OpenSSL heartbeat reads incoming request and allocates buffer large enough to hold
message header, payload, and padding.
– It then overwrites current buffer contents with incoming request, changes first byte to indicate
response message type and transmits response (which includes payload length field and the
payload).
• However, software does not check length of incoming message.
– Adversary can send request that indicates maximum payload (64 KB) but only includes minimum
payload (16 bytes).
− As a result almost 64 KB of
the buffer is not overwritten
and whatever happened to be
in memory at the time will be
sent to the requestor
The Heartbleed Exploit (Another Illustration)
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
– URL addresses begin with https:// instead of http:// and port 443 is
used as default instead of 80
– Search engines do not support HTTPS

• Documented in RFC 2818, HTTP Over TLS


• For HTTPS, agent acting as the HTTP client also acts as the TLS
client
• TLS client establishes first a TCP connection with the server then sends TLS
ClientHello to begin the TLS handshake
– When TLS handshake completes, client then initiates the first HTTP request

• 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
IP Security (IPSec)
https://sourcedaddy.com/networking/ip-security.html
• various application security mechanisms
– S/MIME (email), Kerberos (client/server), TLS(web access)

• However, users have some security concerns that cut across protocol
layers
– Example: enterprise wants to run a secure, private TCP/IP network by
disallowing links to untrusted sites, encrypting leaving packets, and
authenticating incoming packets.

• Hence, implementing security at the IP level, one can ensure secure


networking not only for applications that have security mechanisms
but also for the many security-ignorant applications
• Internet Architecture Board (IAB) includes authentication &
encryption as necessary security features for IPv6
• also usable in existing IPv4
IPSec
• general IP Security mechanisms that provide
– Authentication: 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.

– Confidentiality: Enables communicating nodes to encrypt messages to prevent


eavesdropping by third parties.

– key management: Concerned with the secure exchange of keys.

• Provided by the Internet key exchange standard IKEv2

• applicable to use over LANs, across public & private WANs, & for
the Internet
Benefits of IPSec
• When IPsec implemented in a firewall/router, it provides strong
security to all traffic crossing the perimeter
– Traffic within a company does not incur overhead of security-related processing

• IPsec in a firewall is resistant to bypass if all traffic from the outside


must use IP and the firewall is the only means of entrance
• IPsec is below transport layer, hence transparent to applications
– There is no need to change software on a user or server system

• IPsec can be transparent to end users; There is no need to train users


on sec mechanisms such as keys
• IPsec can provide security for individual users if needed
– Such as VPN for offsite workers and for setting up a secure virtual subnetwork

• IPsec can play a vital role in securing routing architecture


The Scope of IPsec
• mandatory in IPv6, optional in IPv4
• have two main functions:
– Encapsulating Security Payload (ESP) function
• Combines both authentication and encryption functions
– Key Exchange function: manual/auto exchange of keys

• For VPN, both authentication and encryption are generally desired


• hence usually use ESP

• Also an authentication-only function, implemented using an


Authentication Header (AH)
– Because message authentication is provided by ESP, the use of AH is deprecated
but still included in IPsecv3 for backward compatibility

• IPsec specification is quite complex


– numerous RFC’s 4301/4302/ 4303/4306
Security Associations (SA)
• association is one-way relationship between sender & receiver that
affords security for traffic flow
– If a peer relationship is needed for two-way secure exchange then two security
associations are required

• SA is defined by 3 parameters:
– Security Parameters Index (SPI): bit string assigned to this SA , have local
significance only, carried in ESP header; tells receiver to select SA under which
received packet will be processed.
– IP Destination Address: destination endpoint of a SA (may be an end-user
system or a network system such as a firewall or router.
– Security Protocol Identifier: field in outer IP header indicates whether SA is
AH or ESP

• in any IP packet, SA is uniquely identified by Destination Address in


the IP header and SPI in the enclosed extension header (AH or ESP)
• has a number of other parameters: seq no, AH & EH info, lifetime etc
Encapsulating Security Payload (ESP)
• Security Parameters Index (32 bits): Identifies a SA.
• Sequence Number (32 bits): A monotonically increasing counter value.
• Payload Data (variable): is a transport-level segment (transport mode) or IP packet (tunnel
mode) that is protected by encryption.
• Padding (0–255 bytes): required if encryption algorithm requires plaintext to be a multiple of
some number of octets.
• Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.

• Next Header (8 bits): Identifies


type of data contained in Payload
Data by identifying first header in
that payload (e.g., TCP or IP).
• Integrity Check Value (variable):
variable-length field that contains
integrity check value computed
over the ESP packet minus the
Authentication Data field
Transport and Tunnel Modes
• Transport Mode
– Extends to the payload of an IP packet to include a TCP or UDP segment
– Typically used for end-to-end communication between two hosts
– ESP encrypts and optionally authenticates the IP payload but not the IP header

• Tunnel Mode
– Provides protection to the entire IP packet
• after the ESP fields are added to the IP packet, the entire packet plus security fields
are treated as the payload of new outer IP packet with new outer IP header.
– The entire original inner packet travels through a tunnel from one point of an IP
network to another
• no routers along the way are able to examine the inner IP header
– 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
Summary
• Secure E-mail and S/MIME
– MIME, S/MIME
• DomainKeys identified mail
– Internet mail architecture, DKIM strategy
• SSL and TLS
– TLS architecture, TLS protocols, TLS attacks, SSL/TLS attacks
• HTTPS
– Connection institution
– Connection closure
• IPv4 and IPv6 security
– IP security overview
– The scope of IPsec
– Security associations
– Encapsulating security payload
– Transport and tunnel modes

You might also like