
sSecurity Sep-01

(C) Siemens

Dr. J. Cuellar Siemens, CT IC 3


sSecurity

Jul-02(C) Siemens

Contents Part 1

IKE

Main ModeQuick ModeDOIPolicies + ConfigGeneral Structure and Properties of IKEDeficiencies of IKE

IPSec

SA, SAD, SPI: Receiving IPSec PacketsSPD: Sending IPSec PacketsIPsec Documents


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Contents Part 2

SoI

IdentitiesJFKIKEv2Comparison

ESP + AH changes


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Internet Key Exchange (IKE)

ISAKMP Phases and Oakley Modes

Phase 1 establishes an ISAKMP SA

Main Mode or Aggressive Mode

Phase 2 uses the ISAKMP SA to establish other SAs

Quick Mode

New Group Mode

Authentication with

Signatures

Public key encryption

Two versions

Based on ability to decrypt, extract a nonce, and compute a hash

Pre-shared keys

Four of the five Oakley groups

AggressiveMain

New Group

Quick

No SA

Ph 1

Ph 2

IKE states (simplified)

modes and phases


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEMain Mode


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKE: Diffie-Hellman

k = Yx mod p = (gx)y mod p = (gy)x mod p = Xy mod p =k

choose g,pgenerate x

compute X=gx mod p X [,g,p]

generate ycompute Y=gy mod p

Y

A B


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKE: Denial of Service: Flodding

choose g,pgenerate series

of random numbers:Xi , i =1.. n

Xi [,g,p]

generate yicompute Yi = gyi (p)

Yi

A B

Exponentiation: computationally expensive

Memory allocation


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKE: Cookies

X=gx mod p CA, CB, X [,g,p]

Y=gy mod pCA, CB, Y

A Bchoose CA

CA

choose CB

CB

Return routability proof: A has to have seen CB to send the next msg.

If A spoofs Addi it has to sit on path Addi --BClose to Addi : not many active addresses

Close to B


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKE: Cookies

A B

Y=gy mod pCA, CB, Y

choose g,p

X=gx mod pCA, CB, X [,g,p]

choose CA

CA

choose CB

CB

If A uses repeatedly same Address: Same cookie: B discardsDifferent cookies: A must wait

Problem remains: Unauthenticated key-exchange:

man-in-the-middle


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKE: Identities (Authenticated Key Exchange)

A B

Y=gy mod pCA, CB, Y

X=gx mod p CA, CB, X [,g,p]

choose CA

CA

choose CB

CB

CA, CB, {IDA}SAA,k

CA, CB, {IDB} SAB,k

If A and B have a long-term security associations SA (for instance, share a key PSKey)they may use it, together with k (the D-H result)to encrypt and authenticate the ID


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKE: Main Mode for shared key: Negotiation, Key Derivation

A B

CA, CB, X [,g,p], NA

CA, ISAA

CA, CB, Y, NB

CB, ISAB

CA, CB, {IDA}PSKey,k

CA, CB, {IDB}PSKey,k

SKey = hPSKey( NA | NB)

{IDA}PSKey,k = ( IDA | HashA )

ISAA, ISAB are ISAKMP SA Data, used by IKE to negotiate:

encryption algorithmhash algorithmauthentication method

The negotiated parameters pertain only to the ISAKMP SA and not to any SA that ISAKMP may be negotiating on behalf of other services.

SKeyd = hSKey( k | CA | CB | 0 )

SKeye = hSKey( SKeyd | k | CA | CB | 2 )

SKeya = hSKey( SKeyd | k | CA | CB | 1 )

HashA = hSKeya( X | Y | CA | CB | ISAA | IDA )


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEDeficiencies


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Designing key-establishment protocols

Needham-Schroeder (1978): first protocols, based on:

shared-key encryption

public-key signatures. (With on-line server rather than certication).

Needham and Schroeder also pointed out that the protocols are prone to subtle errors and that there is a need for verication techniques.

Denning and Sacco (1981) found a flaw in the shared-key N-S protocol and proposed their own protocol that uses a kind of name certicate issued by a trusted on-line server.

10 years later, Denning-Sacco protocol and the public-key Needham-Schroeder protocol were shown to have a serious flaws (Abadi–Needham 96, Lowe 96)


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Issues: 1.: Complexity

