Advanced Topics in Encryption Standards and Protocols 2006 Cisco

Advanced Topics in Encryption
Standards and Protocols
SESSION SEC-4011
Saadat Malik
Sr. Manager, Software Development
Critical Infrastructure Assurance Group (CIAG)
SEC-4011
12470_04_2006_c1 © 2006 Cisco Systems, Inc. All rights reserved. Cisco Public 1
Agenda
• Analysis of Mainline Protocols

IKE V1: Current IPSec Negotiation Flow
IKE V2: New IPSec Negotiation Flow
SSH: Secure Shell Services
SSL/TLS: Secure Application Transport
• Analysis of Underlying Standards

Authentication Framework: PKI
Hashing Techniques: SHA and MD5
Encryption Protocols: 3DES and AES
• New Directions in Cryptography Standards

GCM: High Speed Authenticated Encryption
ECC: Elliptic Curve Cryptography in IPSec
SEC-4011
Agenda



SEC-4011
IPSec Composition
IPSec Combines Three Protocols into a

Cohesive Security Framework
Provides Framework for the Negotiation

IKE of Security Parameters and
Establishment of Authenticated Keys
Provides Framework for the

ESP Encrypting, Authenticating and
Securing Data
Provides Framework for the

AH
Authenticating and Securing Data
SEC-4011
What Is IKE?
IKE (Internet Key Exchange) (RFC 2409)

Is a Hybrid Protocol
SKEME Oakley
Mechanism for Utilizing Modes-Based Mechanism for
Public Key Encryption Arriving at an Encryption Key
for Authentication Between Two Peers
ISAKMP
Architecture for Message
Exchange Including Packet
Formats and State Transitions
Between Two Peers
SEC-4011
Why IKE?
IKE Solves the Problems of Manual

and Unscalable Implementation of IPSec by
Automating the Entire Key Exchange Process
• Negotiation of SA characteristics
• Automatic key generation
• Automatic key refresh
• Manageable manual configuration
SEC-4011
How Does IKE Work?
IKE Is a TWO Phase Protocol
Phase 1 Exchange
Peers Negotiate a Secure, Authenticated Channel with Which to
Communicate ‘Main Mode’
or ‘Aggressive Mode’ Accomplish a Phase I Exchange
Phase 2 Exchange
Security Associations Are Negotiated on Behalf of IPSec Services;
‘Quick Mode’ Accomplishes a Phase II Exchange
SEC-4011
How Does IKE Work?
Phase I SA (ISAKMP SA)
Main Mode Aggressive Mode

(6 Messages) (3 Messages)
New IPSec Tunnel or Rekey
Phase II SA Phase II SA
(IPSec SA) (IPSec SA)
Quick Mode Quick Mode
A Protected Data B C Protected Data D
SEC-4011
IKE Phase 1 (Main Mode): Preparation for
Sending ‘Message 1 and 2’
Goal: Negotiation of IKE SA Parameters
Generation of Initiator Cookie

An 8 Byte Pseudo-Random Number Used for Anti-Clogging
CKY-I = md5{Date and Time, (src_ip, dest_ip), Random Number}
Generation of Responder Cookie

CKY-R = md5{Date and Time, (src_ip, dest_ip), Random Number}
SEC-4011
IKE Phase 1 (Main Mode):
Sending ‘Message 1’
The Initiator Proposes a Set of Attributes to Base the SA On
Initiator Responder
Initiator Cookie (Calculated and Inserted Here)
Responder Cookie (Left 0 for Now) DOI Identifies the Exchange
SA Version Exchange Flags to Be Occurring to Setup IPSec
Message ID SPI = 0 for All Phase
Total Message Length 1 Messages
Next Payload 1 SA Payload Length Includes Proposal #,
SA Payload (Includes DOI and Situation) Protocol ID, SPI Size,
Next Payload 1 Proposal Payload Length # of Transforms, SPI
Proposal Payload (Two Proposals Shown Here)
Next Payload 1 Transform Payload Length Includes Transform #,
Transform Payload Transform ID, SA Attributes,
Next Payload 1 Proposal Payload Length for Example, DES, MD5,
Proposal Payload DH 1, Pre Share, Timeout
0 1 Transform Payload Length (Two Transform Sets
Transform Payload
Shown Here)
SEC-4011
The Responder Sends Back the One Set of Attributes Acceptable to It
Initiator Responder
Initiator Cookie (Same as Before)

Responder Cookie (Calculated and Inserted Here) DOI Identifies the Exchange
SA Version Exchange Flags to be Occurring to
Message ID Setup IPSec
Total Message Length PROTO_ISAKMP,
Next Payload 1 SA Payload Length SPI = 0 for All Phase
SA Payload (Includes DOI and Situation) 1 Messages
Next Payload 1 Proposal Payload Length
Proposal Payload (Includes Proposal #, Protocol ID, SPI
Size, # of Transforms, SPI)
0 1 Transform Payload Length KEY_OAKLEY = Type
Transform Payload (Includes Transform #, DES, MD5, DH 1
Transform ID, SA Attributes) Pre-Share
SEC-4011
Goal: Exchange of Information Required for Key

Generation Using DH Exchange
Generation of DH Public Value by Initiator

DH Public Value = Xa
Xa = ga mod p
Where g Is the Generator and p a Large Prime Number
and a Is a Private Secret Known Only to the Initiator
Generation of DH Public Value by Responder

DH Public Value = Xb
Xb = gb mod p
and b Is a Private Secret Known Only to the Responder
SEC-4011
Generation of a Nonce by Initiator

Nonce Is a Very Large Random Number
Initiator Nonce = Ni
Generation of a Nonce by Responder

Responder Nonce = Nr
SEC-4011
The Initiator Sends Its DH Public Value Xa and Nonce Ni
Initiator Responder
Responder Cookie (Same as Before)

Next Payload Version Exchange Flags
Message ID DH Public Value = Xa
Total Message Length
Next Payload 0 KE Payload
Length
KE Payload (Includes DH Public Value)
0 0 Nonce Payload Length Nonce = Ni
Nonce Payload (Includes Nonce)
SEC-4011
The Responder Sends Its DH Public Value Xb and Nonce Nr
Initiator Responder

Message ID DH Public Value = Xb
Length
0 0 Nonce Payload Length Nonce = Nr
SEC-4011
Goal: Exchange of Authentication

Information Using DH
Calculation of the Shared DH Secret by Initiator
Shared Secret = (Xb)a mod p (Xb)a mod p =

(Xa)b mod p
=
gab
Calculation of the Shared DH Secret by Responder
Shared Secret = (Xa)b mod p
SEC-4011
Calculation of Three Keys (Initiator)

SKEYID_d—Used to Calculate Subsequent IPSec Keying Material
SKEYID_a—Used to Provide Data Integrity and Authentication
to IKE Messages
SKEYID_e—Used to Encrypt IKE Messages
SKEYID = PRF (Ni | Nr gab)
SKEYID_d = PRF (SKEYID, gab | CKY-I | CKY-R | 0)
SKEYID_a = SKEYID_e =
PRF (SKEYID, SKEYID_d | gab | CKY-I | CKY-R | 1) PRF (SKEYID, SKEYID_a | gab | CKY-I | CKY-R | 2)
SEC-4011
Calculation of Three Keys (Responder)

to IKE Messages
SKEYID = PRF (Ni | Nr gab)
SEC-4011
(Digital Signatures) Sending ‘Message 5’
The Initiator Sends Its Authentication Material and ID
Initiator Responder

Identification of Responder
KE Version Exchange Flags
(ID_I)
Message ID Such as Host Name or
Total Message Length IP Address
Next Payload 0 Identity Payload Length
ID Type DOI Specific ID Data Signature
Identity Payload =
SKEYID_e
Next Payload 0 Hash_I Encrypted with Priv_I

Signature Payload Length
=
Signature Data Priv_I {PRF (SKEYID, CKY-I,
0 0 Certificate Payload Length CKY-R, SA Payload,
Certificate Data Proposals+Transforms,
Certificate Encoding
ID_I)}
Certificate Data
SEC-4011
(Digital Signatures) Sending ‘Message 6’
The Responder Sends Its Authentication Material and ID
Initiator Responder

(ID_I)
Message ID Such as Host Name or
Total Message Length IP Address
ID Type DOI Specific ID Data Signature
Identity Payload =
SKEYID_e
Next Payload 0 Hash_R Encrypted with Priv_R

Signature Payload Length
=
Signature Data Priv_R {PRF (SKEYID, CKY-I,
0 0 Certificate Payload Length CKY-R, SA Payload,
Certificate Data Proposals+Transforms,
Certificate Encoding
ID_R)}
Certificate Data
SEC-4011
IKE Phase 1 (Main Mode): Completion of
Phase 1
• Initiator authenticates the responder

1. Decrypt message using SKEYID_E
2. Decrypt Hash_R using Pub_R
3. Calculate Hash_R on its own
4. If received Hash_R = self-generated Hash_R then
authentication = successful!!
• Responder authenticates the initiator
ISAKMP SA
1. Decrypt message using SKEYID_E Established!
2. Decrypt Hash_I using Pub_I
3. Calculate Hash_I on its own
4. If received Hash_I = self-generated Hash_I then
SEC-4011
IKE Phase 1 (Quick Mode): Preparation for
Goal: Negotiation of IPSec SA
Execution of DH by Initiator Again to Ensure PFS
New Nonce Generated: Ni’

New DH Public Value = Xa’
Xa’ = ga mod p
Execution of DH by Responder Again to Ensure PFS
New Nonce Generated: Nr’

New DH Public Value = Xb’
Xb’ = gb mod p
SEC-4011
IKE Phase 2 (Quick Mode):
The Initiator Sends Authentication/Keying Material and
Proposes a Set of Attributes to Base the SA On
Initiator Responder

Message ID
SEC-4011
SA 0 Hash Payload
Hash Payload Hash =PRF (SKEYID_a,
Next Payload 0 SA Payload Length Message ID, Ni’, Proposals+
SA Payload (Includes DOI and Situation) Transforms, Xa)
Next Payload 0 Proposal Payload Length Proposal:
Proposal Payload ESP or AH, SHA or MD5,
Next Payload 0 Transform Payload Length
DH 1 or 2, SPI
Transform Payload
(Two Proposals
Shown Here)
SKEYID_e
Proposal Payload
Transform Payload
Transform:
Next Payload 0 Keyload Payload Length
Tunnel or Transport,
IPSec Timeout
KE Payload
Next Payload 0 Nonce Payload Length
Nonce Payload (Ni’) KE Payload = Xa’
ID Type DOI Specific ID Data
Identity Payload = ID-s
0 0 Identity Payload Length
ID-s = Source Proxy
ID-d = Destination Proxy
Identity Payload = ID-d
SEC-4011
The Responder Sends Authentication/Keying Material and
Proposes a Set of Attributes to Base the SA on
Initiator Responder

Message ID
SEC-4011
Hash =
Next Payload 0 Hash Payload Length
PRF (SKEYID_a, Message ID
Hash Payload Ni’, Nr’, Accepted Proposal+
Next Payload 0 SA Payload Length Transform, Xb)
SA Payload (Includes DOI and Situation)
Proposal Payload (Accepted Proposal)
SKEYID_e
Transform Payload (Accepted Transform) with Responder’s SPI

Next Payload 0 KE Payload Length
KE Payload
Nonce Payload (Nr’)
Next Payload 0 Identity Payload Length KE Payload = Xb’
Identity Payload = ID-s (Generally Similar to ID-d for Initiator)
Identity Payload = ID-d (Generally Similar to ID-s for Initiator)
SEC-4011
IKE Phase 2 (Quick Mode): Completion of
Phase 2
• Initiator generates IPSec keying material

1. Generate new DH shared secret = (Xb’)a mod p
2. IPSec session key = PRF (SKEYID_d, protocol
(ISAKMP), new DH shared secret, SPIr, Ni’, Nr’)
• Responder generates IPSec keying material

1. Generate new DH shared secret = (Xa’)b mod p
(ISAKMP), new DH shared secret, SPIi, Ni’, Nr’)
SEC-4011
The Initiator Sends Across a Proof of Liveness
Initiator Responder
Initiator Cookie (Same as Before) Hash

