CA 0r

Intrmitnt CA
 banks public certificate

CA - Verisign

client

CSScorp Paloalto
Digicert verisign
ICA ICA
Dicert RA Verisig R CA
Chain of trust (Verisgn ICA ( Digicert ICA
Verisn root) Digicert RCA)
issues to : hdfcbank.com
( Server cirtificate) - Public certificate - Public Key
Signed - ICA - Digital signature

issued to ICA ICA - certificate respository - Public key

ICA - (Public Certificate)
Singed - ( Root CA) - Digital Signature

RCA - root certificate - public key

issued : RCA
Signed : RCA
banks public certificate

CA - Verisign
SSL VPN
Steps involved in SSL handshake
 3 way handshake

cleint hello
server hello
server certificate

pre master secret, change ciphe spec

Change Chipher Spec

Resumption
The Transport Layer Security (TLS) is designed to add security to network communications. It
and HTTPS when browsing the Internet.
Using TLS creates additional work for the client and the server, but it has its benefits, includin
Confidentiality: TLS wraps traffic in an encrypted tunnel. This makes it impossible for a
the traffic on its way to its destination.
Authentication: TLS proves the identity of the server to the client. This is helpful in prot
Integrity: TLS includes protections that help with identifying if data has been modified or
All of these are valuable features when browsing the web. This is why TLS is so popular and w
with a TLS handshake.

What is the TLS Handshake?

Like a handshake in real life, the TLS handshake is an introduction. It establishes that two co
another in a secure fashion.
A TLS handshake also defines some of the rules for this conversation. Both the client and the
benefits of TLS, but they need to agree on the details. A TLS handshake gets them from an in
they can start talking privately.
Before diving into the details of the TLS handshake, it’s important to understand some key vo
protocol, which means that it uses a lot of cryptography. Some important terms to know whe
Inside the TLS Handshake
The goal of the TLS handshake is for the client and the server to agree on a shared symmetric
fashion. To do so, they use asymmetric encryption, which allows encrypted messages to be s
The details of the TLS handshake depend on the asymmetric encryption algorithm used. A cl
through the following steps:

1. Client Hello: The client kicks off the TLS handshake by sending configuration information
like the TLS version(s) supported by the client, which cipher suites it can use, and some rand
random”.
2. Server Hello: The server responds with a message including its choices of TLS version a
certificate, and the “server random”.
 3. Premaster Secret: The digital certificate provided by the server contains its public key,
messages sent to the server. After verifying the validity of the certificate, the client generat
the premaster secret. Using the server’s public key, the client encrypts this value and sends
4. Session Keys: The server uses its private key to decrypt the premaster secret. At this p
have the client random, server random, and the premaster secret. From these, they calcula
premaster secret is a secret value – it was only sent in an encrypted form over the network
5. Client Finished: To complete the TLS handshake, the client sends a message to the serv
session key. The server decrypts this message and verifies its correctness. If it matches, th
correctly calculated the session key.
6. Server Finished: The server also sends a message encrypted with the shared session ke
message proves to the client that the server correctly calculated the session key.

At this point, the client and server have a shared encryption key known only to them. For the
messages will be encrypted using this session key.

Beyond the Basic Handshake

The process described here is the basic TLS handshake, which is used in most TLS sessions.
additional steps that provide certain benefits.
For example, the basic TLS handshake uses a digital certificate to authenticate the server to t
the client to the server. A modified version of the TLS handshake can send a client’s digital c
achieving mutual authentication.

An Alternative Structure
As mentioned above, the use of different asymmetric encryption algorithms can cause small c
if the client and the server choose to use Diffie-Hellman instead of RSA, the contents of the m
slightly
In stepmodified:
2, the server will send a digitally-signed package containing the client random, serve
parameter.
After validating the digital signature, the client responds with a message containing its Diffie
premaster secret.