The cellular carriers haven’t seriously considered IKE to protect the Mobile IP messages due to the large overhead required in order to setup the IKE Security Association (large number of round trips).

IKE is a combination of 13 different subprotocols:

Phase One: 8 difierent subprotocols,

2 choices for mode, and

4 choices for authentication mechanism.

Phase Two: 4 difierent subprotocols:

perfect forward secrecy or no PFS

explicit identity information is included or not.

Plus new group protocol


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Marcus Leech, Jeff Schiller, Steve Bellovin (Aug 2001):A Cryptographic Evaluation of IPsec, Niels Ferguson and Bruce Schneier, http://www.counterpane.com/ipsec.pdf

Analysis of the Internet Key Exchange Protocol Using the NRL Protocol Analyzer, Catherine Meadows, http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1999/1999meadows-IEEE99.ps

IKE/ISAKMP Considered Dangerous, William Simpson, http://www.alternic.org/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html

have shown security problems in IKE.

„It seems only a matter of time before more analyses show more serious security issues [and] *implementation* problems become apparent.

Reason: the complex nature of the protocol, and the complex implementation that must surely follow.“


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Contradictions between the different documents:Rekeing: multiple SAs may be pre-negotiated and used at will?

Possible interaction of the different subprotocols, which use similar formats, could lead to new insecurities.

This has been shown to be the case for an early version of SSL (draft-benaloh-pct-00.txt, 1995)

Intruder is able to pass off a compromised weak key as a strong key by interleaving two subprotocols, one of which uses the weak key, and one of which is intended to use a strong key.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Issues with Identities in IKE (Meadows, 1999)

Client negotiation is supported.

The negotiating parties are not the endpoints for which security association negotiation is taking place.

The identities of the end parties remain hidden.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Information & Communications

Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

IPSec


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Insecured Messages vs. Secured Messages

Impersonation: IP Spoofing

Session hijacking

Man-in-the-middle

Eavesdropping

Msg modification

IPHdr Payload

IPHdr

Fields

Source

IPAdd

Dest

IPAdd

TCP

Hdr

Appl

Hdr

Appl

Payload

Tunnel mode:

the whole package is being

encapsulated

in a new package

IPHdr Payload

Neuer

IPHdr

IPSec

Hd

IPHdr Payload IPSec

Trailerencrypted

There is also a less expensive

Transport mode:

new IPSec Header (+ evtl Trailer)

provides somewhat less security

IPSec

Hd

IPHdr IPSec

Trailer

Payload

encrypted


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Use of IPSec: Tunnel Mode

Secured messagesin an insecureenvironment

NeuerIPHdr

IPSecHd

IPHdr Payload IPSecTrailerencrypted

Insecured messagesin an secureenvironment

IPHdr Payload

IPHdr Payload


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Transport vs. Tunnel Mode

IPHdr Payload

Neuer

IPHdr

IPSec

Hd

IPHdr Payload IPSec

Trailerencrypted

Tunnel ModeTunnel mode has an “outer IP header” and “inner IP header”

AH protects part of the outer header as well

Authentication is between remote host and corporate firewall (or Security Gateway), or between two firewallsUser for access to entire internal network (VPN) or because the correspondent host has no IPSec stack

IPSec

Hd

IPHdr IPSec

Trailer

Payload

encrypted

Transport ModeTransport mode must be host to hostadequate for upper layer protocols

Gateways cannot handle fragmentation or multiple routes Hosts share a secret key


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

AH


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

AH Position

Tunnel Mode

Payload

(e.g. TCP Hdr + Data)

Orig

IPHdr

Payload

(e.g. TCP Hdr + Data)AH

Neue

IPHdr

Orig

IPHdr

Authenticated (except for

mutable fields)

Orig

IPHdr

Payload

(e.g. TCP Hdr + Data)Transport Mode

Payload

(e.g. TCP Hdr + Data)AH

Orig

IPHdr

Authenticated (except for

mutable fields)


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Msg Authentication with HMAC

Hash function H may be MD5, SHA-1, or, optionally, others

Goals are:Use available hash functions and implementations

Preserve hash function performance,

Understand cryptographic strength

Allow easy replacement of the hash function if necessary

HMAC (H, K, T) = H(K opad, H(K ipad, T))

K shared key, T text

opad is repeated bytes of 0x5C and

