final exam-review 1 ppt - hanijessa.com exam-review 1.pdf · confidentiality in pgp email is...

CNT 4403- Spring 2012

Final Exam- Review 1

Topics

Chapter 16 Email SecurityChapter 16 Email Security

Chapter 17 Transport Layer Security

Chapter 18 Network Layer Security

PGPPGPPrettyPretty GoodGood PrivacyPrivacy (PGP)(PGP) cancan bebe usedused toto createcreate aa securesecureee--mailmail messagemessage oror toto storestore aa filefile securelysecurely forfor futurefutureretrievalretrieval..

PGPPGP MessageMessage IntegrityIntegrity andand AuthenticationAuthentication

16.2

The sender (Alice) creates a digest of the message and signs itwith her private key. The receiver (Bob) verifies the message byusing Alice’s public key.

Ch16 Email Security

PGPCompressionCompression inin PGPPGP

Data compression has no security benefits, but it reduces thevolume of email traffic and is frequently used in PGP. In the

16.3

volume of email traffic and is frequently used in PGP. In thedefault mode, PGP compresses message after signing but beforeencrypting.

ConfidentialityConfidentiality inin PGPPGPSince public key encryption methods are not computationallyefficient and cannot be used for large email messages, messageconfidentiality in PGP is achieved using symmetric keyencryption with a one-time (session) key.

Ch16 Email Security

PGPConfidentialityConfidentiality withwith OneOne--TimeTime SessionSession KeyKey

Confidentiality in PGP email is achieved using symmetric keyencryption with a one-time (session) key. The sender creates asession key (random number whose seed is generated bykeystorkes typed by the sender) to encrypt both the message andthe signed digest. The sender also encrypts the session key withthe public key of the receiver and sends the encrypted key withthemessage.

16.4

themessage.

Ch16 Email Security

Key Rings

In PGP, each user stores two sets of keys (called key rings). • The Private Ring: this is the set of private/public key pairs used by the

user (a user may change his private/public pair of keys from time to time).• The Public Ring: this is the set of public keys of other persons with whom

the user needs to correspond.

16.5

Ch16 Email Security

PGP uses certificates to authenticate public keys. However, theprocess is totally different from CA-based X.509 certificates. InPGP, there is no need for CAs; anyone in the ring can sign acertificate for anyone else in the ring.

PGP Certificates

�PGP certificates: a single certificate could have multiple signatures. The certificates use the Web of Trust model which adds the notion that trust is in the eye of the beholder.

16.6

TrustsTrusts andand LegitimacyLegitimacyTheThe entireentire operationoperation ofof PGPPGP isis basedbased onon�� IntroducerIntroducer trusttrust�� CertificateCertificate trusttrust�� LegitimacyLegitimacy ofof thethe publicpublic keyskeys

Ch16 Email Security

adds the notion that trust is in the eye of the beholder.

Format of Private Key Ring Table

Each entry corresponds to one private/public key pair.• User ID: this is usually the email address of the user.• Key ID: 64 bits identifying the public key of this entry, e.g., the first 64 bits

of the public key. The shorter Key ID is transmitted in the message insteadof the full public key to save space. The key ID will very likely be uniqueand is used to index the table.

• Public key:this is the full public key.• Encrypted private key:PGP does not store the private key in plaintext. PGP

uses thepass-phrase (sequenceof key strokeswith possiblepauses)of the

16.7

uses thepass-phrase (sequenceof key strokeswith possiblepauses)of theuser and the predefined decryption algorithm to decrypt theprivate key.

• Timestamp:this is the date/time of the key pair creation.

Ch16 Email Security

Format of Public Key Ring Table

Each entry corresponds to the public key of one user.

• User ID:this is the email address of the user.• Key ID: 64 bits identifying the public key of this entry, e.g., the first

64 bits of the public key.• Producer Trust:is the trust level for the owner of the public key.• Certificate(s) or Signature(s):the public key may have more than one

certificate. Each certificate holds the public key and is signed bysome entity.

• CertificateTrust(s): for eachcertificatestoredfor this public key, this

16.8

• CertificateTrust(s): for eachcertificatestoredfor this public key, thisis the level of trust assigned to the entity that signed the certificate.

• Key Legitimacy: this is a value calculated based on the weightedcertificate trust levels, e.g.,

no trust→ 0, partial trust→ 0.5, full trust→ 1• Timestamp:this is the date/time of the creation of this entry

Ch16 Email Security