Responder Cookie (Same as Before) =
KE Version Exchange Flags PRF (SKEYID_a, Message ID,
Message ID Ni’, Nr’)
SKEYID_e

0 0 Hash Payload Length
Hash Payload IPSec SA
Established!
SEC-4011
One Page Summary: Signatures Main Mode
Initiator IKE Responder
DES HDR, SAProposal DES DES

MD5 MD5 SHA
DH 1 DH 1 DH 2
Rsa-Sig HDR, SAchoice Rsa-Sig Pre-Share
Phase I SA Parameter Negotiation Complete

Generate
DH Public Value HDR, KEI, NonceI [,cert_req]
and Nonce
Generate
HDR, KER, NonceR [,cert_req] DH Public Value
and Nonce
DH Key Exchange Complete, Share Secret Derived
Nonce Exchange Defeat Replay, Optional cert_req
HASHI=HMAC(SKEYID,
KEI|KER|cookieI| HDR*, IDI [,certI], SignatureI
cookieR|SA|IDI)
HASHR=HMAC(SKEYID,
HDR*, IDR [,certR],signature KER|KEI|cookieR|
cookieI|SA|IDR)
IDs Are Exchanged, Signature Is Verified for Authentication
ID and Signature Are Encrypted by Derived Shared Secret
SEC-4011
One Page Summary: Quick Mode
Initiator IPSec Responder
ESP ESP
DES HDR*, HASH1, Saproposal, NonceI [,KEI] [,IDCI,IDCR] DES
SHA SHA
PFS 1 PFS 1
HDR*, HASH2, SAchoice, NonceR, [,KER] [,IDCI,IDCR]
HDR*, HASH3
SEC-4011
Agenda



SEC-4011
IKE v2: Replacement for Current IKE
Specification
• Feature preservation
Most of the features and characteristics of the baseline
parent IKE v1 protocol are preserved in v2
• Compilation of features and extensions

Quite a few features that were added on top of the baseline
IKE protocol functionality in v1 are reconciled into the
mainline v2 framework
• New features
A few new mechanisms and features have been introduced
in the IKE v2 protocol as well
SEC-4011
IKE v2: What has not Changed
• Features in v1 that have been debated but are

ultimately preserved in v2
Most payloads reused
Use of nonces to ensure uniqueness of keys
• v1 extensions and enhancements merged into

mainline v2 specification
Use of a ‘configuration payload’ similar to MODECFG for
address assignment
‘X-auth’ type functionality retained through EAP
Use of NAT Discovery and NAT Traversal techniques
SEC-4011
IKE v2: What has Changed
Significant Changes Being Made to the

Baseline Functionality of IKE
• EAP adopted as the method to provide legacy
authentication integration with IKE
• Public signature keys and pre-shared keys, the only
methods of IKE authentication
• Use of ‘stateless cookie’ to avoid certain types of
DOS attacks on IKE
• Continuous phase of negotiation
SEC-4011
How Does IKE v2 Work?
IKE_SA_INIT IKE_SA Authentication

(Two Messages) Parameters Negotiated
IKE_AUTH IKE Authentication Occurs

(Two Messages) and One CHILD_SA Created
CREATE_CHILD_SA
(Two Messages) Second CHILD_SA Created
A Protected Data B
SEC-4011
IKE_SA_INIT: ‘Message 1’
The Initiator Proposes Basic SA Attributes
Along with Authentication Material
Initiator Responder
Initiator SPI
Responder SPI (Left 0 for Now)
Next Payload Version Exchange Flags Critical Bit: Request Rejection
Message ID of Entire Message if This
Total Message Length Payload Not Understood
Next Payload C 0 SA Payload Length
SA Payload (Includes Proposal and Transform Info)
Next Payload C 0 KE Payload Length
Key Exchange Payload (Includes DH Public Value) DH Public Value Is Guessed
Next Payload C 0 Nonce Payload Length
Nonce
SEC-4011
IKE_SA_INIT: ‘Message 2’
The Responder Sends Back the One Set of Attributes Acceptable
to It Along with Authentication Material
Initiator Responder
Initiator SPI (Same as Before)

Responder SPI (Calculated and Inserted Here)
Includes Accepted Transforms
Message ID
and Proposals
SA Payload (Includes Proposal and Transform Info)
Next Payload C 0 KE Payload Length
Key Exchange Payload (Includes DH Public Value)
Nonce
SEC-4011
IKE_AUTH: ‘Message 3’
Authentication Material Along with CHILD_SA Info Sent
Initiator Responder
Initiator SPI
Responder SPI Includes an Identity for the
Next Payload Version Exchange Flags Initiator
Message ID
Total Message Length Auth Payload = hash(hash(
Next Payload C 0 ID Payload Length Shared Secret, “Key Pad for
ID Payload (Contains Initiator ID) IKEv2”, All Octets from First Init
Message, Ni, hash(SK_ar, IDr)))
SK_e and SK_a
Next Payload C 0 Auth Payload Length

Authentication Payload Includes SA, Proposal and
Next Payload C 0 SA Payload Length Transform Info to Create the
SA Payload for first CHILD_SA 1st CHILD_SA
Next Payload C 0 TS Payload Length Traffic Selectors Include Source
Traffic Selector Payload and Destination Proxies
0 C 0 TS Payload Length
Traffic Selector Payload
SEC-4011
IKE_AUTH: ‘Message 4’
Authentication Material Along with CHILD_SA Info Sent
Initiator Responder
Initiator SPI
Responder SPI
Responder Identity
Message ID
Next Payload C 0 ID Payload Length
ID Payload (Contains Responder ID) Calculated Similar to the
Initiator Calculation
SK_e and SK_a
Next Payload C 0 Auth Payload Length