ipad is repeated bytes of 0x36.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Authentication data field is calculated over

IP header fields that either do not change in transit (immutable) or that are predictable in value upon arrival at the endpoint for the AH SA.

Fields that may change in transit and whose value on arrival are unpredictable are set to zero for purposes of calculation at both source and destination.

Examples (IPv4):

immutable fields are Internet Header Length and Source Address.

mutable but predictable field is the Destination Address (with loose or strict source routing).

mutable fields are the Time to Live (TTL) and Header Checksum fields.

The AH header other than the Authentication Data field.

The Authentication Data field is set to zero for purposes of calculation at both source and destination.

The entire upper-level protocol data, which should be immutable in transit (e.g., a TCP segment or an inner IP packet in tunnel mode).


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

ESP


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

ESP Position

Orig

IPHdr

Payload

(e.g. TCP Hdr + Data)Transport Mode

Payload


ESP

Hdr

Orig

IPHdr

Encrypted

ESP

Trail

ESP

Authn

Authenticated

Payload


ESP

Hdr

Tunnel Mode

Payload


Orig

IPHdr

Neue

IPHdr

Orig

IPHdr

Encrypted

ESP

Trail

ESP

Authn

Authenticated


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Encapsulating Security Payload

Encapsulating Security Payload (ESP)

encrypts data contents

format varies based on encryption type

Modes supported by ESP:

Tunnel mode: encrypt entire IP packet plus headers inside another IP packet

Transport mode: do not encrypt headers


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

SA, SAD, SPI

Receiving

IPSec Packets


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Security Associations (SAs)

Logically, a simplex “connection” that affords security services

Typical bi-directional security requires two SAs

Can be established by IKE or manual methods

Used by AH or ESP, not both

Technically, corresponds to one entry in the Security Association Database (SAD)

Key

...

0110100...

...

Security Association Database (SAD)

SPI Dest. IP-Addr. Sec. Prot. Algorithm

... ... ... ...

375 2.2.2.2 AH HMAC-MD5

... ... ... ...

...

...

...

...


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Security Associations (SAs)

For inbound processing: The SA is uniquely identified by the 3 packet fields:

Security Parameters Index (SPI): The SPI assigns a bit string to this SA that has local significance only. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed.

IP destination address: Currently, only unicast addresses are allowed; this is the address of the destination endpoint of the SA, which may be an end-user system or a network system such as a firewall or router.

Security protocol identifier: This indicates whether the association is an AH or ESP security association.

For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Security Associations (SAs, cont.)

A SA determines the following values (= fields of the SAD):

Sequence number counter: A 32-bit value used to generate the sequence number field in AH or ESP headers

Sequence counter overflow: A flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent further transmission of packets on this SA

Anti-replay window: Used to determine whether an inbound AH or ESP packet is a replay, by defining a sliding window within which the sequence number must fall

AH information: Authentication algorithm, keys, key lifetimes, and related parameters being used with AH

ESP information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Security Associations (SAs, cont.)

A SA determines the following values (= fields of the SAD):

Lifetime of this security association: A time interval or byte count after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur

IPSec protocol mode: Tunnel, transport, or wildcard (required for all implementations); these modes are discussed later

Path MTU: Any observed path maximum transmission unit (maxi-mum size of a packet that can be transmitted without fragmentation) and aging variables (required for all implementations)


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Use of SPI, SAD: Receiving an AH-protected package

Received IP packet

AHNormalized IP Packet

CalculatedAuthn. Value

ReceivedAuthn. Value

?=

NormalizationExtraction

CalculationExtraction

AlgorithmParameters

SAD

Accept package

Authentic sender

Integer package

Discard package

SPI

yes no


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

SPD

Sending

IPSec Packets


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Security Policies

For every packet that is to be sent out, the SPD (Security Policy Database) is checked to find how the packet is to be processed. The SPD can specify three actions:

discard,

bypass IPsec, or

apply IPsec processing. Result may be:

all trafic between two computers carried on a single SA,

separate SA used for each application or for each TCP connection.

The SPD also specifies which SAs should be used (if suitable SAs have already been set up) or specifies the parameters for a new SAs to be used.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

SPD: Security Policy Database

Packets are classified according to selectors

SPD matches selectors to determine the appropriate action.

