Security Protocols III

Security Protocols III

Luca Vigano

Institut fur InformatikAlbert-Ludwigs-Universitat Freiburg

IT-Security: Theory and Practice (WS02)

Luca Vigano 1

Roadmap

• The Kerberos Protocol.

• Network security:

– TCP/IP and IPsec.

– The IKE Protocol.

IT-Security: Theory and Practice (WS02) 03.12.02

Luca Vigano 2

Kerberos

• Authentication in heterogeneous networks.

– A distributed authentication service allowing a

client to prove its identity to a server.

– Optional: data integrity and confidentiality.

• Developed as part of Project Athena (MIT, 80’s).

– Version IV (1989) still used at many sites.

– Version V (1993) is now the standard Kerberos.

• Industry acceptance (see also next lectures/labs):

– Kerberos V: RFC 1510 (1993).

– draft-ietf-cat-kerberos-revisions-09.txt

– Distributed Computing Environment (DCE).

– Microsoft Windows 2000.

In Greek mythology,

Kerberos (a.k.a.

Cerberus) was

the 3-headed

dog guarding the

entrance to Hades.


Luca Vigano 3

Kerberos• Based on Needham-Schroeder Shared-Key Protocol:

M1. A → S : A,B, N1

M2. S → A : {N1, B, KAB, {KAB, A}KBS}KAS

M3. A → B : {KAB, A}KBS

M4. B → A : {N2}KAB

M5. A → B : {N2 − 1}KAB

• Timestamps:

– assure freshness (e.g. session keys),

– to prevent replay attacks (instead of nonces),

– have a lifetime (minutes, hours, ...),

– require synchronization of clocks.

• A “ticket-granting” service supports subsequent

authentication without re-entry of passwords.


Luca Vigano 4

Kerberos Version IV: Dramatis Personae

• Kerberos System:

– KAS: Kerberos Authentication Server.

– TGS: Ticket Granting Server.

– Database of shared keys of registered users.

∗ Database can be accessed only by KAS.

∗ Shared keys assumed secure.

• Client A.

• Network resource B.

SystemKerberos

KAS TGS

database

AB


Luca Vigano 5

Kerberos Version IV: The Protocol

KerberosSystem

KAS TGS

database

AB

12 3

4

5

6

I. Authentication: Messages 1 and 2.

II. Authorization: Messages 3 and 4.

III. Service: Messages 5 and 6.


Luca Vigano 6

Kerberos Version IV: The Protocol (slightly simplified)

KerberosSystem

KAS TGS

database

AB

12 3

4

5

6

I. AUTHENTICATION1. A → KAS : A, TGS, TA12. KAS → A : {AuthKey, TGS, TKAS, {A, TGS, AuthKey, TKAS}KTGS︸︷︷︸

AuthTicket

}KAS

II. AUTHORIZATION3. A → TGS : {A, TGS, AuthKey, TKAS}KTGS︸︷︷︸

AuthTicket

, {A, TA2}AuthKey︸︷︷︸authenticator

, B

4. TGS → A : {ServKey, B, TTGS, {A, B, ServKey, TTGS}KBS︸︷︷︸ServTicket

}AuthKey

III. SERVICE5. A → B : {A, B, ServKey, TTGS}KBS︸︷︷︸

ServTicket

, {A, TA3}ServKey︸︷︷︸authenticator

6. B → A : {TA3 + 1}ServKey


Luca Vigano 7

Kerberos Version IV: Authentication Phase

KerberosSystem

KAS TGS

database

AB

12 3

4

5

6

1. A → KAS : A, TGS, TA12. KAS → A : {AuthKey, TGS, TKAS, {A, TGS, AuthKey, TKAS}KTGS︸︷︷︸

AuthTicket

}KAS

• A logs onto workstation to access network.

• KAS accesses database and sends A a session key AuthKey and

an encripted ticket AuthT icket.

• AuthKey has lifetime of several hours: A is automatically logged

out when AuthKey expires.


Luca Vigano 8

Kerberos Version IV: Authorization PhaseKerberosSystem

KAS TGS

database

AB

12 3

4

5

6

3. A → TGS : {A, TGS, AuthKey, TKAS}KTGS︸︷︷︸AuthTicket