Authentication Payload
SA Payload for first CHILD_SA
Next Payload C 0 TS Payload Length
0 C 0 TS Payload Length
SEC-4011
CREATE_CHILD_SA: ‘Message 5’
Initiator Responder
Initiator SPI
Includes SA, Proposal and
Responder SPI
Transform Info to Create the
Exchange Flags
2nd CHILD_SA
Message ID
SA, Proposal and Transform Info for 2nd CHILD_SA
SK_e and SK_a

Nonce
Next Payload C 0 TS Payload
Initiator Length
Traffic Selector
Traffic Selector
SEC-4011
CREATE_CHILD_SA: ‘Message 6’
Initiator Responder
Initiator SPI
Responder SPI
Exchange Flags
Includes Agreed upon SA Info
Message ID
SA, Proposal and Transform Info for 2nd CHILD_SA
SK_e and SK_a

Nonce
Next Payload C 0 TS Payload
Initiator Length
Traffic Selector
Traffic Selector
SEC-4011
Agenda



SEC-4011
SSH
• SSH
RFCs 4250-4254
• OSI layer placement

Runs above TCP or any other reliable transport
• Goals of protocol
Secure remote logins and other secure services
IDs define standard methods for secure interactive shells,
tunneling TCP/IP ports and X11 connections
Authentication + privacy + integrity
SEC-4011
SSH Composition
SSH Is a Combination of Three Protocols

Running over One Another
SSH Connection Protocol

Runs over User Authentication Protocol and Multiplexes
the Encrypted Tunnel Into Several Logical Channels
SSH User Authentication Protocol

Runs over the Transport Layer Protocol
and Authenticates Client to the Server
SSH Transport Layer Protocol

Runs over TCP and Provides for Server Authentication,
Confidentiality and Integrity
SEC-4011
How Does SSH Negotiation Work?
SSH Session Is Negotiated Through Three Stages
Transport Layer Protocol Negotiation

Used to Agree upon Algorithms for Encryption and Integrity
as Well as Exchange DH Keys
User Authentication Protocol Negotiation

Used to Agree upon a Method for and Then Carry Out User Authentication
Connection Protocol Negotiation

Used to Negotiate Parameters of a Channel to Be Open Channels
for Communication of Data
SEC-4011
Version String Exchange:
‘Message 1’
The Client Sends a Version String to the Server
to Establish Basic Capabilities
Client Server
Protocol Version = 2.0

TCP Payload
TCP Header Software Version Is Used

Version String to Trigger Extension and
Further Capabilities of a
Software Implementation
Contains ASCII String =

SSH-protoversion-softwareversion
SP comments CR LF
‘Please Note that the Packet Diagrams Shown Here Are for
Illustration Purposes and May Not Accurately Depict the
Relative Sizes or Byte Boundary Placement of the Various
Fields; Certain Fields Such as Padding May Also Not Be Shown
to Conserve Space’
SEC-4011
Version String Exchange:
‘Message 2’
The Server Sends a Version String to the Client to
Establish Basic Capabilities
Client Server
Protocol Version = 2.0

TCP Payload
TCP Header Software Version Is Used

Version String to Trigger Extension and
Further Capabilities of a
Software Implementation
SEC-4011
Key Exchange Initialization (KEXINIT):
‘Message 3’
The Client Lists for the Server Options It Is Willing to Support for
Encryption, Integrity and Compression Algorithms in Each Direction
Client Server
Packet Length Padding Length

KEXINIT Cookie Random Number
Key Exchange Algorithms Usually DH Algorithms
Server Host Key Algorithms Client Lists Algorithms It Is
Client to Server Encryption Algorithms Willing to Accept for Verifying
Server to Client Encryption Algorithms Server’s Host Key
Client to Server MAC Algorithms Language Tag
Server to Client MAC Algorithms
Client to Server Languages The Client Guesses What
Keyexchange Algorithm the
Server to Client Languages
Server Would Want to Use
First Key Exchange Message Follows = 1 or 0
and Indicates That the First
Message of That Exchange
Follows
SEC-4011
Key Exchange Initialization (KEXINIT):
‘Message 4’
The Server Lists for the Client Options It Supports for
Encryption, Integrity and Compression Algorithms in Each Direction
Client Server

KEXINIT Cookie
Key Exchange Algorithms
Server Host Key Algorithms
The Server Guesses What
Client to Server Encryption Algorithms Keyexchange Algorithm the
Server to Client Encryption Algorithms Client Would Want to Use
Client to Server MAC Algorithms and Indicates That the First
Server to Client MAC Algorithms Message of That Exchange
Client to Server Languages Follows
Server to Client Languages
First Key Exchange Message Follows = 1 or 0
SEC-4011
DH Key Exchange:
‘Message 5’
The Client Initiates DH Exchange
Client Server

SSH_MSG_KEXDH_INIT
e
e = gx mod p Where x Is a Random Number

Between 1 and q, Where q Is the Order of the DH
Group, g Is a Generator for the Group and p Is
a Large Safe Prime
SEC-4011
DH Key Exchange:
‘Message 6’
The Server Responds with DH Key Material Along with
Information to Prove Its Identity
Client Server
K_S = Server Public Host Key;