Using these Diffie-Hellman parameters and the client and server randoms, it is possible for the client and s
private key. In the end, Diffie-Hellman and RSA produce the same result in slightly different ways.

Types of Records
Handshake Records
CCS Records ( change Cipherspec record)
Alert Records
Application Data Record

Common Certificate Errors (Unknown/Untrusted Issuer, Expired Cert, CN Mismatch, revoked cert)
Most sites use HTTPS redirect, which means they will force you to use HTTPS and this will
IP Sec
Aggressive mode
 VPN's

IPsec Vpns - layer 3

2 types Site - Site

Remote - site

Remote PC - site
 IKE
Phase 1 ISAKMP
Main mode 6 messages UDP 500
Aggressive Mode 3 messages UDP 500

Phase 2
Quick mode 3 messages UDP 500
data transfer starts
ESP or AH

IN IF NAT device is involved

UDP 4500
NAT T

Output : Main mode, quick mode, ESP for data.

Remote access VPN Road Warriors
remote client (PC -XP to corporate gateway)
aggressive mode is used
main mode
aggressive mode

quick mode
Hash payload
Id payload
Phase 1
Main mode ( 6 msgs)
Aggressive ( 3 messages)

Phase 2
quick mode

Data
 IIS
Lab on creating a web page etc

Kerberos
Used in Single Sihn On (SSO)

Key concepts
Kerberos client – a client (an application or even an end user) requiring access to a Kerberos service.
Kerberos service – a server or an application providing something (a resource, a service, a process, data)

Key Distribution Center (KDC) – a domain service located on a domain controller (such as Active Director
 Authentication Service (AS) – authenticates the Kerberos client against the user database, and grants a T
Ticket Granting Service (TGS) – validates the client is allowed to access the requested Kerberos service a

Ticket Granting Ticket (TGT) – an encrypted identification ticket with a limited validity period used for data
Service ticket – an encrypted client-to-server ticket containing the client ID, client network address, validit

How it works

1. A Kerberos client sends its user ID in a cleartext message to the AS. The message does not include the
2. The AS checks if the client is in the user database, and if found, generates the secret key for the client
3. The Kerberos client decrypts the client/TGS session key, and sends a request message – containing the
4. The TGS decrypts the TGT in the request message to retrieve client/TGS session key, and decrypts the
5. The Kerberos client sends the service ticket and a new authenticator message encrypted with the clien
6. The Kerberos service decrypts the service ticket to retrieve the client/server session key, then decrypt
7. The Kerberos client decrypts the service confirmation message and verifies the timestamp is correct. T
cess to a Kerberos service.
ce, a service, a process, data) a Kerberos client wants to access.

roller (such as Active Directory on Windows). In Kerberos, the KDC is a single process providing two services:
 user database, and grants a Ticket Granting Ticket (TGT) for the client.
requested Kerberos service and issues a service ticket for that service. The TGS acts as the trusted third party in the Kerberos protocol.

d validity period used for data traffic protection. The TGT is used to obtain a service ticket from the TGS. The TGT contains the the client/T
client network address, validity period and client/server session key. A Kerberos client obtains this ticket from TGS after presenting a valid

message does not include the client's password, nor its secret key based on the password.
es the secret key for the client by hashing the client's password. The AS then sends a client/TGS session key and a TGT to the Kerberos clien
uest message – containing the TGT and the ID of the Kerberos service to be accessed – and an authenticator message – containing the clie
session key, and decrypts the authenticator message. The TGS verifies the Kerberos client is authorized to access the Kerberos service req
ssage encrypted with the client/server session key to the Kerberos service to be accessed.
rver session key, then decrypts the authenticator message to retrieve the client's timestamp. The Kerberos service sends a service confirm
fies the timestamp is correct. The mutual authentication is now complete. The Kerberos client can now start issuing service requests, and t
 rty in the Kerberos protocol.

TGT contains the the client/TGS session key, its expiration date, and the client's IP address protecting the client from man-in-the-middle a
m TGS after presenting a valid TGT. The service ticket is encrypted with the secret key of the Kerberos service