Format of Public Key Ring Table

• Key Legitimacy: is the value calculated based on the weightedcertificate trust levels, e.g.,

no trust→ 0, partial trust→ 0.5, full trust→ 1

In order for Alice to communicate securelywith Bob, the PGP Key Legitimacy of Bob’spublic key in Alice’s public key ring must

16.9

public key in Alice’s public key ring musthave a full trust level, i.e., a value 1.

Ch16 Email Security

Sending a Confidential MessageExtracting information at the sender site: The sender (Alice)

selects the user ID (email address) to be used for sending the message. PGP uses this ID as an index to Alice’s private key ring and extracts the key ID (64 bits identifyingAlice’s public key) and Alice’s encrypted private key. PGP uses the predefined decryption algorithm and the pass-phrase typed by Alice to decrypt the private key. PGP uses a random number generator to create a random session key (the seed

is keystrokes typed by Alice). PGP creates a message digest and signs

16.10

(encrypts) it with Alice’s private key. PGP uses the session key and the predefined symmetric-key algorithm to encrypt the message and the digest. PGP uses the receiver’s user ID (typed by Alice) as an index to Alice’s public key ring to extract the receiver’s key ID (to be sent in the message) and the receiver’s public key to encrypt the session key.

Ch16 Email Security

Receiving a Confidential MessageExtracting information at the receiver’s site: PGP uses Bob’s

public key ID sent in the message as an index to Bob’s private key ring to find Bob’s encrypted private key. PGP decrypts this private key using the decryption algorithm defined in the message and the pass-phrase typed by Bob. PGP uses Bob’s decrypted private key to decrypt the session key sent in the message. PGP uses this session key to decrypt the message and the signed digest. PGP uses Alice’s key ID sent in the message as an index to Bob’s public key ring to extractAlice’s public key, which is used

16.11

to decrypt the message digest. PGP then computes a new digest from the received message using the predefined hash algorithm and compares the new digest with the decrypted digest to authenticate the message.

Ch16 Email Security

S/MIMES/MIME is a security enhancement to MIME. S/MIMEprovides the following cryptographic security services forelectronic messaging applications:authentication, messageintegrity and non-repudiation of origin (using digitalsignatures) andprivacy and data security(using encryption).

S/MIME adds some new content types to include securityservicesto the MIME protocol. All of thesenew typesinclude

16.12

servicesto the MIME protocol. All of thesenew typesincludethe parameter “application/pkcs7-mime,” in which “pkcs”stands for “Public Key Cryptography Specification.”

Both PGP and S/MIME are on IETF standards track, and itappears likely that both will continue to be popular. S/MIME isemerging as the industry standard for commercial andorganizational use, while PGP will remain a favorable choicefor personal email security of many users and companies.

Ch16 Email Security

Exercise 1:Alice wants to send message M to Bob. She generates a session key K and encrypts K with the public key of Bob. She then encrypts the message with the session key K. Finally, she sends the encrypted key and the encrypted message to Bob.

Does the above procedure guarantee message confidentiality? Yes. Only Bob can decrypt the session K using his private key then decrypt and read the message.

S/MIME Enveloped-data content type

then decrypt and read the message.

Does the above procedure guarantee message authentication? No. Attacker Eve can generate a session key and encrypt it with Bob’s public key. Eve can encrypt the message and send it to Bob pretending message is coming from Alice.

Does the above procedure guarantee message integrity? No. Since no message digest is used, bit errors and message modification cannot be detected.

Ch16 Email Security

Exercise 2:Alice wants to send message M to Bob. She applies a hashing function to compute the digest of M . She then encrypts (signs) the digest with her private key. Finally, she sends M, the signed digest and the certificate for her public key to Bob.

Does the above procedure guarantee message confidentiality? No. Anyone can read M because it is not encrypted.

Does the above procedure guarantee message authentication?

S/MIME Signed-data content type

Does the above procedure guarantee message authentication? Yes. Only Alice can sign the digest with her private key.

Does the above procedure guarantee message integrity? Yes. If the message is modified, the digest will change.

Does the above procedure guarantee message non-repudiation? Yes but only against the sender. Bob can provide the signed digest and the certificate (signed by CA) to prove Alice has sent the message. Alice has no proof that Bob received the message.

Ch16 Email Security

Email Security Enhancements for S/MIMETwo proposed enhanced security services:• Signed Receipts: a signed receipt may be requested for Signed-Data