The Client Must Verify,
SSH_MSG_KEXDH_REPLY Through a Local Database
K_S or PKI Mechanism That This
f Key Is Really the Host Key
Signature of H of the Server It Is Trying to
Connect to
f = gy mod p Where y Is a
Signature of H = Spriv(hash(client version string | Random Number
server version string| client kexinit message |
server kexinit message | K_S | e | f | K)
where K = ey mod p
SEC-4011
Calculation of Keys
Client Side Calculations
Encryption Key Client to Server = Hash (K | H | "C" | Session_id)

Integrity Key Client to Server = Hash (K | H | "E" | Session_id)
Server Side Calculations
Integrity Key Server to Client = Hash (K | H | "F" | Session_id)

Encryption Key Server to Client = Hash (K | H | "D" | Session_id)
Where Session_id = H From the Very First Key Exhange, Meaning That Subsequent
Key Exchanges Within This Session Will Use the Hash Calculated First Time, as
the Session Identifier; and Where H = Spriv(hash(client Version String | Server
Version String| Client Kexinit Message | Server Kexinit Message | K_s | E | F | K)
SEC-4011
Key Exchange Conclusion (NEWKEYS):
‘Message 7’
The Client Informs the Server That It Is About to Start

Using Newly Generated Keys
Client Server

SSH_MSG_NEWKEYS
SEC-4011
Key Exchange Conclusion (NEWKEYS):
‘Message 8’
The Server Informs the Client That It Is About to Start Using

Newly Generated Keys
Client Server

SSH_MSG_NEWKEYS
SEC-4011
Service Request (SERVICE_REQUEST):
‘Message 9’
The Client Requests a Service to Be Started; in This Example,

the Service Is for Authenticating The Client
Client Server

SSH_MSG_SERVICE_REQUEST
ssh-userauth
SEC-4011
Service Request Accept
(SERVICE_REQUEST_ACCEPT): ‘Message 10’
The Server Accepts the Client’s Requests for

Authentication Service
Client Server

SSH_MSG_SERVICE_ACCEPT
ssh-userauth
SEC-4011
User Authentication Request
(USERAUTH_REQUEST): ‘Message 11’
The Client Sends the Server a Request to the Server with a

Username and Password Asking to Be Authenticated
Client Server

SSH_MSG_USERAUTH_REQUEST
Username Service Name
“Password” FALSE
Password in Plaintext
Indicates That the Password Method The Service for Which the
of Authentication Is to Be Used Authentication Is Taking Place
SEC-4011
User Authentication Success
(USERAUTH_SUCCESS): ‘Message 12’
The Server Informs the Client of a Successful Authentication
Client Server

SSH_MSG_USERAUTH_SUCCESS
SEC-4011
Channel Open Request
(CHANNEL_OPEN): ‘Message 13’
The Client Sends the Server a Request to Open a Channel

Specifying the Channel Type, a Local Number It Has Assigned
to the Channel and the Initial Window Size Along with Other
Channel Specific Information
Client Server

SSH_MSG_CHANNEL_OPEN
Channel Type Sender Channel Number
Initial Window Size Maximum Packet Size
Channel Type Specific Data After This…
SEC-4011
Channel Open Confirmation
(CHANNEL_OPEN_CONFIRMATION): ‘Message 14’
The Server Responds Back to the Client with a Message

Confirming Opening the Channel and Provides Its Own
Parameters for Communicating with It on This Channel
Client Server

SSH_MSG_CHANNEL_OPEN_CONFIRMATION
Recipient Channel Sender Channel Number
Initial Window Size Maximum Packet Size
Channel Type Specific Data After This…
This Is the Channel Number

This Is the Channel Number Sent by
the Server Allocates on Its
the Client in the Open Request
Side for This Channel
SEC-4011
Agenda



SEC-4011
SSL/TLS
• SSL and TLS

SSL v3.0 specified in an I-D in 1996 (draft-freier-ssl-version3-02.txt)
TLS v1.0 specified in RFC 2246 in 1999
TLS v1.0 = SSL v3.1 ≈ SSL v3.0
• OSI layer placement
Above TCP/IP and below application layer
Most common use with HTTP → HTTPS
• Goals of protocol
Secure communication between applications
Authentication + privacy + integrity
SEC-4011
SSL Composition
SSL Is a Combination of a Primary Record Protocol

with Four ‘Client’ Protocols
SSL
SSL SSL Application
Change Cipher
Handshake Alert Data
Spec
Protocol Protocol Protocol
Protocol
SSL Record Protocol
SEC-4011
SSL Protocols
Allow for Authentication and Generation
SSL
of Encryption Material Through Negotiation
Handshake
of Parameters And Exchange of
Protocol
Calculated Values
SSL
Used to Convey Administrative Alerts for
Alert
Managing SSL Connections and Sessions
Protocol
SSL
Used to Signal Transition to New Cipher
Change Cipher
and Keys Generally Towards the End of a
Spec
Handshake Negotiation
Protocol
SSL Provides for Transmission of Data in

Record Encrypted and Compressed Form with
Protocol Integrity Checking
SEC-4011
How Does SSL Negotiation Work?
SSL Session Is Negotiated Through Four Sets Of Messages
1st Set of Messages

Used to Start a Negotiation and to Offer and Agree upon Basic Negotiation Options
2nd Set of Messages

Used by the Server to Prove Its ID to the Client and to Send Its Certificate
3rd Set of Messages

Optionally Used By the Client to Prove Its ID and to Send Its Certificate, if Needed, and
to Pass Initial Keying Material for Subsequent Key Generation to the Server
4th Set of Messages

Used by the Server and Client to Indicate Beginning of Use of New Keying Material
SEC-4011
Client Hello: ‘Message 1’
The Client Initiates Handshake with Server, Proposing Session Management

Information as Well as Encryption and Compression Options
Client Server
Handshake Protocol Body
Type = Handshake Version Length Record Protocol Header

Type = ClientHello Length Handshake Protocol Header
Version Random Session ID Random Is a Random Number
CipherSuite CompressionMethod For Use in Generation of
Subsequent Keying Material
Resistant Against Replay
Attacks
Version: Highest Version of SSL/TLS Version
Supported by Client Session ID Is Used to Identify
‘Please Note that the Packet Diagrams Shown Here Are for a Session Allowing a Client to
Illustration Purposes and May Not Accurately Depict the Resume a Previous Session
Relative Sizes or Byte Boundary Placement of the Various and Reuse Its Negotiated
Fields; Certain Fields Such as Padding May Also Not Be Parameters; for New
Shown to Conserve Space’ Sessions This Is Left to Null
SEC-4011
Server Hello: ‘Message 2’
The Server Responds by Sending Back the Selected Options for Ciphers
and Compression Method Along with Its Own Random Number
Client Server

Type = ServerHello Length Handshake Protocol Header
Version Random Session ID
Random Number Generated
CipherSuite CompressionMethod by the Server
The Server Can Provide a
Non-Zero Length Session ID
if It Is Prepared to Resume
Version: Lowest Common Denominator of the This Session at a Later Time
Highest Version Supported by the Server and
the Highest Version Supported by the Client
Server Picks the Most
Preferred Options from
What the Client Offered
SEC-4011
Certificate: ‘Message 3’
The Server Sends Its X.509 Certificate to Prove Its Identity to the Client
While also Supplying a Public Key the Client Can Use Privately Send
Encryption Key Material
Client Server

Type = Certificate Length Handshake Protocol Header
Certificate If the Certificate Does
Not Contain a Key the
Client Can Use for Sending
Encrypted Material to the
Server, an Additional
‘Serverkeyexchange’
The Server Sends Either a Single X.509 Type Message Needs to Be
Certificate or a Chain of Certificates Sent by the Server with
Optionally all the Way up to the Root One Such Key
SEC-4011
Server Hello Done: ‘Message 4’
The Server Sends This Message Containing a Secret Key It Has

Generated Encrypted with the Public Key Provided by the Server
Client Server

Type = ServerHelloDone Length Handshake Protocol Header
<Empty> This Empty Message Is Sent
So the Client Does Not Keep
Waiting for Further Optional
Messages from the Server
SEC-4011
Client Key Exchange: ‘Message 5’
The Server Sends This Message Indicating It Has Sent All the Material
It Wanted to Send During the Handshake Process
Client Server

Type = ClientKeyExchange Length Handshake Protocol Header
EncryptedPreMasterSecret Upon Receiving This
Message; the Master Secret
Is Calculated as Follows:
Mastersecret =
PRF (Premastersecret,
EncryptedPreMasterSecret =
“Master Secret”,
Pub_Server {Version Number | Random Number}
Random from Clienthello,
Random from Serverhello)
Where Version Is a 2 Bytes Number Indicating
the Latest Version Supported by the Client,
Included to Prevent Roll Back Attacks, and the
46 Byte Random Number Generated Securely
SEC-4011
Change Cipher Spec: ‘Message 6’
The Client Sends This Message Indicating That It Is About to Start Using
the Newly Generated Masterkey to Send Encrypted Data
Change Cipher Spec Protocol Body
Client Server
Type = ChangeCipherSpec Version Length Record Protocol Header

Type = ‘1’
This Message Consists of
Only a Single Byte Set to
Value 1
SEC-4011
Finished: ‘Message 7’
Being the First Message from Client to Server to Contain Encrypted Data, It
Allows for Verification That All Exchanges Have Been Securely Completed
Client Server

Type = Finished Length Handshake Protocol Header
VerifyData Verifydata =
PRF (Mastersecret,
“Client Finished”,
MD5 (Handshake Messages),
VerifyData, Used to Ensure the Integrity Sha-1 (Handshake Messages)
of the Exchange, Is Encrypted with
the MasterKey Using the Negotiated
Cipher Algorithm
SEC-4011
Change Cipher Spec: ‘Message 8’
The Server Sends This Message Indicating That It Is About to Start Using
the Newly Generated Masterkey to Send Encrypted Data
Change Cipher Spec Protocol Body
Client Server
Type = ChangeCipherSpec Version Length Record Protocol Header

Type = ‘1’
This Message Consists of
Only a Single Byte Set to
Value 1
SEC-4011
Finished: ‘Message 9’
Being the First Message from the Server to the Client to Contain Encrypted Data,
It Allows for Verification That All Exchanges Have Been Securely Completed
Client Server

Type = Finished Length Handshake Protocol Header
VerifyData Verifydata =
PRF (Mastersecret,
“Server Finished”,
MD5 (Handshake Messages),
VerifyData, Used to Ensure the Integrity Sha-1 (handshake Messages))
of the Exchange, Is Encrypted with
the MasterKey Using the Negotiated
Cipher Algorithm
SEC-4011
Agenda



SEC-4011
PKI: IKE Authentication Architecture
Registration and Certificate

Certification Issuance Authority
Key Certificate
Recovery Revocation
Key Certificate
Generation Distribution
Trusted
Key Storage
Time Service
Support for Non-Repudiation
SEC-4011
Digital Signatures
Private Public
• Entity authentication
• Data origin authentication
• Integrity
• Non-repudiation
SEC-4011
Digital Signatures
One-Way Function; Easy to Mess

age
Produce Hash from Message,

“Impossible” to Produce
Message from Hash
Hash
Function
Alice
Hash of Message s74hr7sh7040236fw
7sr7ewq7ytoj56o457
Sign Hash with Private Key
Signature = “Encrypted”
Hash of Message
SEC-4011
Signature Verification
Message
Decrypt the Re-Hash the

Received age
Mess
Received
Signature Message
Signature
Signature Message with
Appended Hash
Signature Function
Decrypt Using
Alice’s Public Key
Alice
Hash of
Hash Message
Message
If Hashes Are
Equal, Signature
Is Authentic
SEC-4011
Certificate Authority
• The trust basis of a PKI system

• Verify user identity, issues
certificates by binding user’s
identity to a public key with a
digital certificate
• Revokes certificates and
publish Certificate Revocation
List (CRL)
• In-house implementation or
outsourcing
SEC-4011
X.509 v3 Certificate
Version
Serial Number Signing Algorithm,
Signature Algorithm ID e.g. SHA1withRSA
Issuer (CA) X.500 Name CA’s Identity

Validity Period Lifetime of this Cert
Subject X.500 Name User’s Identity, e.g. cn, ou, o
Subject Public Algorithm ID

User’s Public Key (Bound
Key Info Public Key Value to User’s Subject Name)
Issuer Unique ID
Subject Unique ID
Other User Info,
Extension e.g. subAltName, CDP
CA Digital Signature Signed by CA’s Private Key
SEC-4011
Digital Certification
Certificate Authority
Alice
4
Hash
y
Ke
b lic Alice
Pu Ke y ..
Message Digest
’s
CA
blic
r
Pu
Cert Req.
1 fo Sign
est Its Alice CA’s
equ 2 nds Private Key
R Se 3
CA Bob Trusts Alice’s
Public Key After Verifies
5 Her Signature Using CA’s
Public Key
Alice
Alice 6
.. 7
Bob
(Already Has CA’s Public Key)
Convey Trust in Her Public Key
SEC-4011
Agenda



SEC-4011
Encryption vs. Hashing
PlainText Message
CipherText
Encryption( )
or Hash
Decryption( ) Message Digest
• Encryption keeps • Hash transforms message into

communications private fixed-size string
• Encryption and decryption can • One-way hash function
use same or different keys • Strongly collision-free hash
• Achieved by various algorithms, • Message digest can be viewed as
e.g. DES, CAST “digital fingerprint”
• Need key management • Used for message integrity check
and digital certificates
• Hash is generally faster than
encryption
SEC-4011
Properties and Uses of Hashes
• Collision resistance
Impossible to find a, b such that H(a) = H(b)
Used for non-repudiation, commitment
• Second pre-image resistance

Given a, impossible to find b such that H(a) = H(b)
Used for digital signatures
• Pre-image resistance
Given v, impossible to find a such that H(a) = v
Used for password hashing
SEC-4011
Message Authentication
and Integrity Check Using Hash
Message Message
Message
MAC
Hash Hash
MAC
Insecure Channel
MAC
? Hash Output
Sender Receiver
Secret Key Only Known to Sender and Receiver
• MAC (Message Authentication Code): cryptographic checksum

generated by passing data thru a message authentication algorithm
• MAC is often used for message authentication and integrity check
• HMAC: keyed hashed-based MAC
SEC-4011
Commonly Used Hash Functions
(MD5 and SHA)
Message Padding
Block 1 Block 2 Block n Last

(512 Bits) (512 Bits) (512 Bits) Block
IV
H H H H
128 Bits
Hash
• Both MD5 and SHA are derived based on MD4 128 Bits
• MD5 provides 128-bit output, SHA provide 160-bit output,

(only first 96 bits used in IPSec)
• Both of MD5 and SHA are considered one-way strongly collision-free
hash functions
• SHA is computationally slower than MD5, but more secure
SEC-4011
Recent Results
• MD5, SHA1 not collision resistant

Relevance to non-repudiation, commitment
• MD5, SHA1 weakly second pre-image resistant

Relevance to digital signatures
SEC-4011
So What Does This Mean?
• SHA1 is still much safer than MD5

Best known attack has effort > 2^64
• HMAC SHA1 (keyed SHA1) believed to be

unaffected by current attacks
• Industry making a move towards SHA256 and other
secure crypto methods
• Actual transition will take place within standard
groups first
IETF and NIST among others addressing this issue
Analysis Courtesy: David McGrew

SEC-4011
Security Level of Crypto Algorithms
Security Level Work Factor Algorithms
Weak O(240) DES, MD5
Legacy O(264) RC4, SHA1
Minimum O(280) 3DES, SEAL, SKIPJACK
Standard O(2128) AES-128, SHA-256
High O(2192) AES-192, SHA-384
Ultra O(2256) AES-256, SHA-512
SEC-4011
Agenda



SEC-4011
Symmetric vs. Asymmetric
Encryption Algorithms
PlainText PlainText CipherText

CipherText
Encryption( ) Encryption( )
or
Decryption( ) Decryption( )
• Secret-key cryptography • Public-key cryptography

• Encryption and decryption use • Encryption and decryption
the same key use different keys
• Typically used to encrypt the • Typically used in digital
content of a message certification and key
management
• Examples: DES
• Examples: Diffie-Hellman, RSA
SEC-4011
Data Encryption Standard (DES)
• Symmetric key encryption algorithm

• Block cipher: works on 64-bit data block, use
56-bit key (last bit of each byte used for parity)
• Mode of operation: how to apply DES to encrypt
blocks of data
Electronic Code Book (ECB)
Cipher Block Chaining (CBC)
K-bit Cipher FeedBack (CFB)
K-bit Output FeedBack (OFB)
SEC-4011
DES CBC Mode
IV m1 m2 mn
XOR XOR Cn-1 XOR
K K K
DES Encrypt( ) DES Encrypt( ) DES Encrypt( )
C1 C2 Cn
C1 C2 Cn
K K K
DES Decrypt( ) DES Decrypt( ) DES Decrypt( )
IV Cn-1
XOR XOR XOR
m1 m2 mn
SEC-4011
Triple-DES
64-bit 56-bit 56-bit 56-bit

Plaintext Block 64-bit
DES DES DES Cipher Text
• 168-bit total key length

• Mode of operation decides how to process DES three times
• Normally: encrypt, decrypt, encrypt
• More secure than DES but slower
• So, is 3DES optimally the fastest, the easiest to implement
and the securest algorithm out there?
SEC-4011
AES: the New Encryption Standard
• ‘Advanced Encryption Standard’ formerly known as

‘Rijndael’
• Successor to DES and 3DES
• Will ultimately become the default ESP cipher
• Symmetric key block cipher
• Strong encryption with long expected life
• AES can support 128, 192 and 256 keys strengths
but 128 is considered safe
• HMAC-SHA-1 and HMAC-MD5 can serve as the IKE
generators of the 128 bit AES keys
SEC-4011
AES: Pseudo Code
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)])