and a TGT to the Kerberos client. The session key is encrypted with the secret key of the client.
r message – containing the client ID and the timestamp and encrypted with the client/TGS session key – to the TGS.
ccess the Kerberos service requested, and sends a service ticket and a client/server session key encrypted with the client/TGS session key

service sends a service confirmation message including the timestamp and encrypted with the client/server session key back to the Kerber
issuing service requests, and the Kerberos service can provide the requested services for the client
lient from man-in-the-middle attacks. The TGT is encrypted with the secret key of the TGS.

ith the client/TGS session key to the Kerberos client.

session key back to the Kerberos client.

SAML
SAML - Security Assertion Markup Language, developed by the Security Services Technical Committee of "Organizati
is an XML-based framework for exchanging user authentication, entitlement, and attribute information. SAML is a d
for web applications across various domains and services.

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging

authentication and authorization data between an identity provider (IdP) such as Okta,
and a service provider (SP) such as Box, Salesforce, G Suite, Workday, etc

How SAML Works

SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service pr

Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to l

The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loa

The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the u

The user either has an existing active browser session with the identity provider or establishes one by logging into t

The identity provider builds the authentication response in the form of an XML-document containing the user’s use

The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authe

The identity of the user is established and the user is provided with app access.
 Benefits of SAML Authentication
Without much ado, the benefits of SAML authentication include:
Standardization: SAML is a standard format that allows seamless interoperability be
Improved User Experience: Users can access multiple service providers by signing in ju
Increased Security: Security is a key aspect of software development, and when it co
Reduced Costs for Service Providers: With SAML, you don't have to maintain account infor

SASS service for SAML

Layer
VPN 2
Tunnellin
g Protocol
(L2TP)
Point–to–Point Tunnelling Protocol (PPTP)
Internet Protocol Security (IPsec) Layer 3
SSL and TLS Application Layer

IPsec VPN's

Site to Site
Remote to Site

Basic functions or elements of VPN