messages to provide a proof of delivery to the sender and allows the sender to demonstrate to a third party that the recipient has received the message. To do so, the recipient signs the entire original message plus the original (sender’s) signature and append the new signature to form a new S/MIME reply message.

• Secure Mailing Lists: the user can employ the services of an S/MIME Mail List Agent (MLA). The MLA takes a single incoming message plus a list of List Agent (MLA). The MLA takes a single incoming message plus a list of multiple recipients and performs the recipient-specific encryption for each recipient, then forwards (sends) the messages. This relieves the sender from processing the message for each recipient; the sender only sends the message to the MLA. To do so, the sender generates a session key and encrypts it with the MLA’s public key, encrypts the message using the session key, then sends the encrypted session key and message to MLA.

With these enhanced security features, S/MIME can provide confidentiality (protection from disclosure), authentication (of the sender of

message), message integrity (protection from modification), and non-repudiation (protection from denial by sender or optionally by receiver).

Ch16 Email Security

Domain Keys Identified Mail (DKIM)

� DKIM is a specification for cryptographically signing email messages permitting a signing domain to claim responsibility for a message in the mail stream.

� 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.directly to retrieve the appropriate public key.

� DKIM is a proposed Internet Standard RFC 4871

� DKIM has been widely adopted by a range of email providers, including corporations, government agencies, gmail, yahoo, and many Internet Service Providers (ISPs).

Ch16 Email Security

� DKIM is designed to provide an email authentication technique transparent to the end user. In essence, a user's email message is signed by a private key of the administrative domain from which the email originates. The signature covers all of the content of the message and some of the RFC 5322 message headers.

� At the receiving end, the MDA can access the

DKIM Strategy

� At the receiving end, the MDA can access the corresponding public key via a DNS and verify the signature, thus authenticating that the message comes from the claimed administrative domain. Thus, mail that originates from somewhere else but claims to come from a given domain will not pass the authentication test and can be rejected.

� This approach differs from that of S/MIME and PGP, which use the originator's private key to sign the content of the message.

16.17

Ch16 Email Security

Secure Sockets Layer (SSL)Secure Sockets Layer (SSL)

SSLSSL isis designeddesigned toto provideprovide securitysecurity andand compressioncompression servicesservices totodatadata generatedgenerated fromfrom thethe applicationapplication layerlayer.. SSLSSL uses TCP toprovide a reliable end-to-end service.

Key Exchange Algorithms:In SSL, the client and server need to establish

17.18

In SSL, the client and server need to establish and exchange six cryptographic secrets. To create these secrets, one pre-master secret must be established and exchanged between the two parties. The client and server can use one of several SSL exchange algorithms to exchange the pre-master key. We only covered the RSA key exchange algorithm in CNT 4403. Ch17 Transport Layer Security

RSA Key Exchange Method

�The server sends its public key certificate**to the client so that the client can encrypt certain SSL parameter values and send them confidentially to the server.

� In the RSA exchange method, the 48-byte pre-master secret is created by the client, encrypted with the server’s RSA public key

17.19

encrypted with the server’s RSA public key and is sent to the server.

Ch17 Transport Layer Security** What is colloquially known as SSL certificate is actually an X.509 certificate.

Encryption/decryption algorithms SSL allows stream or block symmetric key encryption methods, including no encryption (NULL), Block DES, and Block Fortezza.

SSL

Hash algorithms for message integrity and authenticationIn SSL, the following three options are available for the hash algorithm : NULL (no authentication), MD5 and SHA-1.

17.20

Cipher SuiteTheThe combinationcombination ofof keykey exchange,exchange, hash,hash, andand encryptionencryption algorithmsalgorithmsdefinesdefines aa ciphercipher suitesuite forfor eacheach SSLSSL sessionsession.. TheThe tabletable shownshown onon thethenextnext slideslide showsshows thethe suitessuites usedused inin thethe UnitedUnited StatesStates.. NoteNote thatthat thethecompressioncompression algorithmalgorithm isis notnot partpart ofof thethe CipherCipher SuiteSuite..

CompressionCompression AlgorithmsAlgorithmsCompressionCompression isis optionaloptional inin SSLvSSLv33.. Therefore,Therefore, thethe defaultdefault compressioncompressionmethodmethod isis NULLNULL..

Ch17 Transport Layer Security

Cryptographic Parameter GenerationCalculation of the master secret from the pre-master secret:

SSL needs 6 cryptographic secrets : each of the client and the server needs one key for message authentication, one key for encryption, and one initial vector (IV) for symmetric block encryption. Before creating these 6 secrets, a master key must be established as follows:1. The client creates a random number (CR) and the server creates a

random number (SR). The two parties exchange these numbers. 2. If the RSA exchange method is used, the client creates a pre-master

key and sends it to the server.

17.21

3. A 48-byte master secret is created from the pre-master secret, CR and SR by applying two hash functions: SAH-1 in the first stage and MD5 in the second stage, as shown in the figure on the side. Ch17 Transport Layer Security

Calculation of key material from the master secretSSL requires that the keys in one direction of the connection be different from the keys in the other direction. There are a total of 6 keys: three for the client and three for the server. The three keys of the client are used by the client to write and send messages to the server and are also used by the server to read messages received from the client; therefore they serve as the Write keys for the client and the Read keys for the server. Similarly, the three keys of the server are Write Keys for the server and Read keys for the client.

Cryptographic Parameter Generation

The master key is used to

17.22

The master key is used to create the six keys by applying two stages of hash functions (SHA-1 and MD5). Each stage consists of a number of hash modules that are enough to produce a random string whose length is sufficient for the six keys based on the specific cipher suite used in the SSL session. Ch17 Transport Layer Security

Extractions of cryptographic secrets from key material (continued)After producing a random string of sufficient length, the six keys are extracted as shown below.

Cryptographic Parameter Generation

17.23

Ch17 Transport Layer Securityclient Write MAC secret

SSL Sessions and ConnectionsA session is defined by a session state which consists of the following set of parameters: Session ID, Peer Certificate (may be null), compression method, Cipher Suite, Master Secret, and Is-Resumable Flag (to indicate if connections can be resumed in an old session). The SSL specifications suggest that the state information be cached for no longer than 24 hours. If no sessions are resumed within that time, all information is deleted and any new sessions have to go through the handshake again.

A connection within a session is defined by a connection state which includes the following set of parameters: server and client random numbers, server Write MAC secret (for authentication), client Write MAC secret, server Write Secret (for data encrypted by the server and decrypted by the client), client Write Secret, client Initialization Vector

17.24

the server and decrypted by the client), client Write Secret, client Initialization Vector (used by block ciphers for the first block exchange; the final cipher text from a block is used as the IV for the next block), server Initialization Vector.


SSL - Four Protocols

SSL defines four protocols in two layers, as shown below. Therecordprotocol is the carrier protocol: it carries messages from the three other SSLprotocols as well as the data coming from the application layer.

17.25


Handshake Protocol

The Handshake Protocol uses messages to negotiate the cipher suite, to authenticate the server and client to each other and to exchange information for building the cryptographic secrets. The handshake is done in four phases.

17.26


Phase I of Handshake ProtocolEstablishing Security Capabilities:

In Phase I, the client sends a Client Hello message containing the following : highest SSL version number supported by the client, 32-byte random number (CR), suggested session ID, list of cipher suites the client can support, list of compression methods supported by the client.The server replies by sending a Server Hello message containing the following: the SSL version number to be used in the session, a 32-byte random number (SR), the session ID, the selected cipher suite and the selected compression method.

17.27

selected compression method.


Phase II of Handshake ProtocolServer Authentication and Key Exchange:

In Phase II, the server authenticates itself by sending the following 4 messages:1. Server’s Certificate if required: a chain (one or more) of X.509 certificates 2. Server Key Exchange: is the server’s contribution to the pre-master secret. The pre-master secret is jointly selected by the client and server. But in the RSA exchange method, the client alone selects the pre-master secret and sends it to the server in Phase III of the Handshake Protocol.3. Certificate Request: the server may request the client to authenticate itself in Phase III. The server may specify the list of acceptable certification authorities.

17.28

Server’s contribution to pre-master key

Phase III. The server may specify the list of acceptable certification authorities.4. Server Hello Done: this is the last message in Phase II.

The contents of the first two messages aredependent on the selected key exchange method


Phase II of Handshake Protocol

The first two messages of Phase II (Certificate message and Server Key Exchange message ) are based on the selected key exchange method.

In the RSA method,the server sends its RSA encryption/decryption public key certificate. The second message is empty because the pre-master secret is generated and sent by the client in Phase III.

17.29


Phase III of Handshake ProtocolClient Authentication and Key Exchange:

In Phase III of the Handshake Protocol, the client sends up to three messages to the server.1. Client’s Certificate: this message is only sent if the server requested client authentication in Phase II. The format is the same as the format of the server’s certificate sent in Phase II. The message contains the chain of certificates that certify the client.2. Client Key Exchange message: is the client’s contribution to the pre-master secret. In the RSA method, the client creates the entire pre-master secret and encrypts it with the RSA public key of the server sent in Phase II.

17.30

Client’s contribution to pre-master key

hash code →→→→Encrypt a message using private key

encrypts it with the RSA public key of the server sent in Phase II.

3. Certificate Verify: If the client has sent a certificate in (1) above, it must show that it owns the public key in the certificate by encrypting some meaningful message using the client’s private key. The server can verify that the client indeed possesses the private key (i.e., is not an imposter) by decrypting the message with the public key stored in the client’s certificate. Ch17 Transport Layer Security

Phase III of Handshake ProtocolThe three messages in Phase III are based on the selected key-exchange method.

In the RSA method, there is no certificate message unless the server has explicitly requested client authentication in Phase II. In the absence of such a request, Phase III consists of only one message as shown in the figure below. The Client Key Exchange message includes the pre-master key encrypted with the server’s RSA public key received in Phase II.

17.31

No certificate except if explicitly requested by server in Phase II


Phase IV of Handshake ProtocolFinalizing and Finishing

In Phase IV, the client and server send messages to change cipher specification and to finish the Handshake protocol. Four messages are exchanged in this phase.1) Change Cipher Spec: the client sends this message to show that it has moved all of the cipher suite set and its parameters from the pending state to the active state. This message is actually part of the second SSL protocol (Change Cipher Spec Protocol).2) Finished: the client sends this message to announce the end of the Handshake protocol.3) Change Cipher Spec: the server sends this message to show that it has moved all

17.32

of the cipher suite set and its parameters from the pending state to the active state.4) Finished: the server sends this message to announce the end of the Handshake protocol.


Change Cipher Spec ProtocolThe negotiation of the cipher suite and the generation of the cryptographic secrets are formed gradually during the Handshake Protocol. SSL mandates that the two parties cannot use the security parameters and secrets until they have sent or received a special message, the Change Cipher Spec message. This message is first used in the Handshake protocol, but is actually defined and used by the Change Cipher Spec Protocol.

The sender and receiver need two states: a pending state and an active state. The pending state keeps track of the parameters and secrets. The active state

17.33

The pending state keeps track of the parameters and secrets. The active state holds the parameters and secrets used by the Record protocol to sign/verify or encrypt/decrypt messages. Both the pending state and the active state hold two sets of values: read (inbound) and write (outbound).

The Change Cipher Spec Protocol defines the process of moving values between the pending state and the active state.


Example- ChangeCipherSpec Protocol

Movement of parameters from pending state to active state

17.34


Alert ProtocolSSl uses the Alert Protocol for reporting errors and abnormal conditions. Alert messages describe the problem and its level (warning or fatal). Some types of Alert messages are shown below.

17.35


Record ProtocolThe Record Protocol carries messages from the SSL Handshake Protocol, SSL Change Cipher Spec Protocol, SSL Alert Protocol or the application layer. The message is fragmented (into blocks of size 2^14 bytes) and optionally compressed. A MAC is added to the compressed message using the selected hash algorithm. The compressed fragment and the MAC are encrypted using the selected encryption algorithm and the cipher Write Secret. Finally the SSL header is added. The process at the receiver is reversed.

17.36


Transport Layer Security (TLS)

The Transport Layer Security (TLS) protocol is the IETFstandard version of the SSL protocol. The two are very similar,with slight differences.

The first difference is the version number. The current versionof SSL is 3.0; the current version of TLS is 1.0. SSLv3.0 is

17.37

of SSL is 3.0; the current version of TLS is 1.0. SSLv3.0 iscompatible with TLSv1.0.

Another minor difference between SSL and TLS is the lack ofsupport for the Fortezza method for key exchange or forencryption/decryption.The number of ciphers suites in TLS istherefore smaller than in SSL.


Note: The TLS Handshake is used to protect the Extensible Authentication Protocol (EAP)used in 802.11i for WLANs.

Generation of Cryptographic SecretsTLS defines two functions: the data expansion function and the pseudorandom function.

Data Expansion Function:This function uses a predefined HMAC (SHA-1 or MD5) to expand a secret into longer one. The function consists of multiple sections where each section creates one hash value. Each section uses two HMACs, a secret and a seed. As many of these sections are chained together as required; the input seed in the first HMAC of a section is the output of the first HMAC of the previous section. The process