begin
byte state[4,Nb]
state = in
AddRoundKey(state, w[0, Nb-1])
for round = 1 step 1 to Nr–1
SubBytes(state)
ShiftRows(state)
MixColumns(state)
AddRoundKey(state, w[round*Nb, (round+1)*Nb-1])
end for
SubBytes(state)
ShiftRows(state)
AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1])
out = state
end
SEC-4011
AES: The Complete Cipher
Input
Key 1
Round 0
Key 2
Round 1
Key
Schedule
Key Nr
Round Nr
Output
SEC-4011
AES: Individual Rounds
Input
Note: Last Round Is Slightly Different Sub

from the Rest of the Rounds Bytes
Shift
Rows
Input
Key 1
Round 0 Mix
Key 2
Columns
Round 1
Key
Schedule
Add Round
Key Nr Key
Round Nr
Output
Output
SEC-4011
AES Functions: SubBytes and ShiftRows
SubBytes
s0, s4 s8 s12 s'0 s'4 s'8 s'12

s1 ss5 s9 s13 s'1 s'5 s'9 s'13
s'5
s2 s6
5
s10 s14
S-Box s'2 s'6 s'10 s'14
s3 s7 s11 s15 s'3 s'7 s'11 s'15
ShiftRows
s0 s4 s8 s12 s0 s4 s8 s12
s1 s5 s9 s13 s5 s9 s13 s1
s2 s6 s10 s14 s10 s14 s2 s6
s3 s7 s11 s15 s15 s3 s7 s11
SEC-4011
AES Functions: MixColumns and
AddRoundKey
MixColumns
s0, ss
4 s8 s12 s‘0 s's4 s‘8 s‘12
4 4
s1 s5 s9 s13 s‘1 s'5 s‘9 s‘13
s5 Mix s‘5
s2 s6
s6
s10 s14 Columns s‘2 s'6 s‘10
s6
s‘14
s3 s7 s11 s15 s‘3 s'7 s‘11 s‘15
s6 s7
AddRoundKey
s0 s4 s8 s12 s‘0 s'4 s‘8 s‘12
s4 s‘4
s1 s5 s9 s13 Word from s‘1 s'5 s‘9 s‘13
s5 s‘5
XOR Key s‘2 s'6 s‘10 s‘14
s2 s6 s10 s14 s‘6
s6 Schedule
s3 s7 s11 s15 s‘3 s'7 s‘11 s‘15
s6 s‘7
SEC-4011
Agenda



SEC-4011
Galois/Counter Mode (GCM)
• Authenticated encryption at very high speeds!

• Designed to achieve speeds 10gbps or above
in hardware, can perform well in software and
is patent free
• Block cipher mode of operation
Provides High Speed, Low Latency at Low Cost
SEC-4011
Authenticated Encryption Operation
• Inputs
K Key (same length as block cipher key)
IV Unique value (length between one and 264 bits)
P Plaintext (length between zero and 239 bits)
A Additional authenticated data (one to 264 bits)
• Outputs
C Ciphertext (same length as P)
T Authentication tag (length between zero and 128 bits)
SEC-4011
Example: GCM Frame Encryption
SEC-4011
GCM Internals
• Counter mode encryption