1. Confidentiality - encryption ( symmetric - (same key on both encryption & decryption - DES, 3DES, AES etc )
( Asymmetric- ( 2 keys Public & Private - RSA, DH)
2.Intergrity - hashing - MD5, SHA etc
3.Autentication - Pre shared key , Digital certificates
4.Anti replay - would avoid duplicate packets, cookie

IPsec is security framework Flow of VPN

1 1. IKE Phase 1 ( ISAKMP Tunnel establishment)

ISAKMP - protocol Layer 3

UDP - 500
 Phase 1
Main mode Aggressive Mode
( 6 messages) ( 3 messages) Plain text

2 2. IKE Phase 2 (IPsec tunnel establishment)

Encrypted
ISAKMP - protocol Layer 7
UDP - 500
Quick mode Phase 2
( 3 messages)
Encrypted
3 Data transfer using AH of ESP Layer 3
AH = 50
ESP = 51 Protocol nos Data transfer

4 How data is going to be transferred through the tunnel

a. Tunnel mode
b. Transport mode

1 Main mode msg 1

1. Initiator cookie
2. SA payload - DOI & situation DOI - IPsec
3.Proposal payload - Proposal no, Protocol ID, transform NO
4. Transform payload - combination of Haggle paraments
5. NAT -T Support

First, the two peers independently generate a DH public value and nonce val
message 3 from initiator and message 4 from the respond

3 Main Mode Message 3

1. Key exchange Payload - DH Public key of the initiator

2. Nonce payload - Nonce of the initiator

4
 Before sending Message 5 & 6

Using these D-H values initiator and responder will create a key called DH shared secret
Three keys are generated by each peer. These keys come out to be the same on both ends due to the nature of the
SKEYID_d- This key is used to calculate subsequent IPsec keying material.
SKEYID_a- This key is used to provide data integrity and authentication to subsequ
SKEYID_e- This key is used to encrypt subsequent IKE messages.
Note : Now that both ends have the keying material generated, the rest of the IKE exchange can occur confidential

5 Main mode Message 5

1. Identity Payload - hostname or IP address

2. Hash payload - Hash_I = PRF (SKEYID,Cookie-I,Cookie-R,Pre-shared key(PK-I),SA P
The hash is used for authentication purposes. The responder calculates the same hash on its end. If the t
said to have taken place.

In this message 5, we can’t able to see the information because as we discussed it will be encrypted with the SKE
because they have the same SKEYID_e with the help of D-H nature.

6 Main mode Message 6

1. Decrypt the message using

2. Calculate Hash_R on its ow
3.If received Hash_I = calcula

Message 6 reply
1. Identity Payload - hostnam
2. Hash payload -

In this message 6, we can’t able to see the information because as we discussed it will be en
identity payload & hash payload. After these message phase 1 tunnel will come up.

Once message 6 is received by the Initiator

At this point, the IKE SA is established, and main mode using preshared key authentication is complete. The next ste
discussed in the next section.

Quick mode
IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has
IKE phase 2 performs the following negotiations:

❖IPsec Protocol: do we use AH or ESP?

❖Encapsulation Mode: transport or tunnel mode?
❖Encryption: what encryption algorithm do we use? DES, 3DES or
❖Authentication: what authentication algorithm do we use? MD5
❖Lifetime: how long is the IKE phase 2 tunnel valid? When the tun

All the Phase 2 quick mode messages are encrypted by SKEYID_e

Quick Mode message 1

1. Hash payload
2. SA Payload
3. Proposal payload - AH & ESP
4. Transform payload - Tunnel or Transport
5. ID payload IDs - Source Proxy ( referred as interesting traffic , LAN Networks of booth peers
IDd - Dst Proxy
6. Note : PFS is optional
IF PFS is requested - DH public value of Initiator& Initiator Nonce value is also shafted to responder

These are the information which will be carried by the phase 2 me

encrypted so we are not able to see in packet captures. Encrypted
1.
Quick Mode Message 2

Proposal & transform payload - accept

ID payload
Hash payload
back to initiator

Before sending Message 3 in quick

Initiator generates IPsec keying material :
IPsec session key for incoming IPsec SA = PRF (SKEYID_d, protocol (ISAKMP),
IPsec session key for outgoing IPsec SA = PRF (SKEYID_d, protocol (ISAKMP), n
Responder generates IPsec keying material :
IPsec session key for incoming IPsec SA = PRF (SKEYID_d, protocol (ISAKMP),
IPsec session key for outgoing IPsec SA = PRF (SKEYID_d, protocol (ISAKMP), n

Quick Mode Message 3

The last message of the IKE exchange is sent to verify the liveness of th
After message 3 has been received by the receiver, IPsec's quick mode is concluded. All the goals of IKE-a
encryption algorithm, and other attributes needed to generate the encrypted packets-have been negotia
can be used to exchange encrypted traffic.

Phase 1 & Phase 2 are established

Encrypted datatrafer using AH or ESP will start.
nical Committee of "Organization for the Advancement of Structured Information Standards" (OASIS),
ibute information. SAML is a derivative of XML. The purpose of SAML is to enable Single Sign-On

der) to another (the service provider). This is done through an exchange of digitally signed XML documents.

y provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The followin

similar and the application loads.

, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.

tablishes one by logging into the identity provider.

ment containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider

fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
ess interoperability between systems, independent of implementation. It takes away the comm
viders by signing in just once, without additional authentication, allowing for a faster and better
ment, and when it comes to enterprise applications, it is extremely important. SAML provides
aintain account information accross multiple services. The identity provider bears this burden.

ryption - DES, 3DES, AES etc )

Note: Pvt is never shared.
 Main mode mgs 1
Main mode mgs 2
Main mode mgs 3 All 6 messages
Main mode mgs 4 ISAKMP
Main mode mgs 5 Src P: 500 Dst P: 500
Main mode mgs 6
ISAKMP Tunnel establishment

Quick mode mgs 1 All 3 messages

Quick mode mgs 2 ISAKMP
Quick mode mgs 3 Src P: 500 Dst P: 500
IPsec tunnel establishment
ESP data transfer Encrypted data transfer
ESP data transfer Data transfer ( AH or ESP)
ESP data transfer layer 3

Main mode Message 2

1. Responder Cookie
2. SA payload - DOI & situation DOI - IPsec
3. Proposal Accept
4. NAT -T Support

value and nonce value before sending the

e 4 from the responder.

Main Mode Message 3

 1. Key exchange Payload - DH Public key of the responder
2. Nonce payload - Nonce of the responder

ends due to the nature of the DH exchange. These keys are called session keys (SKEYs).
ing material.
entication to subsequent IKE messages.

change can occur confidentially using encryption done using SKEYID_e.

shared key(PK-I),SA Payload, proposal + Transforms ID_I)

e same hash on its end. If the two hashes come out to be the same, authentication is

l be encrypted with the SKEYID_e. Responder can able to decrypt

-H nature.

Main mode Message 6

1. Decrypt the message using SKEYID_E.

2. Calculate Hash_R on its own.
3.If received Hash_I = calculated Hash_R, authentication is successful!

Message 6 reply
1. Identity Payload - hostname or IP address
2. Hash payload - Hash_I = PRF (SKEYID,Cookie-I,Cookie-R,Pre-shared key(PK-I),SA Payload, proposa

e discussed it will be encrypted with the SKEYID_e. It will have the

unnel will come up.

ation is complete. The next step, quick mode, is

e occurs after IKE has established the secure tunnel in phase 1

we use? DES, 3DES or AES?
hm do we use? MD5 or SHA?
l valid? When the tunnel is about to expire, we will refresh the keying material.

KEYID_e which is created by phase 1.

LAN Networks of booth peers. )

also shafted to responder

by the phase 2 message 1. These information's are

captures. Encrypted by SKEYID_e which is created by phase

3 in quick mode
_d, protocol (ISAKMP), new DH shared secret, SPIr, Ni', Nr')
d, protocol (ISAKMP), new DH shared secret, SPIi, Ni', Nr')

_d, protocol (ISAKMP), new DH shared secret, SPIi, Ni', Nr')

d, protocol (ISAKMP), new DH shared secret, SPIr, Ni', Nr')

rify the liveness of the responder. It will send the Hash payload in this message.
oncluded. All the goals of IKE-authentication, negotiation of the
ted packets-have been negotiated. Now the agreed-on IPsec SAs
service provider). The following happens:

tication request.

mation to the service provider.

akes away the common problems associated with vendor and platform-specific architecture an
or a faster and better experience at each service provider. This eliminates password issues su
ant. SAML provides a single point of authentication, which happens at a secure identity provid
er bears this burden.
I),SA Payload, proposal + Transforms ID_I)
 ecific architecture and implementation.
s password issues such as reset and recovery.
secure identity provider. Then, SAML transfers the identity to service providers. This form of a
viders. This form of authentication ensures that credentials don't leave the firewall boundary.
e firewall boundary.
 Layer
VPN 2
Tunnellin
g Protocol
(L2TP)
Point–to–Point Tunnelling Protocol (PPTP)
Internet Protocol Security (IPsec) Layer 3
SSL and TLS Application Layer

IPsec VPN's

Site to Site
Remote to Site

Basic functions or elements of VPN

1. Confidentiality - encryption ( symmetric - (same key on both encryption & decryption - DES, 3DES, AES etc )
( Asymmetric- ( 2 keys Public & Private - RSA, DH)
2.Intergrity - hashing - MD5, SHA etc
3.Autentication - Pre shared key , Digital certificates
4.Anti replay - would avoid duplicate packets, cookie

IPsec is security framework Flow of VPN

1 1. IKE Phase 1 ( ISAKMP Tunnel establishment)

ISAKMP - protocol Layer 3

UDP - 500

Phase 1
Main mode Aggressive Mode
( 6 messages) ( 3 messages) Plain text

2 2. IKE Phase 2 (IPsec tunnel establishment)

Encrypted
ISAKMP - protocol Layer 7
UDP - 500
Quick mode Phase 2
( 3 messages)
Encrypted
3 Data transfer using AH of ESP Layer 3
AH = 50
ESP = 51 Protocol nos Data transfer

4 How data is going to be transferred through the tunnel

a. Tunnel mode
b. Transport mode

1 Main mode msg 1

 1. Initiator cookie
2. SA payload - DOI & situation DOI - IPsec
3.Proposal payload - Proposal no, Protocol ID, transform NO
4. Transform payload - combination of Haggle paraments
5. NAT -T Support

First, the two peers independently generate a DH public value and nonce val
message 3 from initiator and message 4 from the respond

3 Main Mode Message 3

1. Key exchange Payload - DH Public key of the initiator

2. Nonce payload - Nonce of the initiator

Before sending Message 5 & 6

Using these D-H values initiator and responder will create a key called DH shared secret
Three keys are generated by each peer. These keys come out to be the same on both ends due to the nature of the
SKEYID_d- This key is used to calculate subsequent IPsec keying material.
SKEYID_a- This key is used to provide data integrity and authentication to subsequ
SKEYID_e- This key is used to encrypt subsequent IKE messages.
Note : Now that both ends have the keying material generated, the rest of the IKE exchange can occur confidential

5 Main mode Message 5

1. Identity Payload - hostname or IP address

2. Hash payload - Hash_I = PRF (SKEYID,Cookie-I,Cookie-R,Pre-shared key(PK-I),SA P
The hash is used for authentication purposes. The responder calculates the same hash on its end. If the t
said to have taken place.

In this message 5, we can’t able to see the information because as we discussed it will be encrypted with the SKE
because they have the same SKEYID_e with the help of D-H nature.
In this message 5, we can’t able to see the information because as we discussed it will be encrypted with the SKE
because they have the same SKEYID_e with the help of D-H nature.

6 Main mode Message 6

1. Decrypt the message using

2. Calculate Hash_R on its ow
3.If received Hash_I = calcula

Message 6 reply
1. Identity Payload - hostnam
2. Hash payload -

In this message 6, we can’t able to see the information because as we discussed it will be en
identity payload & hash payload. After these message phase 1 tunnel will come up.

Once message 6 is received by the Initiator

At this point, the IKE SA is established, and main mode using preshared key authentication is complete. The next ste
discussed in the next section.

Quick mode
IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has

IKE phase 2 performs the following negotiations:

❖IPsec Protocol: do we use AH or ESP?

❖Encapsulation Mode: transport or tunnel mode?
❖Encryption: what encryption algorithm do we use? DES, 3DES or
❖Authentication: what authentication algorithm do we use? MD5
❖Lifetime: how long is the IKE phase 2 tunnel valid? When the tun

All the Phase 2 quick mode messages are encrypted by SKEYID_e

Quick Mode message 1

1. Hash payload
2. SA Payload
3. Proposal payload - AH & ESP
4. Transform payload - Tunnel or Transport
5. ID payload IDs - Source Proxy ( referred as interesting traffic , LAN Networks of booth peers
IDd - Dst Proxy
6. Note : PFS is optional
IF PFS is requested - DH public value of Initiator& Initiator Nonce value is also shafted to responder

These are the information which will be carried by the phase 2 me

encrypted so we are not able to see in packet captures. Encrypted
1.
Quick Mode Message 2

Proposal & transform payload - accept

ID payload
Hash payload
back to initiator

Before sending Message 3 in quick

Initiator generates IPsec keying material :
IPsec session key for incoming IPsec SA = PRF (SKEYID_d, protocol (ISAKMP),
IPsec session key for outgoing IPsec SA = PRF (SKEYID_d, protocol (ISAKMP), n
Responder generates IPsec keying material :
IPsec session key for incoming IPsec SA = PRF (SKEYID_d, protocol (ISAKMP),
IPsec session key for outgoing IPsec SA = PRF (SKEYID_d, protocol (ISAKMP), n

Quick Mode Message 3

The last message of the IKE exchange is sent to verify the liveness of th

After message 3 has been received by the receiver, IPsec's quick mode is concluded. All the goals of IKE-a
encryption algorithm, and other attributes needed to generate the encrypted packets-have been negotia
can be used to exchange encrypted traffic.

Phase 1 & Phase 2 are established

Encrypted datatrafer using AH or ESP will start.
ryption - DES, 3DES, AES etc )
Note: Pvt is never shared.

Main mode mgs 1

Main mode mgs 2
Main mode mgs 3 All 6 messages
Main mode mgs 4 ISAKMP
Main mode mgs 5 Src P: 500 Dst P: 500
Main mode mgs 6
ISAKMP Tunnel establishment

Quick mode mgs 1 All 3 messages

Quick mode mgs 2 ISAKMP
Quick mode mgs 3 Src P: 500 Dst P: 500
IPsec tunnel establishment
ESP data transfer Encrypted data transfer
ESP data transfer Data transfer ( AH or ESP)
ESP data transfer layer 3
 Main mode Message 2

1. Responder Cookie
2. SA payload - DOI & situation DOI - IPsec
3. Proposal Accept
4. NAT -T Support

value and nonce value before sending the

e 4 from the responder.

Main Mode Message 3

1. Key exchange Payload - DH Public key of the responder

2. Nonce payload - Nonce of the responder

ends due to the nature of the DH exchange. These keys are called session keys (SKEYs).
ing material.
entication to subsequent IKE messages.

change can occur confidentially using encryption done using SKEYID_e.

shared key(PK-I),SA Payload, proposal + Transforms ID_I)

e same hash on its end. If the two hashes come out to be the same, authentication is

l be encrypted with the SKEYID_e. Responder can able to decrypt

-H nature.
 l be encrypted with the SKEYID_e. Responder can able to decrypt
-H nature.

Main mode Message 6

1. Decrypt the message using SKEYID_E.

2. Calculate Hash_R on its own.
3.If received Hash_I = calculated Hash_R, authentication is successful!

Message 6 reply
1. Identity Payload - hostname or IP address
2. Hash payload - Hash_I = PRF (SKEYID,Cookie-I,Cookie-R,Pre-shared key(PK-I),SA Payload, proposa

e discussed it will be encrypted with the SKEYID_e. It will have the

unnel will come up.

ation is complete. The next step, quick mode, is

e occurs after IKE has established the secure tunnel in phase 1

we use? DES, 3DES or AES?

hm do we use? MD5 or SHA?
l valid? When the tunnel is about to expire, we will refresh the keying material.

KEYID_e which is created by phase 1.

LAN Networks of booth peers. )

also shafted to responder

by the phase 2 message 1. These information's are

captures. Encrypted by SKEYID_e which is created by phase
 3 in quick mode
_d, protocol (ISAKMP), new DH shared secret, SPIr, Ni', Nr')
d, protocol (ISAKMP), new DH shared secret, SPIi, Ni', Nr')

_d, protocol (ISAKMP), new DH shared secret, SPIi, Ni', Nr')

d, protocol (ISAKMP), new DH shared secret, SPIr, Ni', Nr')

rify the liveness of the responder. It will send the Hash payload in this message.

oncluded. All the goals of IKE-authentication, negotiation of the

ted packets-have been negotiated. Now the agreed-on IPsec SAs
I),SA Payload, proposal + Transforms ID_I)