, B

4. TGS → A : {ServKey, B, TTGS, {A, B, ServKey, TTGS}KBS︸︷︷︸ServTicket

}AuthKey

• Occurs each time A want to access network resource B.

• A presents AuthT icket from M2 to TGS together with

authenticator (to show that AuthT icket was issued to her).

• TGS issues A a new session key ServKey (lifetime of few

minutes) and a new ticket ServT icket.


Luca Vigano 9

Kerberos Version IV: Service Phase

KerberosSystem

KAS TGS

database

AB

12 3

4

5

6

5. A → B : {A, B, ServKey, TTGS}KBS︸︷︷︸ServTicket


6. B → A : {TA3 + 1}ServKey

• Occurs each time A wants to access network resource B.

• A presents ServKey from M4 to B along with new

authenticator.

• B replies.


Luca Vigano 10

Limitations of Kerberos IVM1. A → KAS : A, TGS, TA1

M2. KAS → A : {AuthKey, TGS, TKAS, {A, TGS, AuthKey, TKAS}KTGS︸︷︷︸AuthTicket

}KAS

M3. A → TGS : {A, TGS, AuthKey, TKAS}KTGS︸︷︷︸AuthTicket


, B

M4. TGS → A : {ServKey, B, TTGS, {A, B, ServKey, TTGS}KBS︸︷︷︸ServTicket

}AuthKey

M5. A → B : {A, B, ServKey, TTGS}KBS︸︷︷︸ServTicket


M6. B → A : {TA3 + 1}ServKey

• M2: double encryption is redundant ⇒ eliminated in Kerberos V.

• Old authenticators may be stored for later replay, at least during the tickets’lifetimes. Servers should store all tickets to prevent this, but can’t always do so.

• Authenticators rely upon synchronized and uncompromized clocks. If a host iscompromized, then the clock can be compromized and replay is easy.

• Relies upon trustworthy clients and servers, and upon the security of the TGSand the Kerberos server.

Some of these limitations apply also to Kerberos V (see also next labs).


Luca Vigano 11

Obtaining and Using Kerberos

• Obtaining Kerberos:

– MIT: http://web.mit.edu/kerberos/www/– Many other websites.

– Also: distributions for Linux and Windows 2000.

• Several protocols/applications use Kerberos, including:

– Mobile IP (SeaMoby), Resource Reservation Protocol (RSVP),

Radius/Diameter,

– Telnet, FTP, SNMP, TLS,

– DHCP, GSS-API, SASL, DMS (via TKEY),

– Windows 2000 for all authentication procedures,

– IKE (running IKE Phase 2, over Artifical Kerberos IKE SA),

– ...


http://web.mit.edu/kerberos/www/

Luca Vigano 12

Roadmap






Luca Vigano 13

TCP/IP

Transmission Control Protocol/Internet Protocol TCP/IP: a suite of

communications protocols (the two main ones are TCP and IP) used

to connect hosts on the Internet.

• De facto standard for transmitting data over networks.

• Four layers:

ApplicationTransport/sessionNetwork (Internet)Link (Interface)

Telnet, FTP, HTTP, RPC, SMTP, SET, ...TCP, UDP (User Datagram (i.e. packets) Protocol)IP, ...Network interface & device drivers (IEEE 802.x, PPP, SLIP)

Note: in the Internet model some of the seven layers (Application,

Presentation, Session, Transport, Network, Link, Physical) of the

ISO/OSI model protocol have been collapsed and only four

remain.


Luca Vigano 14

TCP/IP (cont.)

• Transmission Control Protocol (TCP): enables two hosts to

establish a connection and exchange stream of data.

It guarantees delivery of data and that packets will be delivered in

the same order in which they were sent.

• Internet Protocol (IP): specifies format of packets and addressing

scheme.

– IP ≈ postal system: one can address a package and drop it in

the system, but there is no direct link between sender and

recipient.

– Current version is IPv4 (IPv6 under development).


Luca Vigano 15

IP Security (IPsec)

A set of protocols to support secure exchange of packets at IP layer.

• Provides security for everyone using IP, without changing the

interface to IP:

ApplicationTransport/session