Based on IPSec CTR specification
Efficient, compact
• MAC is encrypted hash

Polynomial hash over GF(2128)
Multiply and accumulate
MAC key H = EK(0128)
SEC-4011
Software Performance (Cycles/Byte)
SEC-4011
GCM Uses
• IEEE Link Security (802.1AE)

GCM is mandatory cryptoalgorithm in draft
• IPSec ESP
Draft based on ESP-AES-CCM, ESP-AES-CTR
• Fibre Channel Security

• Future fast wireless LAN
SEC-4011
Agenda



SEC-4011
Elliptic Curve Cryptography (ECC)
• ECC is an alternate to the traditional ways of doing

public key signatures and key exchanges
• Primary advantage of using ECC is a much smaller
key size and faster calculations
• Gains in storage and performance efficiency
• Three ECC DH (also known as ECDH) groups have
been proposed for use in IKE v2
SEC-4011
Elliptic Curve Diffie Hellman (ECDH)
• Alice picks an elliptic curve Examples of Elliptic Curves

and a point ‘S’ on it; she then
calculates Apub = a * S, where
A is a secret known only to
her; she makes the curve,
point ‘S’ and Apub publicly
known
• Bob uses the above
information to calculate
Bpub = b * S, and makes
Bpub publicly known
Shared Secret = b * Apub = b * a * S = a * Bpub
SEC-4011
ECDH Gains in Efficiency
The Table Below Shows the Comparable Key Lengths

Required in DH/RSA as Compared to ECC Based DH
to Secure a Symmetric Key of a Given Length
Symmetric Key Length ECC Key Length DH/RSA Key Length
80 163 1024
112 233 2048
128 283 3072
192 409 7680
256 571 15360
Reference: draft-ietf-ipsec-ike-ecc-groups-05.txt with Further Reference Contained Therein

SEC-4011
Recommended Reading
• ‘Network Security
Principles and Practices’
by Saadat Malik
• Continue your Networkers

learning experience with
further reading for this
session from Cisco Press
• Check the Recommended
Reading flyer for suggested
books
SEC-4011
Available Onsite at the Cisco Company Store
Complete Your Online Session Evaluation!
• Win fabulous prizes! Give us your feedback!

• Receive 10 Passport Points for each
session evaluation you fill out
• Go to the Internet stations located
throughout the Convention Center
• Winners will be posted on the Internet
stations and digital plasma screens
• Drawings will be held in the
World of Solutions
Monday, June 20 at 8:45 p.m.
Tuesday, June 21 at 8:15 p.m.
Wednesday, June 22 at 8:15 p.m.
Thursday, June 23 at 1:30 p.m.
SEC-4011
12470_04_2006_c1 © 2006 Cisco Systems, Inc. All rights reserved. Cisco Public 114 114
SEC-4011
11286_05_2005_c1 © 2005 Cisco Systems, Inc. All rights reserved. 115
APPENDIX
SESSION SEC-4011
SEC-4011
Appendix
Analysis of the Enhancements in IPSec

• IKE Negotiation Using Pre-Shared Keys
• Remote Access Features, NAT Traversal, DPD
• Multicast IPSec
SEC-4011
Appendix

• Multicast IPSec
SEC-4011
Goal: Negotiation of IKE SA Parameters
Generation of Initiator Cookie

CKY-I = md5{Date and Time, (src_ip, dest_ip), Random Number}
Generation of Responder Cookie

CKY-R = md5{Date and Time, (src_ip, dest_ip), Random Number}
SEC-4011
The Initiator Proposes a Set of Attributes to Base the SA On
Initiator Responder
Initiator Cookie (Calculated and Inserted Here)
Responder Cookie (Left 0 for Now) DOI Identifies the Exchange
SA Version Exchange Flags to be Occurring to Setup IPSec
Message ID SPI = 0 for All Phase
Total Message Length 1 Messages
Next Payload 1 SA Payload Length Includes Proposal #,
SA Payload (Includes DOI and Situation) Protocol ID, SPI Size,
Next Payload 1 Proposal Payload Length # of Transforms, SPI
Proposal Payload (Two Proposals Shown Here)
Next Payload 1 Transform Payload Length Includes Transform #,
Transform Payload Transform ID, SA Attributes,
Next Payload 1 Proposal Payload Length for Example, DES, MD5,
Proposal Payload DH 1, Pre Share, Timeout
0 1 Transform Payload Length (Two Transform Sets
Transform Payload
Shown Here)
SEC-4011
The Responder Sends Back the One Set of Attributes Acceptable to It
Initiator Responder

Responder Cookie (Calculated and Inserted Here) DOI Identifies the Exchange
SA Version Exchange Flags to be Occurring to
Message ID Setup IPSec
Total Message Length PROTO_ISAKMP,
Next Payload 1 SA Payload Length SPI = 0 for All Phase
SA Payload (Includes DOI and Situation) 1 Messages
Proposal Payload (Includes Proposal #, Protocol ID, SPI
Size, # of Transforms, SPI)
0 1 Transform Payload Length KEY_OAKLEY = Type
Transform Payload (Includes Transform #, DES, MD5, DH 1
Transform ID, SA Attributes) Pre-Share
SEC-4011
Goal: Exchange of Information Required for Key

Generation Using DH Exchange
Generation of DH Public Value by Initiator

DH Public Value = Xa
Xa = ga mod p
Generation of DH Public Value by Responder

DH Public Value = Xb
Xb = gb mod p
SEC-4011
Generation of a Nonce by Initiator

Initiator Nonce = Ni
Generation of a Nonce by Responder

Responder Nonce = Nr
SEC-4011
The Initiator Sends Its DH Public Value Xa and Nonce Ni
Initiator Responder

Message ID DH Public Value = Xa
Length
0 0 Nonce Payload Length Nonce = Ni
SEC-4011
The Responder Sends Its DH Public Value Xb and Nonce Nr
Initiator Responder

Message ID DH Public Value = Xb
Length
0 0 Nonce Payload Length Nonce = Nr
SEC-4011
IKE Phase 1 (Main Mode): (Pre-Shared Keys)
Preparation for Sending ‘Message 5 and 6’
Calculation of Three Keys (Initiator)

to IKE Messages
PRF = A Pseudo
SKEYID = PRF (Pre-Shared Key, Ni | Nr) Random Function
Based on the
Negotiated Hash
SEC-4011
IKE Phase 1 (Main Mode): (Pre-Shared Keys)
Calculation of Three Keys (Responder)

to IKE Messages
SKEYID = PRF (Pre-Shared Key, Ni | Nr)
SEC-4011
(Pre-Shared Keys) ‘Sending ‘Message 5’
Initiator Responder
Identification of Initiator
Initiator Cookie (Same as Before) (ID_I)
Responder Cookie (Same as Before) Such as Host Name or
Next Payload Version Exchange Flags IP Address
Message ID
Total Message Length Hash_I
Next Payload 0 Identity Payload Length =
SKEYID_e
ID Type DOI Specific ID Data PRF (SKEYID, CKY-I,

Identity Payload CKY-R, Pre-Shared Key
(PK-I), SA Payload,
Proposals+Transforms,
Hash Payload
ID_I)
SEC-4011
(Pre-Shared Keys) Sending ‘Message 6’
Initiator Responder
Initiator Cookie (Same as Before) (ID_R)
Responder Cookie (Same as Before) Such as Host Name or
Next Payload Version Exchange Flags IP Address
Message ID
Total Message Length Hash_R
Next Payload 0 Identity Payload Length =
SKEYID_e
ID Type DOI Specific ID Data PRF (SKEYID, CKY-I,

Identity Payload CKY-R, Pre-Shared Key
(PK-R), SA Payload,
Proposals+Transforms,
Hash Payload
ID_R)
SEC-4011
Completion of Phase 1
• Initiator authenticates the responder

1. Decrypt message using SKEYID_E
2. Find configured PK-R using ID_R
3. Calculate Hash_R on it’s own
4. If received Hash_R = self-generated Hash_R then
• Responder authenticates the initiator ISAKMP SA
1. Decrypt message using SKEYID_E Established!
2. Find configured PK-I using ID_I
3. Calculate Hash_I on it’s own
4. If received Hash_I = self-generated Hash_I then
SEC-4011
Goal: Negotiation of IPSec SA
Execution of DH by Initiator Again to Ensure PFS
New Nonce Generated: Ni’

New DH Public Value = Xa’
Xa’ = ga mod p
Execution of DH by Responder Again to Ensure PFS
New Nonce Generated: Nr’

New DH Public Value = Xb’
Xb’ = gb mod p
SEC-4011
The Initiator Sends Authentication/Keying Material and
Initiator Responder

Message ID
SEC-4011
SA 0 Hash Payload
Hash Payload Hash =PRF (SKEYID_a,
Next Payload 0 SA Payload Length Message ID, Ni’, Proposals+
SA Payload (Includes DOI and Situation) Transforms, Xa)
Proposal Payload ESP or AH, SHA or MD5,
DH 1 or 2, SPI
Transform Payload
(Two Proposals
Shown Here)
SKEYID_e
Proposal Payload
Transform:
Transform Payload
Next Payload 0 Keyload Payload Length
Tunnel or Transport,
IPSec Timeout
KE Payload
Nonce Payload (Ni’) KE Payload = Xa’
Identity Payload = ID-s
ID-s = Source Proxy
ID-d = Destination Proxy
Identity Payload = ID-d
SEC-4011
The Responder Sends Authentication/Keying Material and
Initiator Responder

Message ID
SEC-4011
Hash =
Next Payload 0 Hash Payload Length
PRF (SKEYID_a, Message ID
Hash Payload Ni’, Nr’, Accepted Proposal+
Next Payload 0 SA Payload Length Transform, Xb)
SA Payload (Includes DOI and Situation)
Proposal Payload (Accepted Proposal)
SKEYID_e
Transform Payload (Accepted Transform) with Responder’s SPI

Next Payload 0 KE Payload Length
KE Payload
Nonce Payload (Nr’)
Next Payload 0 Identity Payload Length KE Payload = Xb’
Identity Payload = ID-s (Generally Similar to ID-d for Initiator)
Identity Payload = ID-d (Generally Similar to ID-s for Initiator)
SEC-4011
Completion of Phase 2
• Initiator generates IPSec keying material

1. Generate new DH shared sSecret = (Xb’)a mod p
(ISAKMP), new DH shared secret, SPIr, Ni’, Nr’)
• Responder generates IPSec keying material