API for creating entries in the security policy database is not standard: left to the IPSec or operating sys provider. (Only PF_KEY available: provides access to security associations for key management systems).


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

SA Selectors

Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors.Selectors are used to filter outgoing traffic in order to map it into a particular SA.

Outbound processing obeys the following general sequence for each IP packet:

Compare the values of the appropriate fields in the packet (the selector fields) against the SPD to find a matching SPD entry, which will point to zero or more SAs.

Determine the SA (if any) for this packet and its associated SPI.

Do the required IPSec processing (that is, AH or ESP processing).


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

SA Selectors

The following selectors determine an SPD entry:

Destination IP address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA (for instance, behind a firewall).

Source IP address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (for instance, behind a firewall).

UserID: UserID is used to identify a policy tied to a valid user or system name.

Data sensitivity level: The data sensitivity level is used for systems providing information flow security (for instance, "Secret" or "Unclassified").


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

SA Selectors

Transport Layer protocol: This value is obtained from the IPv4 protocol or IPv6 Next Header field. This may be an individual protocol number, a list of protocol numbers, or a range of protocol numbers.

IPSec protocol (AH or ESP or AH/ESP): If present, this is obtained from the IPv4 Protocol or IPv6 Next Header field.

Source and destination ports: These may be individual TCP or User Datagram Protocol (UDP) port values, an enumerated list of ports, or a wildcard port.

IPv6 class: This class is obtained from the IPv6 header. It may be a specific IPv6 Class value or a wildcard value.

IPv6 flow label: This label is obtained from the IPv6 header. It may be a specific IPv6 flow label value or a wildcard value.

IPv4 Type of Service (TOS): The TOS is obtained from the IPv4 header. It may be a specific IPv4 TOS value or a wildcard value.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

SPD, SPI, SAD: Sending an AH-protected package

...

...

...

...

Security Policy Database (SPD)

Source IP-Addr. Dest. IP-Addr. Transp. Prot Dest. Port

... ... ... ...

1.1.1.1 2.2.2.2 TCP 80

... ... ... ...

SA

...

...

Key

...

0110100...

...

Security Association Database (SAD)

SPI Dest. IP-Addr. Sec. Prot. Algorithm

... ... ... ...

375 2.2.2.2 AH HMAC-MD5

... ... ... ...

...

...

...

...

IP Hdr

TCP Hdr

Payload

IPSec- Process.

IP Hdr

TCP Hdr

Payload

AH

Selectors


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

IPSec

Documents


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IPSec Documents

Divided in seven groups:

Architecture (general issues, requirements, mechanisms)

Encapsulating Security Payload, ESP (packet form and usage for encryption and some auth)

Authentication Header, AH (packet form and usage for auth)

Encryption Algorithm (how different ones are used)

Authentication Algorithm (using algs for AH and ESP)

Key management

Domain of Interpretation

RFC 241: IP Security Document Roadmap


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IPSec New Drafts (incomplete)

IP Encapsulating Security Payload (ESP)

draft-ietf-ipsec-esp-v3-03.txt

The AES Cipher Algorithms and Their Use With IPsec

draft-ietf-ipsec-ciph-aes-cbc-04.txt

On the Use of SCTP with IPsec

draft-ietf-ipsec-sctp-03.txt

IPsec-NAT Compatibility Requirements

draft-ietf-ipsec-nat-reqts-01.txt

Negotiation of NAT-Traversal in the IKE

draft-ietf-ipsec-nat-t-ike-03.txt

UDP Encapsulation of IPsec Packets

draft-ietf-ipsec-udp-encaps-03.txt


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security Properties of the IPsec Protocol Suite

draft-ietf-ipsec-properties-02.txt

The HMAC-SHA-256-96 Algorithm and Its Use With IPsec

draft-ietf-ipsec-ciph-sha-256-01.txt

Propsal for the IKEv2 Protocol

draft-ietf-ipsec-ikev2-02.txt

Just Fast Keying (JFK)

draft-ietf-ipsec-jfk-04.txt

Design Rationale for IKEv2

draft-ietf-ipsec-ikev2-rationale-00.txt

IP Authentication Header

draft-ietf-ipsec-rfc2402bis-01.txt


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Son-of-IKE Requirements

draft-ietf-ipsec-sonofike-rqts-00.txt

Revised Use of Identity in Successors to IKE