IPsec [Network (Internet)]Link (Interface)

• Developed by the IPsec Working Group of the Internet

Engineering Task Force (IETF).

• IPsec has been deployed widely to implement Virtual Private

Networks (VPNs).

A VPN establishes a secure connection between the gateways of

two subnets that are not directly connected.


Luca Vigano 16

IPsec (cont.)• IP has no specific mechanism for end-to-end data reliability, for

sequencing of datagrams (i.e. packets), or for security.

– Header of an IP datagram contains (among other fields) a

source IP address and a checksum that allows the receiver to

detect corruption of the datagram.

– However: checksum is only a cyclic redundancy check, and thus

offers no defence against intentional modifications of diagram.

– Also: source address is not necessarily the real/correct one.

• IPsec includes two major security mechanisms:

– Authentication Header (AH) protects the integrity and

authenticity of IP datagrams (but not their confidentiality).

– Encapsulating Security Payload (ESP) protects confidentiality

(depending on encryption algorithm used, it may also protect

integrity and authenticity).


Luca Vigano 17

IPsec: Authentication Header (AH)

Location and syntax of Authentication Header:

e.g. a MAC or a digital signaturevariable number of 32−bit words containing the authentication data,

32 bits

Next headertype of payload after AH

Payload lengthlength of AH in 32−bit words (−‘2’)

Reservedfor future use

Security Parameters Index (SPI)field identifying the SA for the datagram (value 0 indicates that no SA exists)

Sequence number field counter value, used to detect replayed packets (to be extended to 64 bits)

Authentication data

IPv6 header Hop−by−hop routing AH Dest. options TCP Data

A Security Association (SA) specifies the protocol format used, the cryptographicand hashing algorithm used, and other features for secure communication.


Luca Vigano 18

IPsec: Encapsulating Security Payload (ESP)ESP supports two encryption modes:

• Transport mode encrypts only the data portion (payload) of each packet, butleaves the header untouched.

• Tunnel mode is more secure as it encrypts both the header and the payload.– The entire IP datagram is encapsulated within the ESP.– An outer IP header is added that contains some other IP address, typically

the address of a security gateway. The inner IP header contains originalsource/destination addresses and is completely protected by the AH.

Location and syntaxof ESP header:

Opaque transform dataprotected field containing further parameters relevant for the processingof the cryptographic algorithm

32 bits

Security Parameters Index (SPI)field identifying the SA for the datagram (value 0 indicates that no SA exists)

IP header Other IP headers Encrypted dataESP header


Luca Vigano 19

Roadmap






Luca Vigano 20

The Internet Key Exchange (IKE) Protocol

• A key exchange protocol being developed by the IPsec Working

Group of the IETF.

• IETF recently advanced the IPsec protocols to Draft Standard.

– These protocols include mechanisms for establishing a secure

channel, via cryptographic key exchange, over an insecure

medium.

– Such a channel can be used for ensuring confidentiality,

authentication, and/or integrity of the communications between

the two parties.


Luca Vigano 21

The Internet Key Exchange (IKE) Protocol (cont.)

• IKE provides security support for client protocols of the IP.

– It does not just establish keys.

– It also establishes Security Associations (SAs) that specify

∗ the protocol format used,

∗ the cryptographic and hashing algorithm used,

∗ other necessary features for secure communication.

• IKE is flexible: it supports a number of different types of key

exchange options, including

– digital signatures,

– public-key encryption, and

– shared-key encryption.

• IKE tries to be a “swiss army knife” and is thus quite complex:

several options, alternative subprotocols, and nested encryptions.


Luca Vigano 22

The Internet Key Exchange (IKE) Protocol (cont.)

• IKE has evolved from a number of different protocols, including

ISAKMP, Oakley, the Station-to-Station protocol, and SKEME.

– ISAKMP (Internet Security Association and Key Management

Protocol): provides a framework for establishing SAs and

cryptographic keys, but does not prescribe any particular

authentication mechanism.

– Oakley: a suite of key agreement protocols in which two parties

generate a key jointly.

• To explain the algorithms and protocols of IKE and discuss the

types of security that the various IKE modes provide, we start

with the simple key exchange mechanism of Diffie-Hellman, which