17.38

of a section is the output of the first HMAC of the previous section. The process is shown in the figure given on the next slide.

Pseudorandom Function (PRF):This is the combination of two data-expansion functions, one using MD5 and the other SHA-1. PRF takes three inputs: a secret, a label, and a seed. The label and the seed are concatenated and serve as the seed for each data-expansion function. The secret is divided into two halves: each half is used as the secret for one data-expansion function. The outputs of the two data-expansion functions are Exclusive-ORed to create the final expanded secret. The process is shown in the figure given on the next slide. Ch17 Transport Layer Security

Generation of Cryptographic SecretsData-expansion function

Pseudorandom Function (PRF)

17.39

Pseudorandom Function (PRF)


PRF uses two inputs: 1. Secret split into two halves2. Seed concatenated with a label

Security at the Application Layer

Examples: PGP, S/MIME, Kerberos, S-HTTP, SSH, etc.� Implemented in end-hosts� Advantages- Extend application without involving operating system.- Extend application without involving operating system.- Application can understand the data and can provide the appropriate

security.

� Disadvantages- Security mechanisms have to be designed independently of each

application.

Note: HTTPS is also an application level protocol but it is largely based on using HTTP over TLS/SSL. HTTPS should not be confused with Secure HTTP (S-HTTP) specified in RFC 2660 (August 1999).


HTTPS� HTTPS (HTTP over SSL/TLS)

� combination of HTTP & SSL/TLS to secure communications between browser & server

� documented in RFC 2818

� no fundamental change using either SSL or TLS

� use https:// URL rather than http://� use port 443 rather than 80

� encrypts� URL of requested document, document contents,

form data, cookies, HTTP headers


SSH Transport Layer Protocol: Provides server authentication, data confidentiality, and data integrity. The SSH transport layer

� Protocol for secure network communications� designed to be simple & inexpensive

� SSH1 provided secure remote login facility� replaces TELNET & other insecure schemes

Secure Shell (SSH)

and data integrity. The SSH transport layer may optionally provide compression.

User Authentication Protocol: Authenticates the user to the server.

Connection Protocol: Multiplexes multiple logical communications channels over a single underlying SSH connection.


IPSec

IP Security (IPSec) is a collection of protocols designed by IETF to provide security at the network layer for all applications. IPSec helps create authenticated and confidential packets for the IP layer.

18.43

IPSec operates in one of two different modes: transport mode or tunnel mode

Ch18 Network Layer Security

In transport mode, IPSec protects what is delivered from the transport layer to thenetwork layer. An IPSec header and trailer are added to the information coming from thetransport layer. The IP header is added later. The transport mode is used for theprotection of host-to-host communication. The sending host uses IPSec to authenticateand/or encrypt the payload delivered from the transport layer. The receiving host usesIPSec to check authentication and/or decrypt the IP packet.

Transport Mode

18.44

IPSec in transport mode does not protect the IP header; it only protects the information coming from the transport layer.


In tunnel mode, IPSec protects the entire IP packet. It takes an IP packet (including theIP header), applies IPSec security methods to the entire packet, and then adds a new IPheader. Some fields in the new IP header have different values than theirvalues in theoriginal header. Tunnel mode is used to protect communication between two routers orbetween a host and a router. Basically, the tunnel mode is used when either the sender orthe receiver is not a host.

Tunnel Mode

18.45

IPSec in tunnel mode protects the entire original IP packet (including the original IP header) as if the entire packet goes through an imaginary tunnel.


Two Security Protocols Two Security Protocols IPSec defines two protocols—the Authentication Header (AH) Protocol and theEncapsulating Security Payload (ESP) Protocol to provide authenticationand/orencryption for packets at the IP level.

Authentication Header (AH)The AH protocol is designed to authenticate the source host and to ensure the integrity of the payload. The protocol uses a hash function and a key to create a message digest which is included in AH. The hash function is applied to the entire packet except for the fields that change in transit (e.g., time-to-live).

18.46

The AH protocol provides source authentication and data integrity, but not privacy.


Encapsulating Security Payload (ESP)

The ESP protocol provides source authentication, integrity and privacy. ESP adds header and trailer. The authentication data are added at the end of the packet and is computed based on the ESP header, the payload and the ESP trailer. Privacy is obtained by encrypting the payload and ESP trailer.

18.47