1. Generate new DH shared secret = (Xa’)b mod p
(ISAKMP), new DH shared secret, SPIi, Ni’, Nr’)
SEC-4011
The Initiator Sends Across a Proof of Liveness
Initiator Responder
Initiator Cookie (Same as Before) Hash

Responder Cookie (Same as Before) =
KE Version Exchange Flags PRF (SKEYID_a, Message ID,
Message ID Ni’, Nr’)
SKEYID_e

Hash Payload IPSec SA
Established!
SEC-4011
One Page Summary: Pre-Shared Main Mode
DES DES HDR, SAProposal DES

MD5 SHA MD5
DH 1 DH 2 DH 1
Pre-Share Pre-Share Pre-Share
HDR, SAchoice
Phase I SA Parameter Negotiation Complete

Generate
DH Public Value HDR, KEI, NonceI
and Nonce
Generate
HDR, KER, NonceR DH Public Value
and Nonce
DH Key Exchange Complete, Share Secret SKEYIDe Derived
Nonce Exchange Defeat Replay
HASHI=HMAC(SKEYID,
KEI|KER|cookieI| HDR*, IDI, HASHI
cookieR|SA|IDI)
HASHR=HMAC(SKEYID,
HDR*, IDR, HASHR KER|KEI|cookieR|
cookieI|SA|IDR)
IDs Are Exchanged, HASH Is Verified for Authentication
ID and HASH Are Encrypted by Derived Shared Secret
SEC-4011
One Page Summary: Quick Mode
ESP ESP
DES HDR*, HASH1, Saproposal, NonceI [,KEI] [,IDCI,IDCR] DES
SHA SHA
PFS 1 PFS 1
HDR*, HASH2, SAchoice, NonceR, [,KER] [,IDCI,IDCR]
HDR*, HASH3
SEC-4011
Aggressive Mode Using Pre-Shared Key:
a Quick Overview
DES DES DES

MD5 MD5 MD5
HDR, SAProposal, KEI, NonceI, IDI
DH 1 DH 2 DH 1
Pre-Share Pre-share Pre-Share
HDR ,SAchoice, KER, NonceR,IDR,HASHR
HDR, HASHI
• Three messages compared to the six messages in main mode

• Group pre-shared key lookup possible for remote access
applications
• ID is not protected (except RSA encryption)
SEC-4011
Appendix

• Multicast IPSec
SEC-4011
Remote Access Features
• Mode config
• Extended authentication
SEC-4011
Placement of Mode Config and X-Auth
in IKE
Phase I SA (ISAKMP SA)

Main Mode Aggressive Mode
(6 Messages) (3 Messages)
New IPSec Tunnel or Rekey
Phase 1.5: X-Auth and/or Mode Config
Phase II SA Phase II SA
(IPSec SA) (IPSec SA)
Quick Mode Quick Mode
A Protected Data B C Protected Data D
SEC-4011
Mode Config
Mechanism Used to Push Attributes to Remote Access
IPSec Clients
Remote Access
Private IPSec Gateway IPSec Client
Network
Public
Network
Internal IP Address
DNS Server
DHCP Server
Net Bios Name Server
Optional Attributes
SEC-4011
Mode Config Protocol Specifications
Type =
ISAKMP HEADER
ISAKMP_CFG_REQUEST = 1 Next
Reserved = 0
Attributes Payload Hash
Payload Length
or =
ISAKMP_CFG_REPLY = 2 Type = 1 Reserved = 0 Identifier Prf (SKEYID_a,
or Attributes (0 Length Attributes in Request) ISAKMP Header M-ID |
ISAKMP_CFG_SET = 3 0 0 Hash Payload Attribute Payload)
or Length
ISAKMP_CFG_ACK = 4 Hash
Attribute Request
Initiator Responder
Remote Client IPSec Gateway
Attribute Reply
ISAKMP HEADER Attributes =

Next Reserved = 0 Attributes Payload INTERNAL_IP4_ADDRESS 1
Payload Length
Length INTERNAL_IP4_NETMASK 2
Type = 2 Reserved = 0 Identifier INTERNAL_IP4_DNS 3
Attributes (Set
Attributes (Set to
to the
the Values
Values for
for One
One or
or INTERNAL_IP4_NBNS 4
More of the Attributes to Be Pushed)
More of the Attributes to Be Pushed) INTERNAL_ADDRESS_EXPIRY 5
0 0 Hash Payload
Hash Length
Payload INTERNAL_IP4_DHCP 6
Hash Length Other Allowed but Not Mandatory
SEC-4011
X-Auth
Mechanism Used to Perform Per User Authentication
for RA Clients
Remote Access
Private IPSec Gateway IPSec Client
Network
Public
Network
AAA Server Generic Username/Password
Chap
OTP
S/Key
SEC-4011
X-Auth Protocol Specifications
Type =
ISAKMP HEADER
Reserved = 0
Payload Length
or =
or Length
Attribute Request
Initiator Responder
Remote Client IPSec Gateway
Attribute Reply
ISAKMP HEADER Attributes =