IKE (usually) uses to generate shared key material.


Luca Vigano 23

The Diffie-Hellman ProtocolBasic Diffie-Hellman key-exchange: initiator I and responder R

exchange “half-keys” to arrive at mutual session key k.

Compute X = g mod px

Compute Y = g mod py

Compute k = Y mod px Compute k = X mod py

Choose g, pGenerate x

I R

Generate y

(1) X [,g,p]

(2) Y

• Relies on the difficulty of computing the discrete logarithm of an exponentiatednumber modulo a large prime number.

• Supports perfect forward secrecy in IKE (and other protocols):

– Even if a key used to protect part of a session is compromised, other keysused to protect later parts are not compromised.

– By periodically negotiating new keys (and keying material).


Luca Vigano 24

The Diffie-Hellman Protocol (cont.)



Compute k = Y mod px Compute k = X mod py


I R

Generate y

(1) X [,g,p]

(2) Y

• I and R agree on Diffie-Hellman group (g,p) (a large prime p and an integer g).

– Group (g,p) is typically chosen by I and sent to R; there are well-knowngroups referred to with unique group identifier numbers.

– Group may be implicit (e.g. 2 parties always use same group).

• I generates large (at least 180 bits in length) random integer x and sendshalf-key X = gx mod p (and optionally also the group).

• R generates large random integer y and sends half-key Y = gy mod p.

• I and R compute key k = Yx mod p = Xy mod p.


Luca Vigano 25


• Advantage: key k is at least as strong as the strongest half-key:

neither I nor R can completely sabotage the resulting key.

• Disadvantage: no authentication of participants, no prevention of

replay or flooding attacks.

• Denial of Service (DoS) attack on R via flooding:

Attacker sends series ofrequest packets, each withdifferent spoofed source IPaddress Xi, so that R mustprocess each request.

Expensive exponentiation,hence flooding.

X , X , ..., X1 2 n

Generate seriesof random numbers

Generate y1y1Compute Y = g mod p1

Compute Y = g mod p

ynCompute Y = g mod pn

X [,g,p]n

Generate yn

X [,g,p]2

Choose g, p

I R

Generate y22

y2

1X [,g,p](1)

(2)

(n)


Luca Vigano 26


• In general: no protection against DoS attacks and flooding.

• Weak form of protection against floodings: cookies.

I and R send also random cookiesCI and CR, and associate cookiepair with peer’s IP address.

Messages containing cookiepair associated with different IPaddresses are discarded.

Hence, attacker must complete acookie exchange for each addressit spoofs.

Attacker must also be able toread CR, which is sent to spoofedaddress.



Validate cookieGenerate y

Compute k = Y mod pxyCompute k = X mod p

(2) C , C I R

(1) C I

Generate C R

Generate C I

(3) C , C , X [,g,p] I R

(4) C , C , Y I R

I R


Validate cookie


Luca Vigano 27

• Cookies also uniquely identify a particular key exchange among

several occurring (sequentially or concurrently) between two hosts.

(Since IKE implementations often use source/destination ports of 500,

concurrent exchanges between 2 hosts can be demultiplexed via cookie pairs.)

• Diffie-Hellman is subject also to a man-in-the-middle attack:


R

Compute Z = g mod pz


RCompute k = Z mod p yCompute k = Z mod pI x


I A

Generate z(1) X [g,p]

(2) Z

(1’) Z [g,p]

(2’) Y

ICompute k = X mod p z

Generate y

RCompute k = Y mod p z

– Can be prevented by mutual authentication between I and R.– Typically: add an exchange of digitally signed identification (ID) tokens.


Luca Vigano 28

The IKE Protocol in DetailIKE is a protocol suite for establishing and maintaining SAs.

• Typical key establishment protocol: one phase, in which two

parties use “master” keys to establish shared keying material.

• IKE proceeds in two such phases:

– Phase 1: two parties negotiate an SA.

They agree on keeying material and mechanisms (e.g.

crypto-algorithms, hash functions, ...) they will use in phase 2.

– Phase 2: the SA of phase 1 is used to agree upon new SAs

(i.e. new keys and mechanisms) that will be used to protect and

authenticate further communications.