draft-ietf-ipsec-revised-identity-00.txt

Features of Proposed Successors to IKE

draft-ietf-ipsec-soi-features-01.txt

The Internet IP Security PKI Profile of ISAKMP and PKIX

draft-ietf-ipsec-pki-profile-00.txt

Extended Sequence Number Addendum to IPsec DOI for ISAKMP

draft-ietf-ipsec-esn-addendum-00.txt

s


C O

R P

O R

A T

E

T

E C

H N

O L

O G

Y


sSecurity

Jul-02(C) Siemens

Network Security Standardization at the IETF

IPsec and IKE

Part 2


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Contents Part 1

IKE

Main ModeQuick ModeDOIPolicies + ConfigGeneral Structure and Properties of IKEDeficiencies of IKE

IPSec

SA, SAD, SPI: Receiving IPSec PacketsSPD: Sending IPSec PacketsIPsec Documents


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Contents Part 2

SoI

IdentitiesJFKIKEv2Comparison

ESP + AH changes


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

SoI

Identity

+ Authn Methods


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Identity Protection in SoI. New Payloads:

TrustedRoot

IDAccepted

FullID: Types:

1 PKIX certificate

2 Certificate bundle

Sequence of PKIX certificates.

3 Hash-and-URL of PKIX certificate

The first 20 octets are the SHA-1 hash of a certificate; the rest is a URL that resolves to the certificate.

4 URL to a PKIX certificate bundle

5 PKIX keyIdentifier

Identifies a self-signed certificate that the receiver has already pre-loaded.

6 IDForSharedSecret

e.g.: IDForSharedSecret is the username, and the key added to the HMAC is the password.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

JFK

s


C O

R P

O R

A T

E

T

E C

H N

O L

O G

Y


sSecurity

Jul-02(C) Siemens


Aiello, Bellovin, Blaze, Canetti, Ioannidis, Keromytis, Reingold


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Just Fast Keying (JFK): Protocol Properties

Only one phase. New: provision for pre-shared secret key mode (“lightweight JFK”)Two protocol variants:

JFKi: provides identity protection for the initiator against active attacks, and no protection for the responder. (Assume: that the responder is a server and his identity is known to everyone). JFKr: provides active identity protection for the responder and passive identity protection for the initiator.

Provides Perfect Forward Secrecy IntervalProtects against Memory and Computational DoS attacksShort negotiation phase

If the Responder accepts the group proposed by the Initiator, his exponential must be in the same group. Otherwise, he may respond with an exponential from any group of his own choosing. The field GRPINFOr lists what groups the Responder finds acceptable.

Certificate handling, path validation etc. outside the scope


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Legacy Authentication is not supported -> IPSRA should be used instead

Frequent rekeying is assumed not to be necessary (especially if AES is used)

SA negotiation: Responder proposes and the initiator can choose what he likes -> no complex rules for selecting the best choice / These parameters are used for the protocol itself. IPSec ESP/AH negotiation will be added in the near future.

JFK allows to prove that the protocol exchange took place.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Just Fast Keying (JFKi)

I->R: Ni, gî, IDr'

R->I: Ni, Nr, g^r, GRPINFOr, IDr,

SIG{r}(g^r, GRPINFOr),

HMAC{HKr}(g^r, Nr, Ni, IPi)

I->R: Ni, Nr, gî, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi),

E{Ke}(IDi, sa, SIG{i}(Ni, Nr, gî, g^r, IDr, sa))

R->I: Ni, Nr,

E{Ke}(SIG{r}(Ni, Nr, gî, g^r, IDi, sa, sa'), sa')


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Just Fast Keying (JFKr)

I->R: Ni, gî

R->I: Ni, Nr, g^r, GRPINFOr,

HMAC{HKr}(g^r, Nr, Ni, IPi)

I->R: Ni, Nr, gî, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi),