Next Reserved = 0 Attributes Payload
XAUTH_TYPE 16520
Payload Length
Length XAUTH_USER_NAME 16521
Type = 2 Reserved = 0 Identifier XAUTH_USER_PASSWORD 16522
XAUTH_PASSCODE 16523
Attributes (Set
Attributes (Set to
to the
the Values
Values for
for One
One or
or
More of the Attributes to Be Pushed) XAUTH_MESSAGE 16524
XAUTH_CHALLENGE 16525
0 0 Hash Payload
Hash Length
Payload XAUTH_DOMAIN 16526
Hash Length
XAUTH_STATUS 16527
SEC-4011
X-Auth Protocol Specifications
Type = ISAKMP HEADER
ISAKMP_CFG_REQUEST = 1 Hash Reserved = Attributes Payload

0 Length
or
ISAKMP_CFG_REPLY = 2 Type = 3 Reserved = 0 Identifier
or Attributes (X-auth_Status = OK or FAIL)
ISAKMP_CFG_SET = 3 0 0 Hash Payload
or Length
Attribute Set
Initiator Responder
IPSec Gateway IPSec Client
Attribute Ack
ISAKMP HEADER
Next Reserved Payload
Hash Reserved =
=00 Attributes
Payload Length
Length
Type = 4
2 Reserved = 0 Identifier
Attributes (Set to(None
Attributes the Values for One or
Included)
0 00 HashHash
Payload Length
Payload
Hash Length
SEC-4011
IPSec and NAT: The Problem
IPSec
Remote IPSec
Private Client PAT Device Gateway Private
Network Network
Public
Network
Port Address Translation Fails Since in

ESP Packets L4 Port Info Is Encrypted
SEC-4011
Need Based NAT Traversal with IPSec
over TCP or UDP
• Step 1: detect support for bi-directional NAT traversal

• Step 2: discover existence of NAT in IPSec path
• Step 3: negotiate NAT traversal encapsulation
• Step 4: begin encapsulation of packets
IPSec
Remote IPSec
Private Gateway Private
Network Client PAT Device
Network
Public
Network
External ESP Original TCP/UDP ESP

Payload
IP Header Header IP Header Header Trailer
External UDP ESP Original TCP/UDP ESP

Payload
IP Header Header Header IP Header Header Trailer
SEC-4011
Step 1: Detect Support for Bi-Directional
NAT Traversal
ISAKMP HEADER
Next Payload Reserved VID Payload Length
Vendor ID = Hash (IETF ID or RFC Number)
VID
Initiator Responder
Remote Client Gateway
VID
ISAKMP HEADER
Next Payload Reserved VID Payload Length
Vendor ID = Hash (IETF ID or RFC Number)
SEC-4011
Step 2: Discover Existence of NAT
in IPSec Path
ISAKMP HEADER
Next Payload Reserved NAT-D Payload Length
NAT-D Payload = Hash (CKY-I | CKY-R | IP | Port)
NAT-D
Initiator Responder
NAT-D
If Hashes Are
Not the Same,
ISAKMP HEADER
Nat Exists!
Next Payload Reserved NAT-D Payload Length
NAT-D Payload = Hash (CKY-I | CKY-R | IP | Port)
SEC-4011
Step 3: Negotiate NAT Traversal
Encapsulation (Shown Here for UDP)
Type =
ISAKMP HEADER
Reserved = 0
Payload Length
or =
or Length
Attribute Request
Initiator Responder
Attribute Reply
ISAKMP HEADER (Optional) Attribute

Next Reserved = 0 Attributes Payload
Payload Length
=
Length
Type = 2 Reserved = 0 Identifier MODECFG_UDP_NAT_PORT
Attributes
Attributes (Set to the Values for One or= x
(MODECFG_UDP_NAT_PORT
More of the Attributes to Be Pushed) Value
0 0 Hash Payload
Hash Length
Payload =
Hash Length UDP Port Number: 10000 – 49151
SEC-4011
Dead Peer Discovery
Peer A Peer B
I Wonder if B Is I Don’t Care if A

Dead, I Have to Is Dead, I Don’t
Send Some Have Anything
Data to It to Send
Passage of IPSec Traffic Is Proof of Liveliness

DPD Is Asynchronous
Each Peer Sets Its Own WORRY METRIC
Check on Peer Only if There Is a Need to Do So
SEC-4011
Cisco’s DPD Worry Metric
Peer A Peer B
DPD
It Has Been a Long

Time Since B Sent Me
any Traffic or DPDs;
Now I Have to Send
Traffic to It, Let Me
Check if It Is Alive
Configurable
Idle Time Between Data and DPD Traffic Before
Which No DPDs Sent
DPD Only Used When There Is Data to Send
SEC-4011
DPD Protocol Specifications
Vendor ID ISAKMP HEADER
Next Payload Reserved Notify Payload Length
Payload Is
DOI = IPSec DOI
Exchanged Protocol ID = Notify Message Type =
in IKE SPI SIZE
ISAKMP R-U-THERE
Negotiation SPI = CKY-I | CKY-R
Beforehand Notification Data = Sequence Number
R-U-THERE
Initiator Responder
R-U-THERE-ACK
ISAKMP HEADER
Next Payload Reserved Notify Payload Length
DOI = IPSec DOI
Protocol ID = Notify Message Type =
ISAKMP SPI SIZE R-U-THERE
SPI = CKY-I | CKY-R
Notification Data = Sequence Number
SEC-4011
Appendix

• Multicast IPSec
SEC-4011
What Is a Multicast Group?
• Two or more parties who send and receive the

same data transmitted over a network
• Packet delivery can be multicast, or unicast (where
identical data is directed to each group member)
• Group members can be routers, PCs, telephones,
any IP device
• There are many different examples of group
topologies
SEC-4011
Multicasting
Single-Source Multicast Publish-Subscribe
Multiple-Source Multicast Multipoint Control Unit
SEC-4011
Securing Multicast Groups
What Is Needed to Secure Group Traffic?

• Policy distribution
Distribution of the knowledge that group traffic is
protected, and what is needed to participate in
the group
• Protect the data in transit

Only group members should be able to participate
in the group
Non-group members should not be able to spoof or
disrupt group communication
• Deliver keys to all group members
SEC-4011
Solution: GDOI and Key Server
• Group Domain of Interpretation (GDOI)

Re-uses IKE protocols and definitions
IETF MSEC internet draft stage
• Key server method

A key server (known as group controller/key server or
GCKS) unilaterally chooses the keys
Group members join by registering with the key server
The key server replaces keys when a group
member leaves
Can scale to very large groups by using multiple
collaborating key servers
SEC-4011
GDOI Overview
• Distributes keys and policy for groups

Security associations and keys
• Can efficiently re-key the group when needed

When a member joins/leaves the group
When an existing SA is about to expire
• Quickly and efficiently eject a group member
SEC-4011
GDOI Protocol Flow
• Two phases
IKE phase 1 protocol
GROUPKEY-PULL protocol
IKE Phase 1
Group
GROUPKEY-PULL Protocol GCKS
Member
• Security protections
IKE phase 1 provides authentication, confidentiality,
and integrity
GROUPKEY-PULL protocol provides authorization
and replay protection
SEC-4011
GDOI Phase 2 Protocol
Member Requests to Join Group Using an ID Payload
Key Server Returns Policy in SA Payload
Group Member Agrees to Policy GCKS

Member
Key Server Returns Keys Using a KD Payload
SEC-4011
GDOI Rekey GROUPKEY-PUSH Message
• One message exchange

Sent from key server to all group members
IP multicast message is the most efficient distribution
• Security protections
Authentication/integrity provided by a digital signature
on the message
Confidentiality provided using keys distributed during GDOI
registration
Replay protection through use of a message sequence number
Group GDOI Rekey

GCKS
Member
SEC-4011

Advanced Topics in Encryption Standards and Protocols 2006 Cisco

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Topics in Encryption Standards and Protocols 2006 Cisco

Uploaded by

Copyright:

Available Formats

Advanced Topics in Encryption

Standards and Protocols

• Analysis of Mainline Protocols

• Analysis of Underlying Standards

• New Directions in Cryptography Standards

• Analysis of Mainline Protocols

• Analysis of Underlying Standards

• New Directions in Cryptography Standards

IPSec Combines Three Protocols into a

Provides Framework for the Negotiation

Provides Framework for the

Provides Framework for the

IKE (Internet Key Exchange) (RFC 2409)

IKE Solves the Problems of Manual

IKE Is a TWO Phase Protocol

Phase I SA (ISAKMP SA)

Main Mode Aggressive Mode

New IPSec Tunnel or Rekey

Quick Mode Quick Mode

A Protected Data B C Protected Data D

Goal: Negotiation of IKE SA Parameters

Generation of Initiator Cookie

Generation of Responder Cookie

Initiator Cookie (Same as Before)

Goal: Exchange of Information Required for Key

Generation of DH Public Value by Initiator

Generation of DH Public Value by Responder

Generation of a Nonce by Initiator

Generation of a Nonce by Responder

Initiator Cookie (Same as Before)

Responder Cookie (Same as Before)

Initiator Cookie (Same as Before)

Responder Cookie (Same as Before)

Goal: Exchange of Authentication

Calculation of the Shared DH Secret by Initiator

Shared Secret = (Xb)a mod p (Xb)a mod p =

Calculation of the Shared DH Secret by Responder

Shared Secret = (Xa)b mod p

Calculation of Three Keys (Initiator)

SKEYID = PRF (Ni | Nr gab)

SKEYID_d = PRF (SKEYID, gab | CKY-I | CKY-R | 0)

Calculation of Three Keys (Responder)

SKEYID = PRF (Ni | Nr gab)

SKEYID_d = PRF (SKEYID, gab | CKY-I | CKY-R | 0)

Initiator Cookie (Same as Before)

Next Payload 0 Hash_I Encrypted with Priv_I

Initiator Cookie (Same as Before)

Next Payload 0 Hash_R Encrypted with Priv_R

• Initiator authenticates the responder

Goal: Negotiation of IPSec SA

Execution of DH by Initiator Again to Ensure PFS

New Nonce Generated: Ni’

Execution of DH by Responder Again to Ensure PFS

New Nonce Generated: Nr’

Initiator Cookie (Same as Before)

Initiator Cookie (Same as Before)

Transform Payload (Accepted Transform) with Responder’s SPI

• Initiator generates IPSec keying material

• Responder generates IPSec keying material

Initiator Cookie (Same as Before) Hash

Total Message Length

DES HDR, SAProposal DES DES

Phase I SA Parameter Negotiation Complete

HDR*, HASH2, SAchoice, NonceR, [,KER] [,IDCI,IDCR]