ESP provides source authentication, data integrity, and privacy.Ch18 Network Layer Security

SECURITY ASSOCIATIONSECURITY ASSOCIATION

SecuritySecurity AssociationAssociation isis aa veryvery importantimportant aspectaspect ofof IPSecIPSec.. IPSecIPSec requiresrequires aa logicallogical relationship,relationship,calledcalled aa SecuritySecurity AssociationAssociation (SA),(SA), betweenbetween twotwo hostshosts.. AnAn SASA isis aa contractcontract thatthat createscreates aa securesecurechannelchannel betweenbetween twotwo partiesparties..

ExampleExample::IfIf AliceAlice needsneeds aa unidirectionalunidirectional communicationcommunication withwith BobBob andand isis interestedinterested onlyonly inin thetheconfidentialityconfidentiality aspectaspect ofof security,security, sheshe andand BobBob willwill needneed toto getget aa sharedshared secretsecret keykey.. InIn thisthis case,case,therethere areare twotwo SAsSAs forfor thethe unidirectionalunidirectional channelchannel betweenbetween AliceAlice andand BobBob:: oneone outboundoutbound andand oneoneinboundinbound.. EachEach SASA storesstores thethe valuevalue ofof thethe sharedshared keykey andand thethe namename ofof thethe encryption/decryptionencryption/decryptionalgorithmalgorithm.. AliceAlice usesusesthethealgorithmalgorithm andand thethekeykeyofof thetheoutboundoutboundSASAtoto encryptencryptthethemessagemessagetoto

18.48

algorithmalgorithm.. AliceAlice usesusesthethealgorithmalgorithm andand thethekeykeyofof thetheoutboundoutboundSASAtoto encryptencryptthethemessagemessagetotoBobBob.. BobBob usesuses thethe algorithmalgorithm andand thethe keykey ofof thethe inboundinbound SASA toto decryptdecrypt thethe messagemessage receivedreceivedfromfrom AliceAlice..


Security Association Database (SAD)IPSec uses SAD to store the set of inbound and outbound security associations for the various people that a given user corresponds with. SAD is a two-dimensional table with each row defining a single SA. Normally the table is implemented as two tables, one inbound and one outbound.

18.49

When a host sends a packet via IPSec, it needs to find the corresponding entry in the outbound SAD to find the information needed to apply the correct security services to the packet. Searching the database is done using the triple index: security parameter index (a number that defines the destination), destination address, and the protocol identifier (AH or ESP).

Some of the SA parameters are: • Sequence number (incremented after each

packet sent and used as the sequence number field in AH or ESP headers)

• Anti-replay window size (explained on the next slide)

• AH/ESP information (authentication algorithm and keys for AH/ESP, encryption algorithm and keys for ESP, other parameters)

• LT: the SA lifetime


Replay Attack ProtectionIn both the AH and ESP protocols, replay attack is prevented by using a sequence numberand a slidingwindow. Each IPSec header contains a unique 32-bit sequence numberfirst selected when the securityassociation is established. When the sequence number reaches the maximum value (2^32-1), it is reset to zero.To prevent processing duplicate packets, the receiver maintains a fixed-size anti-replay window to storeincoming packets. An incoming packet must have a sequence number that falls within this window, i.e.,between N and N+W-1 in the figure shown below. There are threecases.

Case 1:If the sequence number of the arriving packet falls within this window and the packet is non-marked,the packet goes through an authentication check. If it passes the authentication check, it is accepted and itssequence number is marked. If the packet is already marked orif it does not pass the authentication check, itis discarded.Case 2: If the sequence number of the arriving packet is smaller thanN, the packet is considered as aduplicate (replay) packet or late packet and is discarded.Case3: If the sequencenumber is larger than N+W-1, the packetgoesthrough an authenticationcheck. If it


18.50

Case3: If the sequencenumber is larger than N+W-1, the packetgoesthrough an authenticationcheck. If itpasses the authentication check, the packet is accepted andits sequence number is added to the windowcausing the window to slide to the right to accommodate the new sequence number.

The figure below shows an example of an anti-replay window: the colored slots signify received packets thathave been checked and authenticated; the white slots denotesequence numbers whose packets have not beenreceived yet.