The SA of phase 1 is bidirectional: the initiator of phase 1 can be

either initiator or responder in phase 2.


Luca Vigano 29

IKE Phase 1

Establish a secure channel so that phase 2 negotiations can occur

privately.

• Negotiating an ISAKMP SA (shared keys, algorithms) using

Diffie-Hellman (DH) exchange cookies and an ID exchange.

• Given such an SA, all IKE communication between initiator I and

responder R is protected with encryption and an integrity check,

and is authenticated.

• To protect against DoS and man-in-the-middle attacks, cookies

are used and authentication of both parties is performed.

Typically, exchange of authenticated IDs occurs after DH

exchange, so that DH key material can be used to encrypt the

messages in the authentication phase.


Luca Vigano 30

IKE Phase 1 (cont.)Phase 1 offers two modes (both resulting in the desired SA):

• Main mode:– Consists of 6 messages exchanged between I and R.

– Offers identity protection and considerable flexibility in terms of

the parameters and configurations that can be negotiated.

• Aggressive mode: is faster but without protection.– It consists of a 3-way handshake between I and R.

– This exchange occurs without identity protection, except when

public-key encryption is used for authentication.

• Each mode has 4 variants, based on the authentication method

(pre-shared key, digital signatures, and 2 public-key variants).

The derivation of keying material and message contents depend

on the authentication scheme used.


Luca Vigano 31

IKE Phase 1, Main Mode (simplified)

Generate CI

Generate CR



Validate cookieGenerate y

Validate ID I

Validate ID R

Validate cookie

(1) C , ISA I I

(2) C , C , ISA I R R

(3) C , C , [,g,p], N I R I

(4) C , C , Y, N I R R

(5) C , C , {ID , AUTH } I R I I K

(6) C , C , {ID , AUTH } I R R R K

Compute k = Y mod pxyCompute k = X mod p

I R


Validate cookie

Validate cookie


Luca Vigano 32

IKE Phase 1, Main Mode (cont.)(1) I → R : CI, ISAI

(2) R → I : CI, CR, ISAR

• (1): ISAI (ISAKMP SA data from I) includes a series of proposals

and a list of algorithms for each proposal.

• (2): ISAR (ISAKMP SA data from R) consists of the proposals

that were accepted and the algorithm chosen for each.

Example negotiation (fails if R does not support any of I’s proposals):

I R(1) Proposal: ENC = DES or 3−DES, AUTH = MD5 Proposal: ENC = IDEA, AUTH = SHA−1

(2) Proposal: ENC = 3−DES, AUTH = MD5

Proposal chosen

All IPsec implementations are required to support DES/3-DES and MD5.


Luca Vigano 33

IKE Phase 1, Main Mode (cont.)

(1) I → R : CI, ISAI


(3) I → R : CI, CR, X [, g,p], NI

(4) R → I : CI, CR, Y, NR

(5) I → R : CI, CR, {IDI, AUTHI}K

(6) R → I : CI, CR, {IDR, AUTHR}K

• Messages (3) and (4) contain the half-keys and nonces of I and R.

• Messages (5) and (6) are encrypted with the algorithm negotiated

by the ISAKMP SA of (1) and (2) (key K depends also on

half-keys).

– IDI and IDR are a (presumably unique) identification of a user

or host (e.g. an IP address, fully-qualified domain name,

certificate, or email address).

– AUTHI and AUTHR is authentication data in form of a MAC.


Luca Vigano 34

IKE Phase 1, Main Mode (cont.)• As remarked, each mode has 4 authentication method variants: pre-shared key,

digital signatures, and 2 public-key variants.

• For example, Main Mode with Digital Signatures authentication is:

(1) I → R : CI, ISAI


(3) I → R : CI, CR, gx, NI

(4) R → I : CI, CR, gy, NR

(5) I → R : CI, CR, {IDI, SIGI}SKEYIDe

(6) R → I : CI, CR, {IDR, SIGR}SKEYIDe