E{Ke}(IDi, IDr' sa, SIG{i}(Ni, Nr, gî, g^r, GRPINFOr)),

HMAC{Ka}('I', E{Ke}(IDi, IDr', sa, SIG{i}(Ni, Nr, gî, g^r, GRPINFOr)))

R->I: Ni, Nr, E{Ke}(IDr, sa', SIG{r}(g^r, Nr, gî, Ni)),

HMAC{Ka}('R', E{Ke}(IDr, sa', SIG{r}(g^r, Nr, gî, Ni)))


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


gî, g^r and SIG{r}(g^r) need not to be computed with every protocol session. The nonce values prevent two successive session keys (Ke) from being the same.

Keys are computed based on the values Ni, Nr, gîr:

(Ke=HMAC(gîr, Ni, Nr, 1)

Ka=HMAC(gîr, Ni, Nr, 2)

Kir=HMAC(gîr, Ni, Nr, 0) used by IPsec

Ks=HMAC(gîr, Ni, Nr, 1) used in lightweight version)

Msg 1: The group used by the initiator is encoded into the value gî.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


State at the responder is created after successful verification of Msg (3).

The local key HKr (used for the HMAC computation in Msg (2) and (3)) is stored and used only locally at the responder.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

IKE v2

s


C O

R P

O R

A T

E

T

E C

H N

O L

O G

Y


sSecurity

Jul-02(C) Siemens

IKEv2

Harkins, Kaufman, Perlman


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2: Protocol Properties

Collapse IKEv2 description into a single document

Reduce Number of Authentication Modes

IKEv1 Aggressive Mode removed

Keep two phases (IKE SA, Child SAs)

Reduce the number of possible error states by making the protocol reliable (all messages are acknowledged) and sequenced.

Optional DoS protection at the expense of an additional roundtrip (allowing the Responder, if under attack, to require return of a cookie before the Responder commits any state to the exchange).


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2 Protocol Properties

No SA lifetime negotiation – every node is responsible for enforcing his own lifetime policy

Rekeying can be executed by both nodes at any time.

IKE and Child SAs can be rekeyed

Cookie mechanism is modified.

IKEv1 ISAKMP SA is identified by (Initiator Cookie,

Responder Cookie) Cookie values chosen randomly to prevent

reflection attacks

IKEv2 IKE SA is identified by the recipient’s

SA Only the requirement to be different

IKEv1 & IKEv2: Both cookie values appear in the header, but their order is different The Cookie serves for SA indexing + limited protection against DoS


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2: Protocol Properties

Payload negotiation simplified: Within a proposal multiple algorithms of the same type can be included.

SA

ProposalNumber

Protocol (IKE – ESP – AH – IPComp)

SPI

Transform

Type (Encryption, Integrity Protection, Authentication, D-H Group, Compression)

Transform ID (DES, IDEA, etc.)

Proposal 2


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2

Establishing an IKE-SA/Phase I

I->R: HDR, SAi1, gî, Ni

R->I: HDR,SAr1,g^r, Nr,[CERTREQ]

I->R: HDR*, IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2,

TSi, TSr

R->I: HDR*, IDr, [CERT,] AUTH, SAr2, TSi, TSr

TS: Traffic Selector (Each selector has a source port; a destination port; and either a range or addresses, a subnet, or a single address. The Responder is allowed to narrow the choices by selecting a subset of the traffic.)

SKEYSEED = prf(Ni | Nr, gîr)

SK_d = prf(SKEYSEED, gîr | Ni | Nr | C-I | C-R | 0)

SK_a = prf(SKEYSEED, SK_d | gîr | Ni | Nr | C-I | C-R | 1)

SK_e = prf(SKEYSEED, SK_a | gîr | Ni | Nr | C-I | C-R | 2)

(C-I, C-R: Cookies, part of the header HDR)


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2

Generating Keying Material for the IKE-SA

The SKEYSEED value is created after the second Msg to protect Msg (3) and Msg (4).

Prf: HMAC_MD5 and HMAC_SHA

Authentication is accomplished by signing the content of the previous messages (AUTH payload) . Optionally a certificate or certificate chain may be included. Used algorithms may be: RSA-signed PKCS1-padded-SHA1-hash, DSS-signed SHA1-hash, etc.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2

Establishing Child-SA/Phase III->R: HDR*, SA, Ni, [g^i,] TSi, TSr

R->I: HDR*, SA, Nr, [g^r,] TSi, TSr

Generating Keying Material for IPsec SAs KEYMAT = prf(SK_d, protocol | SPI | Nin | Nout ) KEYMAT = prf(SK_d, g(p2)^ir | protoc | SPI | Nin |

Nout )

An Child SA results in two IPSec Sas (one inbound and one outbound SA).


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

IKEv2

CREATE-CHILD-SA (Phase II) Exchange

Phase II exchange allows to create or delete a child-SA, delete the IKE-SA, or deliver information such as error conditions.

Phase II is integrity protected and encrypted with the keys of Phase I.

Both parties may initiate the Phase II exchange.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Son of IKE / Comparison [1]

Cryptographic features = Identity protection: who is protected, kinds of attacks = Perfect forward secrecy (PFS) > (=) Authentication styles > Number of crypto operations = Plausible deniability = Formal proofs of security

>>: much better IKEv2>: somewhat better IKEv2=: more or less the same0: no one has this feature (the same)<>: quite different (probably a matter of taste: simplicity JFK vs

negotiation IKEv2)<: somewhat better JFK<<: much better JFK

(in parenthesis: not now, but it will probably be soon)


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Son of IKE / Comparison [1a]

| Sign | Validate | Symmetric | Hash | | signature | crypt |-------+---------+-----------+-----------+--------JFKr | i:1 r:1 | i:1 r:1 | i:2 r:2 | i:2 r:4-------+---------+---------- +-----------+--------JFKi | i:1 r:1 | i:2 r:1 | i:2 r:2 | i:1 r:2-------+---------+---------- +-----------+--------IKEv2 | i:1 r:1 | i:1 r:1 | i:2 r:2 | i:2 r:2sig | | | |-------+---------+---------- +-----------+--------IKEv2 | i:0 r:0 | i:0 r:0 | i:2 r:2 | i:3 r:3secret | | | |

In other words, the basic difference between JFKr and IKEv2 in signature mode is that JFKr requires two more hashes for the responder.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Son of IKE / Comparison [1b]

For rekeying an existing IPsec SA, the summary looks like:

| Sign | Validate | Symmetric | Hash | | signature | crypt |-------+---------+-----------+-----------+--------JFKr | i:1 r:1 | i:1 r:1 | i:2 r:2 | i:2 r:4-------+---------+---------- +-----------+--------JFKi | i:1 r:1 | i:2 r:1 | i:2 r:2 | i:1 r:2-------+---------+---------- +-----------+--------IKEv2 | i:0 r:0 | i:0 r:0 | i:2 r:2 | i:2 r:1

In other words, for rekeying, JFKr requires two more signatures, two more signature validations, and three more hashes.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Protocol mechanics = DoS protection = Size of messages = Preferred ID for responder 0 Birth certificates

(Bob should have a monotonically increasing number that increases each time Bob restarts. When Bob restarts, he signs a message saying, "this is my incarnation number". When Bob creates an SA, Bob optionally sends his birth certificate. Alice can optionally keep this certificate with her SA. Then, if Alice ever receives an error message from Bob with a birth certificate with a higher incarnation number, she can remove all SAs associated with Bob's previous incarnation.)


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


One or two phases >? Control channel vs. separate protocols > Creating multiple SAs for a single pair of entities > Dead peer detection > SA deletion > SA rekeying > Authenticated error messages > Authenticated informational messages


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


SA creation style <> Cryptographic agreement <> Agreement of key exchange keys <> Agreement of IPsec SA cryptographic algorithms <> Scope of proposals > SPD entries


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Wire protocol issues > Message encoding > Port number > Future versions of the protocols > Code-preservingness >> Extensibility of the protocols


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Son of IKE - Next Steps

Somehow choose the winner!


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens


Security

Sep-01(C) Siemens



Security

Sep-01(C) Siemens

ESP + AH

changes


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

ESP changes

Confidentiality-only service -- now a MAY, not a MUST.

SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA.

Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications.

Payload data -- broadened model to accommodate combined mode algorithms.

Padding for improved traffic flow confidentiality -- added requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

ESP changes

Next Header -- added requirement to be able to generate and discard dummy padding packets (Next Header = 59)

ICV -- broadened model to accommodate combined mode algorithms.

Algorithms -- Added combined confidentiality mode algorithms.

Inbound and Outbound packet processing -- there are now two paths -- (1) separate confidentiality and integrity algorithms, (2) combined confidentiality mode algorithms. Because of the addition of combined mode algorithms, the encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

AH changes

SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA.

Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications.


sSecurity Sep-01

(C) Siemens



sSecurity

Jul-02(C) Siemens

Are there any questions?

network security standardization at the ietf

Documents