Security PolicyAnotherAnother importimport aspectaspect ofof IPSecIPSec isis thethe SecuritySecurity PolicyPolicy (SP),(SP), whichwhich definesdefines thethe typetype ofofsecuritysecurity appliedapplied toto aa packetpacket whenwhen itit isis toto bebe sentsent oror whenwhen itit hashas arrivedarrived.. BeforeBeforeaccessingaccessing thethe SADSAD databasedatabase toto determinedetermine thethe securitysecurity association,association, aa hosthost mustmustdeterminedetermine thethe predefinedpredefined policypolicy forfor thethe packetpacket..

Security Policy Database (SPD)EachEach hosthost needsneeds toto keepkeep aa SPDSPD whichwhich isis normallynormally splitsplit intointo inboundinbound SPDSPD andandoutboundoutbound SPDSPD.. EntriesEntries inin thisthis databasedatabase areare fetchedfetched usingusing thethe sixsix--tupletuple indexindex:: sourcesourceaddress,address, destinationdestination address,address, NameName (DNS(DNS entityentity name),name), protocolprotocol (AH(AH oror ESP),ESP), sourcesourceport,port, andand destinationdestinationportport..

18.51

port,port, andand destinationdestinationportport..


Outbound SPDWhen the packet is sent, the outbound SPD is searched using the six index variables taken from the packet. The output of the search leads to one of the following three cases.Drop: the packet cannot be sent and is dropped.Bypass: there is no security policy set for this packet ; the packet is sent bypassing the security header application.

Apply: in this case, the security header is applied. There are 2 cases:� If an outbound SA exists, the triple SA

Outbound Packet Processing in the IPSec Transport Mode

18.52

� If an outbound SA exists, the triple SA index is used to fetch this SA from the outbound SAD. The AH or ESP header is formed, encryption or authentication or both are applied and the packet is transmitted.

� If there is no outbound SA for this packet, the Internet Key Exchange (IKE) protocol is called to create an outbound SA in the sender’s SAD and an inbound SA in the receiver’s SAD. Ch18 Network Layer Security

Inbound SPDWhen the packet is received, the inbound SPD is searched using the six index variables taken from the packet. The output of the search leads to one of the following three cases.Discard: the packet must be discarded.Bypass: there is no security policy set for this packet ; the packet is processed ignoring the information contained in the AH or ESP header.

Apply: in this case, the security header must be processed . There are 2 cases:� If an inbound SA exists for this Inbound Packet Processing

in the IPSec Transport Mode

18.53

� If an inbound SA exists for this packet, the triple SA index is used to fetch this SA from the inbound SAD. Decryption or authentication or both are applied by the IPSec layer. If the packet is authenticated and passes the security criteria, the AH or ESP header is removed and the packet is delivered to the transport layer.

� If there is no inbound SA for this packet, the packet must be discarded.

in the IPSec Transport Mode


Internet Key Exchange (IKE)

TheThe InternetInternet KeyKey ExchangeExchange (IKE)(IKE) isis aa protocolprotocol designeddesigned toto createcreate bothbothinboundinbound andand outboundoutbound SecuritySecurity AssociationsAssociations.. IKEIKE isis basedbased onon threethreeprotocolsprotocols:: OakleyOakley (a(a protocolprotocol basedbased onon thethe DiffieDiffie--HellmanHellman keykey exchangeexchangemethod),method), SKEMESKEME (a(a protocolprotocol thatthat usesuses publicpublic--keykey encryptionencryption forfor entityentityauthentication),authentication), andand ISAKMPISAKMP (the(the InternetInternet SecuritySecurity AssociationAssociation andand KeyKeyManagementManagement Protocol)Protocol) designeddesigned byby thethe NationalNational SecuritySecurity AgencyAgency;; ISAKMPISAKMPisis thethe carrier,carrier, mostmost important,important, protocolprotocol thatthat actuallyactually implementsimplements thetheexchangesexchangesdefineddefinedinin IKEIKE..

18.54

exchangesexchangesdefineddefinedinin IKEIKE..


Example of IPSec Real World Deployment

Internet

Encrypted / Authenticated

Virtual Private Network (VPN)

IPSec provides protection from attack in virtual private networks (VPNs). IPSec provides user authentication, ensures data confidentiality and integrity, and enforces trusted communication. The strong cryptographic-based authentication and encryption support that IPSec provides is especially effective for securing traffic that must traverse untrusted network paths, such as those on a large corporate intranet or the Internet.

Note: IPSec is becoming the favorite protocol for securing BGP peer communications to

protect against man-in-the-middle attacks.

final exam-review 1 ppt - hanijessa.com exam-review 1.pdf · confidentiality in pgp email is...

Documents