SKEYID = h(NI,NR, gxy)SKEYIDd = h(SKEYID, gxy,CI,CR, 0)SKEYIDa = h(SKEYID,SKEYIDd, gxy,CI,CR, 1)SKEYIDe = h(SKEYID,SKEYIDa, gxy,CI,CR, 2)HASHI = h(SKEYIDa, gx, gy,CI,CR, ISAI, IDI)HASHR = h(SKEYIDa, gx, gy,CR,CI, ISAR, IDR)SIGI = {HASHI}K−1

I

SIGR = {HASHR}K−1R


Luca Vigano 35

IKE Phase 1, Aggressive Mode (simplified)

• Considerably faster than main mode but without protection.

• Fewer messages and encryptions, although, essentially, the same

information is transmitted.

– It consists of a 3-way handshake between I and R.

– This exchange occurs without identity protection, except when

public-key encryption is used for authentication.

• For example, Aggressive Mode with Digital Signatures

authentication is:

(1) I → R : CI, ISAI, gx, NI, I(2) R → I : CI, CR, ISAR, gy, NR, IDR, SIGR

(3) I → R : CI, CR, IDI, SIGI


Luca Vigano 36

IKE Phase 2

Protected by the SA established in phase 1, establish new SAs that

can be used to protect “real” communication (i.e. the IPsec SA).

• Quick Mode:

– Establish new SAs (e.g. for ESP or AH).

• New Group Mode:

– Negotiate new parameters of the SAs (e.g. change

cryptographic group).

– This mode does not establish new SAs (and it does not replace

or preempt quick mode).


Luca Vigano 37

IKE Phase 2, Quick Mode (simplified)Establish new SAs (e.g. for ESP or AH).

• If perfect forward secrecy is required, quick mode supports a new DH exchange(optional message parts).

• Since multiple quick mode negotiations may take place simultaneously betweentwo participants, and since all use the cookie pair of phase 1, each negotiationis assigned a unique identifier.

Message identifier MID is part of generic ISAKMP header included in all IKEpackets.

• Messages are encrypted with the data of phase 1.

• The new key for use with the newly established SA is

NEWKEY = h(SKEYIDd, k |protocol |SPI |NI |NR)

where protocol and SPI are the protocol and SPI fields of the ISAKMPproposal payload, and k is a key produced by the DH exchange for perfectforward secrecy.


Luca Vigano 38

Generate x

Compute HASH(1)

[ Choose g, p

xCompute X = g mod p ]

(1) C , C , HASH(1), SA , N , [, X [,g,p]] [,ID , ID ] I R I I I R

(2) C , C , HASH(2), SA , N , [, Y [,g,p]] [,ID , ID ] I R R R I R

(3) C , C , HASH(3) I R

[ Compute k = Y mod p ]x

y[ Compute k = X mod p ]

Compute Y = g mod p ] y

I R

Validate HASH(2)

Compute HASH(3)

Validate HASH(3)

Validate HASH(1)

Compute HASH(2)

[ Generate y

HASH(1) = h(SKEYIDa,MID, |SAI |NI |X | IDI | IDR)HASH(2) = h(SKEYIDa,MID, |SAR |NI |NR |Y | IDI | IDR)HASH(3) = h(SKEYIDa, 0 |MID |NI |NR)


Luca Vigano 39

Complexity of IKE

• Protocol suite for establishing and maintaining SAs, and thus

provide security support for client protocols of the IP.

• IKE is very efficient but also complex due to several options,

alternative subprotocols, and nested encryptions.

• Preliminary formal analyses of IKE have shown some

vulnerabilities... more detailed analyses needed!


Luca Vigano 40

Bibliography

• See the webpages and RFCs of the IETF for information on

Kerberos, TCP/IP, IPsec, IKE, ...

• web.mit.edu/kerberos

• IPv6 Authentication Header and Encapsulated Security Payload:

www.tml.hut.fi/Opinnot/Tik-110.551/1996/ahesp.html

• Dieter Gollmann. Computer Security. Wiley, 2000.

• John Clark and Jeremy Jacob: A survey of authentication protocol

literature, 1997. www.cs.york.ac.uk/~jac/

• webopedia.com


web.mit.edu/kerberos

www.tml.hut.fi/Opinnot/Tik-110.551/1996/ahesp.html

www.cs.york.ac.uk/~jac/

webopedia.com

Documents

Security Protocols III