IPSec VPN. JTO Rennes 27 Mars. Bertrand Wallrich

IPSec VPN

Bertrand Wallrich

JTO

Rennes

27 Mars

2

Plan

1. Généralités

2. Rappels sur le chiffrement

3. VPN site à site : IPSec

4. Rappels sur PPP

5. VPN client : PPTP, L2F, L2TP

Plan

1. Généralités

2. Rappels sur le chiffrement

3. VPN site à site : IPSec

4. Rappels sur PPP

5. VPN client : PPTP, L2F, L2TP

4

Généralités

n

Les VPN peuvent être utilisés pour différents types d’accès :

n

Utilisateur distant

n

Intranet

n

Extranet

n

Les utilisateurs distants sont des utilisateurs internes de confiance qui ont besoin de pouvoir accéder aux

ressources depuis des endroits distants

n

L’accès Intranet est nécessaire à partir de tous les sites distants

n

L’accès Extranet limite les utilisateurs externes à

l’information qui les concerne.

Sites distants

Remote Office/Branch Office (ROBO)

6

Utilisateurs distants

n

Télétravailleur :

n

Cable

n

Modem

n

ADSL

n

Wavelan , partages de lignes ADSL

n

Numéris…

n

Nomades

n

ADSL dans les hôtels

n

Modem

n

GPRS

n

Ethernet temporaire chez le client, fournisseur, site visit é…

n

Expatriés

n

En permanence dans un autre réseau.

Partenaires professionnels

n

Fournisseurs / clients :

n

Accès extranet, limité

n

Infogérance

n

Accès limité.

n

Accès administrateur.

n

Centres d’appels

n

Accès sous ensemble de l’intranet.

ACCES AVEC LIMITATIONS

Accès restreints suivant les tunnels.

Protection individuelle des partenaires.

8

Menaces & objectifs

n

Menaces :

1.

Interruption (DoS) Le VPN ne peut rien .

2.

Interception (sniffing)

3.

Usurpation d'identité (spoofing)

4.

Modification ( 2 + 3 , man in the middle)

n

VPN Site à site è

n

Se protéger contre les "ISPs" traversés.

n

Se protéger contre 3. (Authentification des machines/réseaux)

n

VPN utilisateur è

n

Se protéger contre les "ISPs" traversés.

n

Se protéger contre le site d'accueil.

n

Accéder au réseau interne indépendemment de :

n

Des adresses IPs

n

Des applications

Les solutions de VPN

n

Services VPN

n

Les fournisseurs de service Internet (ISP)

n

Basé sur IPSec

n

ISDNet -> VPN Premium

n

MCI WorldCom -> UUSecure

n

KPNQwest -> IP VPN

n

FT -> Oléane Control

n

…

n

Les compagnies de t élécommunications, opérateurs, …

n

(ATM, MPLS, Frame relay, …)

n

Les Sociétés de services

n

Matériel “dédié”, …

10

Les solutions de VPN

n Offre matériel ou logiciels (1/2)

n

Applications qui tournent sur un serveur

n

MS RAS NT server,

n

MS Routing & Remote Access W2K Server,

n

poptop / l2TP / freeswan (linux).

n

Matériel dédié

n

Conçu spécifiquement pour le VPN

n

Intel (shiva)

n

Radguard

n

Cisco (altiga)

n

Redcreek

n

Nortel (contivity)

n

V-One (smartguard)

n

Avaya (VPNet)

n

GTA

n

Lucent (Brick)

n

…

Les solutions de VPN

n Offre matériel ou logiciels (2/2)

n

Essentiellement site à site

n

(IOS FW cisco)

n

Firewall

n

Utilisé par de nombreuses organisations pour protéger leur réseau interne

n

M>Tunnel (Mwall Matra)

n

VPN-1 (Checkpoint)

n

Gauntlet VPN

n

…

12

Les technologies

n Technologies mises en œuvre

n

Tunneling / Routage / filtrage

n

Technologies d’authentification

n

Authentification des machines

n

Authentification des utilisateurs

n

Confidentialité

n

Chiffrement, échange de clefs, …

Internet

Rappel, le tunneling

R1

Paquet normal

A B C

Données D

A

Source Dest 1

D E F

Données D

A

Source Dest

Paquet normal 3

R2

R1

2

R2

14

Rappel, le tunneling

R1

Paquet normal

A B C

Données D

G

Source Dest 1

Internet

D E F

Données D

G

Source Dest Paquet normal 3

R2

R2

A

2

G

En général, la machine G a plusieurs interfaces réseau, dont une virtuelle,

correspondant au tunnel (ici dont l'adresse IP est « A »). C’est le routage qui

décide par quelle interface (ie tunnel ou pas) émettre le paquet.

Plan

1.

Généralités

2.

Rappels sur le chiffrement

3.

VPN site à site : IPSec

n

TP 1 : IPSec transport

n

TP 2 : IPSec tunnel

Rappels sur PPP

5.

VPN client : PPTP, L2F, L2TP

n

TP 3 : L2TP

n

TP 4 : L2TP + IPSec

16

Algorithmes symétriques

Algorithme Rijndael 128, 192, 256

AES

Algorithme open source 40–128 bits

CAST-128

Algorithme open source 1–448 bits

Blowfish

Algorithme propriétaire de RSA Variable

RC4

Développée en Suisse 128 bits

IDEA

DES triple passage à trois clefs 168 bits

Triple DES

DES triple passage à deux clefs 112 bits

Triple DES

FIPS PUB 46 56 bits

DES

Commentaire Longueur

de la clef Algorithme

DES = Data Encryption Standard RSA = Rivest, Shamir, and Adelman FIPS = Federal Information Processing Standard AES = Advanced Encryption Standard IDEA = International Data Encryption Algorithm

chiffrement asymétrique

n

Les algorithmes à clef publique sont utilisés pour

n

RSA est un algorithme à clef publique célèbre qui porte le nom de ses trois inventeurs—Ron Rivest, Adi Shamir, et Leonard Adelman

n

Génération uni latérale du secret partagé.

n

RSA peut être utilisé aussi pour la confidentialit é, l'authentification et la non répudiation

n

Diffie-Hellman, le premier algorithme à clef publique inventé, peut être utilisé pour la distribution des clés

n

Génération bi-latérale du secret partag é.

n

L’authentification

n

La non-répudiation

n

La distribution des clés

n

La confidentialité

18

Man in the middle & DH

n

Marc croit échanger avec Sophie

n

Sophie croit échanger avec Marc

n

Tous deux échangent avec le pirate.

n

Diffie Hellman permet l’échange de secret partagé, mais n’assure pas l’authentification.

è Crypto système hybride. Diffie Hellman + RSA

signatures numériques

n

Fournir l’intégrité des données

n

Résumé de message

n

Message Digest 5 (MD5)

n

Secure Hash Algorithm (SHA-1)

n

Signature digitale

n

Combinaison Hashage + cryptographie à clef publique.

n

Digital Signature Algorithm (DSA)

n

RSA

n

Digital Signature Standard (DSS), FIPS 186-2

n

Spécifie des algorithmes de signature numérique approuvés

n

DSA

n

RSA ds algorithm

n

Elliptic Curve Digital Signature Algorithm (ECDSA)

n

Secure Hash Algorithm (SHA-1) pour le résumé du message

20

Code d'authentification des messages

n

Les signatures numériques assurent l'authentification et l'intégrité

n

Ne nécessitent pas l'utilisation d'une clef secrète partagée

n

Un Message Authentication Code (MAC) permet aussi l'authentification et l'intégrité

n

C'est une fonction de hachage à sens unique qui utilise une clef secrète

n

La clef est nécessaire pour vérifier la valeur de hachage

n

Exemples de codes d'authentification de message :

n

Keyed MD5

n

Hashed Message Authentication Code (HMAC)

Types de clefs

n

Clefs de chiffrement de clefs

n

Servent exclusivement à chiffrer d'autres clefs.

n

Durée de vie longue.

n

Souvent cryptographie à clef publique.

n

Clefs maîtresses

n

servent à générer d'autres clefs par dérivation.

n

Clefs de session ou de chiffrement de données

n

Chiffre les données proprement dites.

22 Propriétés des protocoles d'échange de clefs

n

Perfect Forward Secrecy (PFS)

n

Si la découverte du secret à long terme n’entraîne pas la compromission des clefs de session.

n

Back Traffic Protection

n

Si la génération de chaque clef de session se fait de manière indépendante.

n

authentification directe

n

Si les valeurs servant à générer le secret partagé sont authentifiées ou si chaque tiers a prouvé qu'il connaissait la clef de session.

n

protection de l'identité

n

Si un attaquant espionnant les échanges ne peut pas connaître les

identités des tiers communicants.

Certificats

n

Certification des clefs publiques

n

Distribution des clefs

n

Opposition DNSSEC / PGP

n

Souvent utilisés dans les produits VPN du commerce.

n

Manque de portabilité

n

Stockage du certificat sur le poste nomade.

SPKI : Simple Public Key Infrastructure

24

Normes

n

FIPS

n

Federal Information Processing Standards Publications

n

Normes mis en place par le NIST

n

FIPS46 – DES

n

FIPS197 – AES

n

…

n

PKCS

n

« Normes » de chez RSA.

PKCS #1: RSA Cryptography Standard

PKCS #3: Diffie-Hellman Key Agreement Standard PKCS #5: Password-Based Cryptography Standard PKCS #6: Extended-Certificate Syntax Standard PKCS #7: Cryptographic Message Syntax Standard PKCS #8: Private-Key Information Syntax Standard PKCS #9: Selected AttributeTypes

PKCS #10: Certification Request Syntax Standard PKCS #11: Cryptographic Token Interface Standard PKCS #12: Personal Information Exchange Syntax Standard PKCS #13: Elliptic Curve Cryptography Standard

PKCS #15: Cryptographic Token Information Format Standard

Normes

n

RFCs

n

PKIX Working group à l’IETF

n

Développement d’une PKI sur X509v3 et LDAPv2.

Harmonisation des Certification Practices Statement (CPS) et des valeurs des Certificate Policy (CP)

n

SPKI Simple Public Key Certificate (Working group)

n

Généralisation des formats de certificats pour accéder à différents modèles de confiance

RFC du WG PKIX :

•Internet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 2459)

•Internet X.509 Public Key Infrastructure CertificateManagement Protocols (RFC 2510)

•Internet X.509 Certificate Request Message Format (RFC 2511)

•Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527)

•Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates (RFC 2528)

•Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 (RFC 2559)

•Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP (RFC 2585)

•Internet X.509 Public Key Infrastructure LDAPv2 Schema (RFC 2587)

•X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (RFC 2560)

•Certificate Management Messages over CMS (RFC 2797)

•Diffie-Hellman Proof-of-Possession Algorithms(RFC 2875)

•Internet X.509 Public Key Infrastructure Qualified Certificates Profile (RFC 3039)

•Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (RFC 3029)

•Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) (RFC 3161) RFC du WG SPKI :

•SPKI Requirements(RFC 2692)

•SPKI Certificate Theory (RFC 2693)

26

Législation française

Autorisation Autorisation

Autorisation Chiffrement

Clef > 128 bits - Tiers de confiance

Autorisation Autorisation

Libre Chiffrement

Clef > 128 bits + Tiers de confiance

Libre Déclaration

Libre (1) Chiffrement

40 bits < clef <= 128 bits

Libre Déclaration

Libre Chiffrement

clef<=40 bits

Libre Déclaration

simplifiée Libre

Authentification, signature, intégrité

Importation Fourniture

Utilisation

(1) Soumis à déclaration si le fournisseur ou l’importateur ne l’a pas déclaré et si l’usage n’est pas à titre personnel.

(en général, cas des softs GPL)

Plan

1. Généralités

2. Rappels sur le chiffrement

3. VPN site à site : IPSec

4. Rappels sur PPP

5. VPN client : PPTP, L2F, L2TP

28

IPSec

n

IP Security (IPSec) a été développé par l’IETF pour fournir des services cryptographiques de sécurité de la couche Réseau (niveau 3) qui supporte de façon flexible des combinaisons de :

n

Authentification

n

Intégrit é

n

Confidentialité

n

Un système conforme à IPSec peut :

n

Choisir des protocoles de sécurit é

n

Déterminer les algorithmes à utiliser pour les services

n

Utiliser les clés cryptographiques et les certificats

Liste des RFC sur IPSec : (1/2)

•IP Authentication using Keyed MD5 (RFC 1828)

•The ESP DES-CBC Transform (RFC 1829)

•HMAC:Keyed-Hashing for Message Authentication (RFC 2104)

•HMAC-MD5 IP Authentication with Replay Prevention (RFC 2085)

•Security Architecture for the Internet Protocol (RFC 2401)

•The NULL Encryption Algorithm and Its Use With IPsec (RFC 2410)

•IP Security Document Roadmap (RFC 2411)

•IP Authentication Header (RFC 2402)

•The OAKLEY Key Determination Protocol (RFC 2412)

•The ESP CBC-Mode Cipher Algorithms (RFC 2451)

•The Use of HMAC-MD5-96 within ESP and AH (RFC 2403)

•The Use of HMAC-SHA-1-96 within ESP and AH (RFC 2404)

IPSec

n Les associations de sécurité

n Une association de sécurité (Security Association, SA) est une connexion logique unilatérale entre un émetteur et un récepteur

n La communication bilatérale entre deux systèmes IPSec signifie qu’une SA doit être définie dans chaque direction.

Site : Rennes Site :

Sophia

SA # 2 SA # 1

Liste des RFC sur IPSec : (2/2)

•The ESP CBC-Mode Cipher Algorithms (RFC 2451)

•The Use of HMAC-MD5-96 within ESP and AH (RFC 2403)

•The Use of HMAC-SHA-1-96 within ESP and AH (RFC 2404)

•The ESP DES-CBC Cipher Algorithm With Explicit IV (RFC 2405)

•IP Encapsulating Security Payload (ESP) (RFC 2406)

•The Internet IP Security Domain of Interpretation for ISAKMP (RFC 2407)

•Internet Security Association and Key Management Protocol (ISAKMP) (RFC 2408)

•The Internet Key Exchange (IKE) (RFC 2409)

•The Use of HMAC-RIPEMD-160-96 within ESP and AH (RFC

2857)

30

IPSec

n Les associations de sécurité

n

Les SA sont identifiées uniquement par :

n

<Index de paramètre de sécurité, Adresse de destination IP, Protocole de sécurité>

n

Un Index de paramètre de sécurité (Security Parameter Index, SPI) est une valeur de 32 bits qui identifie la SA de chaque paquet

n

Il se trouve dans l’en-tête sécurité du protocole

IPSec

n

Les associations de sécurité

n La Security Association Database (SAD) définit les paramètres associés avec chaque SA

n Les paramètres incluent :(pas normalisés, diffèrent suivant l’implémentation)

n Un compteur de numéro de Séquence (Sequence Number Counter)

n Un indicateur d’overflow (Sequence Counter Overflow)

n Une fenêtre anti-rejeu (Anti-replay window)

n L’information AH (AH information, nécessaire pour implémenter AH)

n L’information ESP (ESP information, nécessaire pour implémenter ESP)

n La durée de vie de SA (SA Lifetime)

n Le mode de protocole IPSec (IPSec Protocol Mode)

n Le MTU sur le chemin (Path MTU)

32

IPSec

n

La politique de sécurité

n Le trafic IP est rattaché à une SA spécifique utilisant la Security Policy Database (SPD)

n Chaque entrée de SPD est définie par un ensemble de valeurs de champs des protocoles IP et des couches supérieures, appelées des sélecteurs

n Les sélecteurs qui déterminent une entrée SPD comprennent

n Adresse IP Source et Destination + netmask (1)

n UserID (2)

n Protocole de la couche Transport

n Ports Source et Destination

n IPv4 Type Of Service (TOS)

n …

(1) Le plus souvent utilisé

(2) Jamais vu d'implémentation… ;-(

En-tête d’authentification IP

n AH est utilisé pour assurer l’intégrité et l’authentification des paquets IP

n L’intégrité des données assure que des modifications non détectées du contenu d’un paquet en transit ne sont pas possibles

n L’authentification permet à une extrémité d’authentifier la machine

n Un service de protection contre le rejeu doit être mis en œuvre par un système compatible IPSec

n Son utilisation est optionnelle

n AH est un en-tête séparé qui suit l’en-tête IP

n Il authentifie le plus de champs IP possibles (les champs ‘non mutables’)

n Ne passe pas le NAT !

AH est identifié par le numéro de protocole 51

34

Format d’en-tête AH

En-tête

En-tête IP AH Données utilisateur

En-tête suivant

Longueur de la

charge Réservé

Security Parameter Index (SPI)

Numéro de séquence

Données d’authentification

(Integrity Check Value) (taille variable) 32 bits

Format d’en-tête AH

n En-tête suivant identifie le type de charge après AH

n Longueur de la charge contient la longueur du champ Données d’authentification

n Données d ’authentification est un champ de longueur variable qui contient la valeur de contrôle d’intégrité (Integrity Check Value, ICV) pour le paquet

n Utilisé par le destinataire pour vérifier l’intégrité du paquet entrant

n Généré à partir du contenu de l’en-tête et des données du paquet

n Calculé avec l’algorithme sélectionné au moment de l’initialisation de la SA

n Les algorithmes par défaut nécessaires pour l’interopérabilité sont

n HMAC with MD5

n HMAC with SHA-1

36

Utilisation d’AH

n

AH peut être utilisé de deux manières différentes

n

Mode transport

n

Mode tunnel

n

Le mode transport est utilisé par les machines et produit moins d’overhead

n

Le mode tunnel est utilisé entre des passerelles

En-tête IP

En-tête

AH Charge

Transport mode

Nouvel En-tête IP

En-tête

AH Ancien Charge

en-tête IP Mode tunnel Authentifié

Authentifié

Encapsulating Security Payload (ESP)

n ESP est utilisé pour permettre

n Chiffrement

n Intégrité des données

n Authentification

n Le champ ''Données Utilisateur'', Payload Data, est composé d’un nombre variable d’octets de données décrits par le champ "En-tête suivant"

n Ce champ est chiffré avec l’algorithme cryptographique sélectionné au cours de l’établissement de la SA

n

Auth ESP à partir de ESP v2

n

Possibilité de chiffrement ESPNULL è uniquement authentification

ESP est identifi é par le numéro de protocole 50

38

Encapsulating Security Payload (ESP)

En-tête

En-tête IP ESP Données utilisateur En-queue ESP

Auth ESP

Données d’authentification (variable)

32 bits

Security Paramet er Index (SPI)

Numéro de séquence

Données utilisateur (variable)

Longueur de remplissage

En-tête suivant Remplissage (0-255 octets)

Chiffré

Authentifié

Utilisation d’ESP

n Comme avec AH, ESP peut être utilisé de deux manières différentes :

n Mode transport

n Mode tunnel

Mode Transport

Mode Tunnel Authentifié

Trailer ESP En-tête

ESP

En-tête ESP

Chiffré

Auth ESP

Charge Charge

Authentifié Chiffré

Trailer ESP

Auth ESP En-tête

IP

Nouvel en-tête IP

Ancien en-tête IP

40

Internet

ESP et le NAT / PAT : problématique

n NAT change les @IP, PAT change les numéros de port TCP et UDP, mais ESP est un protocole…

IP ESP Data Hash

IP ESP Data Hash

10.1.1.1

NAT / PAT

10.1.1.2

VPN gateway

IP ESP Data Hash

123.1.1.1 123.1.1.1 10.1.1.254

IP ESP Data Hash

123.1.1.1

?

NAT-Traversal

n Utilisation d’IPSEC(ESP) encapsulé dans UDP :

n Mode transport

n Mode tunnel

Mode Transport

Mode Tunnel Authentifié

Trailer ESP En-tête

ESP

En-tête ESP

Chiffré

Auth ESP

Charge Charge

Authentifié Chiffré

Trailer ESP

Auth ESP En-tête

IP

Nouvel en-tête IP

Ancien en-tête IP UDP

(500/500)

Non- IKE

Non- IKE UDP

(500/500)

Drafts :

"Negotiation of NAT-Traversal in the IKE", Tero Kivinen, 08-JAN-03.

"UDP Encapsulation of IPsec Packets", Ari Huttunen, 14-JAN-03.

42

Internet Key Exchange (IKE)

n

protocole Internet Key Exchange (IKE) est un protocole de gestion de clef utilisé par IPSec.

n

IKE est composé de :

n ISAKMP (Internet Security Association and Key Management Protocol)

n Oakley / SKEME (Secure Key Exchange Mechanism)

n IPSEC DOI (Domain Of Interpretation) rfc 2407

n IKE assure une gestion sécurisée des clés et l’échange des clés cryptographiques

n Authentification des homologues IPSec

n Négocie les clés IPSec

n Négocie les associations de sécurité (SA) IPSec

Internet Key Exchange (IKE)

n ISAKMP

n ISAKMPest inutilisable seul : c'est un cadre générique qui permet l'utilisation de plusieurs protocoles d'échange de clef et qui peut être utilisé pour d'autres mécanismes de sécurité que ceux de Ipsec.

n ISAKMPa pour but la négociation, l'établissement, la modificationet la suppressiondes associations de sécurité et de leurs attributs.

n

Oakley (RFC 2412) / SKEME

n permettre le partage, de façon sûre entre les tiers, d'un ensemble d'informations relatives au chiffrement :

n Clef secrète, identités des tiers, algorithmes de chiffrement, d'authentification et fonction de hachage.

n

IPSEC DOI

n Spécifie des paramètres des échanges ISAKMP ; indique que ce dernier travaille pour IPSEC.

ISAKMP : UDP port 500

44

IPSec / IKE

n

Relation entre IPSec, SAD, SPD

link IP/Ipsec (AH,ESP) Transport (TCP,UDP)

Socket

Application protocol Application

IKE DOI Oakley

SKEME ISAKMP

SAD

SPD

consulte Administrateur

consulte Pointe sur

Négocie, Modifie, supprime

configure

Demande Création de SA alerte

Négociation ISAKMP

n

Isakmp phase 1

n

Négociation des paramètres de sécurité pour ISAKMP.

n SA Isakmp bi-directionnelle

n SA Isakmp Générique (pour tout échange de clefs), ou SA Isakmp IPSec (uniquement pour les échanges de clefs pour IPSec)

n

Isakmp phase 2

n SA à établir pour le compte d'un mécanisme de sécurité donné (par exemple AH ou ESP).

n échanges de cette phase sont sécurisés (confidentialité, authenticité...) grâce à la SA ISAKMP.

46

Négociation ISAKMP

n

Isakmp indépendant de la génération des clefs.

n

Fonctionne par chaînage de blocs (en-tête Next payload ).

Champs propriétaires.

VID Vendor ID

Message d’effacement d’une SA.

D Delete

Message d'erreur ou d'information.

N Notification

Aléats NONCE Nonce

Résultat d’un algorithme de signature numérique.

SIG Signature

Résultat d’un "hashage" sur le message isakmp.

HASH Hash

Demande de certificats.

CR Certificat Request

Certificat, ou Information sur un certificat (3) CERT

Certificate

identification des tiers (2) ID

Identification

Données nécéssaires à la gestion des clefs (dépend du contexte) KE

Key Exchange

Algorithme + attributs T

Transform

Mécanisme de sécurité (AH, ESP), suivi par un enchaînement de T P

Proposal

Indique le DOI de la négociation (1) SA

Security Association

Commentaire Sigle

Nom

(1) Par exemple :

0 pour le DOI è SA ISAKMP générique.

1 pour le DOI è SA ISAKMP IPsec.

(2) Pour ISAKMP c’est une adresse IP.

(3) Un champ Certificate Encoding (c’est le type) et un champ Certificate Data.

Les types définis actuellement sont :

• PKCS #7 wrapped X.509 certificate

• PGP certificate

• DNS signed key

• X.509 certificate - signature

• X.509 certificate - key exchange

• Kerberos tokens

• Certificate revocation list (CRL)

• Authority revocation list (ARL)

• SPKI certificate

• X.509 certificate - attribute

Négociation ISAKMP

n

Les types d’échange :

Signifie que le message est chiffré

*

Nonce Payload NONCE

Authentication Payload (HASH ou SIG) AUTH

Payload Identity ID

Key ExchangePayload KE

Security Association Payload SA

ISAKMP Header HDR

Commentaire Sigle

SA- DOI - Situation

P1- Mécanisme - SPI

T1.1- Transfo.

- Attr.

T1.2- Transfo.

- Attr.

P2- Mécanisme - SPI

T2.1- Transfo.

- Attr.

T2.2- Transfo.

- Attr.

Les types d’échange définissent des groupes de blocs, afin d’avo ir une

meilleure intéropérabilité, et des fonctions précises (authentification

mutuelle, PFS, …) [RFC2408]

48

Négociation ISAKMP

Négociation ISAKMP

n

Isakmp phase 1 : Main mode (Identity Protection Exchange)

Source Destination

HDR, SA 1 HDR, SA

2

HDR, KE, NONCE 3

HDR, KE, NONCE 4

HDR* , IDs, AUTH 5

HDR* , IDd, AUTH 6

50

Négociation ISAKMP

n

Isakmp phase 1 : Aggressive mode ( Aggressive Exchange)

Source Destination

HDR, SA, KE, NONCE, IDs 1

HDR, SA, KE, NONCE, IDd, AUTH 2

HDR*, AUTH 3

Négociation ISAKMP

n

Isakmp phase 2 : Quick mode

Source Destination

HDR*, HASH, SA, NONCE [, KE] [,IDs, IDd]

1

HDR*, HASH, SA, NONCE [, KE] [,IDs, IDd]

2 HDR*, HASH

3

52

IKE et le NAT-Traversal

n

Détection du support du NAT traversal

n

Utilisation du vendor-string (VID) pour y mettre un hash de RFC XXXX… ;-)

n

Détection de la présence d’un NAT

n

NAT-D Payload : contient un hash de l’@IP et du numéro de port.

n

Utilisation d’un marqueur “Non-ESP” pour démultiplexer ESP d’ISAKMP

Il est conseillé alors d’utiliser un numéro de port <> de 500, car certain

boitiers NAT/PAT ne font justement pas de PAT sur le port IKE, pour ne

pas le perturber…

Plan

1. Généralités

2. Rappels sur le chiffrement

3. VPN site à site : IPSec

4. Rappels sur PPP

5. VPN client : PPTP, L2F, L2TP

54

PPP

n

Le processus de connexion PPP comporte trois phases principales :

n Établissement de la liaison

n Configuration du protocole de la couche réseau

n Fin de la liaison

n

Link Control Protocol (LCP) (1)

n Configure, surveille et termine la liaison

n L'authentification est une phase optionnelle qui suit l'établissement de la liaison (Par exemple, PAP et CHAP [rfc1334])

n

Network Control Protocol (NCP)

n Configure les protocoles de la couche réseau transportés dans la connexion PPP

n Il existe un NCP séparé pour chaque protocole de la couche réseau que supporte PPP (2)

(1) LCP :

• HDLC : RFC 1549

• X25 : RFC 1598

• ISDN : RFC 1618

• SONET/SDH : RFC 1619

• PPPoE : RFC 2516

• …

PPP Multilink Protocol (MP) : rfc1717

(2) NCP :

• IPCP (IP) : RFC 1332

• DNCP (Decnet) : RFC 1376 & RFC 1762

• ATCP (Appletalk ) : RFC 1378

• IPXCP (IPX) : RFC 1552

• BVCP (Bayan) : RFC 1763

• XNSCP (Xerox) : RFC 1764

• IPv6 : RFC2472

• …

PPP

LCP ConfReq LCP ConfAck LCP ConfReq LCP ConfAck

Chap Challenge (name=isp)

Chap Response (name=dupont@loria.fr)

Requête NCP Réponse NCP

Données Utilisateur

NAS ISP

Chap Auth OK

56

PPP & la sécurité

n

CCP (Compression Control protocol)

n Possibilité de compresser l’en-tête IP

n Jacobson, V., "Compressing TCP/IP Headers", RFC 1144,

n RFC 1962, 1977, 1993, 2509

n

ECP (Encryption Control protocol)

n RFC 1968

n Paquets LCP, donc avant tout transfert de DATAs.

n négociation des algorithmes (champ type du paquet LCP)

n è~ un RFC par algorithme.

n èpre-shared secret

DESE (PPP DES Encryption Protocol) : RFC 1969, rfc 2419

3DESE (PPP Triple-DES Encryption Protocol ) : RFC 2420

Authentification PPP

n

PAP (PPP Authentification Protocol RFC1334)

n Le mot de passe circule en clair.

è Peut être stock é chiffré sur le NAS.

n

CHAP (Challenge Handshake Authentication Protocol RFC1994)

n Challenge qui authentifie l’utilisateur auprès du NAS (hash md5).

è Doit être stocké “en clair” sur le NAS.

n

MS-CHAP[v2] (Microsoft PPP CHAP Extensions [version 2])

n RFC 2433 er 2759

n double chiffrement

n Intégration avec les domaines NT et 2k.

n Authentification du serveur (v2)

58

Challenge Chap

Hachage clef

Secrète (*)

Client (homologue)

Serveur (authentificateur)

Hachage

clef secrète Valeur de hachage

Compare Valeur de hachage

Challenge Demande de connexion

Challenge

(valeur de hachage) réponse

(*) La clef secrète est bien souvent dérivée d'un mot de passe par un

hash MD5 (windows2OOO + kerberos)

Ms Chap v1

3 chiffrement DES Hash LANMAN

Du mdp

Client (homologue)

Serveur (authentificateur) Demande de connexion

Challenge

Challenge (8 octets) Hash Windows NT

Du mdp

3 chiffrement DES

Réponse de 2X 24 octets

60

Ms Chap v2

1. Le client demande une épreuve au serveur.

2. Le serveur envoie en réponse une épreuve de 16 octets aléatoires.

3. A- Le client génère un nombre aléatoire de 16 octets, appelé "l'épreuve égale d'authentification.“

B- Le client génére une épreuve de 8 octets en hachant l'épreuve de 16 octets reçue à l'étape (2), les 16 octets de l'épreuve égale

d'authentification générés à l'étape (3a) et le nom de l'utilisateur du client.

C- Le client crée une réponse de 24 octets, en utilisant la fonction de hachage Windows NT et les 8 octets de l'épreuve générés à l'étape (3b).

Ce processus est identique à celui de MS-CHAPv1.

D- Le client transmet au serveur les résultats des étapes (3a) et (3c).

Quelques différences v1- v2 :

MS-CHAP version 1

• Négociation CHAP avec une valeur d'algorithme de 0x80.

• Le serveur envoie une valeur épreuve de 8 octets.

• Le client envoie 24 octets LANMAN et 24 octets NT en réponse aux 8 octets d'épreuve.

• Le serveur envoie une réponse indiquant le SUCCES ou l'ECHEC.

• Le client décide de continuer en fonction de la réponse SUCCES ou ECHEC du serveur.

Ms Chap v2

4.

A- Le serveur utilise les hachages du mot de passe du client, conservé dans une base de données, afin de déchiffrer les réponses. Si les blocs déchiffrés correspondent à l'épreuve, le client est authentifié.

B- Le serveur utilise les 16 octets de l'épreuve égale

d'authentification du client, tout comme le mot de passe haché du client, afin de créer une "réponse d'authentification“ de 20 octets.

5.

Le client calcule aussi une réponse d'authentification. Si celle-ci correspond à celle reçue en réponse, le serveur est authentifié.

Quelques différences v1- v2 :

MS-CHAP version 2

• Négociation CHAP avec une valeur d'algorithme de 0x81.

• Le serveur envoie une valeur de 16 octets qui devra être utilisée par le client dans la création d'une valeur d'épreuve de 8 octets

• Le client envoie 16 octets d'épreuve égale qui ont été utilisés pour créer l'épreuve de 8 octets cachés, et la réponse NT en 24 octets.

• Le serveur envoie une réponse indiquant SUCCES ou ECHEC et transmet une réponse d'authentification de 16 octets.

• Le client décide de continuer en fonction de la réponse SUCCES ou ECHEC. En plus, le client vérifie la validité de la réponse d'authentification et se déconnecte si elle est incorrecte.

62

Authentification PPP

n

EAP (PPP Extensible Authentication Protocol RFC 2284)

n Dissociation de l’authentification de LCP (EAP après LCP)

n Négociation de la méthode d’authentification

n Identity (juste un login)

n MD5-challenge (= CHAP)

n OTP (RFC 1938)

n Generic Token Card

n …

n EAP-TLS (Transport Level Security) (RFC 2716)

n Utilisation de TLS pour de l’authentification mutuel, pour la négociation des clefs pour ECP.

Plan

1. Généralités

2. Rappels sur le chiffrement

3. VPN site à site : IPSec

4. Rappels sur PPP

5. VPN client : PPTP, L2F, L2TP

64

VPN client – généralité

n

Fournir à la machine distante une @IP du réseau interne sur authentification utilisateur.

n

Utilisation de PPP

n

La machine a déjà une adresse IP (routée ou NATée)

Le tunnel sera effectué par la machine elle-même.

n

En accord avec un ISP, fournir au nomade distant une @IP du réseau interne de l’entreprise sur authentification utilisateur.

n

Négociacion PPP avec la passerelle VPN de l’entreprise.

VPN client – PPTP

n

Point-to-Point Tunneling Protocol (PPTP)

n

Développé en partenariat avec Ascend Communications, 3Com Corporation/U.S. Robotics, ECI Telematics, et Microsoft

n

En tant qu’extension de la norme PPP, PPTP est utilisé pour créer des VPN multi-protocoles .

n

Les datagrammes des protocoles réseau sont encapsulés dans une enveloppe IP (utilisation de GRE et GREv2 pour

l’encapsulation)

n

Une session de contrôle du tunnel (1723/TCP)

n

Plusieurs "sessions" dans le même tunnel

PPTP : RFC 2637

GRE (Generic Routing Encapsulation) : RFC 1701 et RFC 1702

GREv2 : Ajout d’aquittements dans GRE.

66

VPN client – GRE

n

Les datagrammes des protocoles réseau sont encapsulés dans une enveloppe IP (utilisation de GRE et GREv2 pour l’encapsulation)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|C|R|K|S|s|Recur| Flags | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum (optional) | Offset (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Sequence Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Routing (optional)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GRE : IP protocole 47.

Protocol Type ~= Protocol type d’ethernet (ftp://ftp.isi.edu/in-

notes/iana /assignments/ethernet- numbers.)

VPN client – PPTP

Utilisateur distant

Dans le cas de L2TP, le NAS s’appelle un LAC ( L2TP Access Concentrator)

La passerelle s’appelle alors un LNS (L2TP Network Server)

68

VPN client – PPTP

En-tête

IP Data

En- tête GRE

En- tête PPP

Données PPP En-tète IP Données

Peut être chiffré Utilisateur distant

NAS (PAC)

RAS (PNS)

En-tête IP 2

IP PPP Tunnel PPTP

Contrôle PPTP

NAS : Network Access Server RAS : Remote Access Server PAC : PPTP Access Concentrator PNS : PPTP Network Server

GRE (Generic Routing Encapsulation) : RFC 1701 et RFC 1702

PPTP liaison de contrôle : 1723/tcp

VPN client – PPTP

(don’t session de CTRL)

70

VPN client – L2F / L2TP

n

La technologie L2F (Layer 2 Forwarding) a été développée par Cisco Systems

n

L2F fournit un tunnel sécurisé entre utilisateurs distants et la passerelle VPN

n

Authentification basée sur PPP / Chiffrement basé sur PPP

n

Layer 2 Tunneling Protocol (L2TP) associe les fonctions des protocoles L2F et PPTP

(Joint venture entre Cisco et Microsoft )

n

Authentification basée sur PPP

n

Supporte l’utilisation de IPSec pour le chiffrement des données

L2F: RFC 2341 L2TP : RFC 2661

Différences L2F / L2TP :

• Contrôle de flux en L2TP

• AVP (attribute-value pair) hiding

• Authentification du tunnel optionnel (obligatoire en L2F)

VPN client – L2F / L2TP

Dans le cas de L2TP, le NAS s’appelle un LAC ( L2TP Access Concentrator)

La passerelle s’appelle alors un LNS (L2TP Network Server)

72

VPN client – L2F / L2TP

1.

L’utilisateur distant initie une connexion PPP vers un ISP (via RTCP, ISDN, xDSL ou un modem câble…)

2.

L’ISP authentifie l’utilisateur. Il détermine aussi si un service VPN est nécessaire.

3.

L’ISP initie ensuite un tunnel L2F / L2TP vers la passerelle de l’entreprise.

4.

La passerelle de l’entreprise authentifie l’utilisateur

5.

S’il est authentifié , la passerelle de l’entreprise effectue des négociations PPP avec l’utilisateur distant

6.

Les données sont encapsulées PPP de bout en bout, de

l’utilisateur vers la passerelle

VPN client – L2F / L2TP

IP PPP Tunnel L2F / L2TP

Utilisateur distant

LAC LNS

Paquet PPP Données

PPP Somme

L2F Charges

(PPP + données) En-tête

L2F / L2TP En-tête

IP

Paquet L2F /L2TP

L2F/L2TP : UDP port 1701

74

VPN client – L2F / L2TP

Dans le cas de L2TP, le NAS s’appelle un LAC ( L2TP Access Concentrator)

La passerelle s’appelle alors un LNS (L2TP Network Server)

VPN client – L2F / L2TP

LCP ConfReq LCP ConfAck LCP ConfReq LCP ConfAck

Chap Auth OK

Chap Response (name=dupont@loria.fr)

Requête NCP Réponse NCP Utilisateur

NAS

ISP LNS

L2tp Conf L2tp Conf L2tp Open L2tp Open

L2tp Open Mid (Chap info & LCP info) L2tp Open Mid

Chap Challenge (name=isp)

Session Tunnel

76

VPN client – L2TP et radius

n

Authentification par user name (rfc 2809)

n Client et LAC : Call Connected

n Client et LAC : PPP LCP negotiation

n Client et LAC : Authentication (juste basé sur le userid via radius)

n LAC vers LNS : L2TP Incoming-Call-Request

n LNS vers LAC : L2TP Incoming-Call-Reply

n LAC vers LNS : L2TP Incoming-Call-Connected

n Client et LNS : PPP LCP re-negotiation

n Client et LNS : PPP authentication

n LNS et Client : RADIUS Access-Accept/Access-Reject

n Client et LNS : NCP negotiation

VPN client – L2TP et IPSEC

n

Shéma de sécurisation

LAC

@IP = Loc

@IP = Nom

routeur FW

LNS (proxy arp )

@IP = Dest internet

@IP = Nom

ESP IP (@Nom,@Dest) Data

IP(@Loc,@LNS)

IP (@Nom,@Dest) Data L2TP PPP

78

VPN client – L2TP et IPSEC

n

Shéma proposé de sécurisation (RFC2888)

LAC

@IP = Nom routeur FW

LNS (routeur)

@IP = Dest internet

@IP = Nom

PPP IP(@Nom,@LNS) ESP IP (@Nom,@Dest) Data PPP

IP(@LAC,@LNS) L2TP IP (@Nom,@Dest) Data

VPN client – routage & filtrage

n

Split tunneling

n

= Seule une partie des informations passe dans le VPN.

n Routage par défaut dans le VPN ?

n èAccès au site "hôte" vu comme une machine extérieure !

n èfirewall en entrée de site sans doute mal configuré (pour le retour).

n

Tunnel = accès privilégié

n

Le nomade doit être "inaccessible" du reste du réseau local ?

n èfirewall local au nomade seulement durant le VPN ? (*) n

Le meilleur des 2 mondes (réseau invité ET réseau mère).

(*) Client "Checkpoint Secure remote"

80

VPN client – filtrage

n

En entrée de site (source = any, destination = passerelle VPN)

n UDP 500 (ISAKMP)

n UDP 1701 (L2TP) (RFC2888 ou en clair)

n TCP 1723 (PPTP CTRL) (si on utilise pptp)

n Proto 50 (ESP) (si pas d'AH, à cause du NAT)

n Proto 51 (AH)

n

En entrée du site hôte (source = any, destination = subnet nomades)

n UDP 500 (ISAKMP) si pas de suivi de session sur UDP

n UDP 1701 (L2TP) si pas de suivi de session sur UDP

n Proto 50 (ESP) suivi de session ?

n Proto 51 (AH) suivi de session ?

(*) Client "Checkpoint Secure remote"

Résumé

ESP PPP AH AUTH-ESP

X -

IPSec

ESP PPP(2)

PPP(2) ESP

Confiden- tialité

PPP PPP

PPP -

Auth User

AH AUTH-ESP -

X(1) AH

AUTH-ESP

Machine

X X

X -

Client

- -

- X

ROBO

L2TP+

IPSec PPTP

L2TP IPSec

(1) Optionnel en L2TP, obligatoire en L2F, basé sur un secret partagé.

Identifie juste le LAC et le LNS, pas la machine client.

(2) Secret pré-partagé seulement.

82

Bibliographie

n Les rfcs : http://www.ietf.orget http://www.rfc-editor.org

n Ipsec : http://www.hsc.fr/ressources/articles/ipsec-tech/index.html.fr

n Divers (chap, pptp, etc) : http://www.counterpane.com/publish.html

n L2F : http://www.cisco.com/warp/public/471/vpdn_20980.html

n Freeswan : http://www.freeswan.org

n "Cryptographie appliquée" (Bruce Schneier), International Thomson Publishing.

n Couterpane : http://www.counterpane.com

n "Digital certificates" (Jalal Feghhi, Jalil Feghhi, Peter Williams), Addison-Welsley

n …Et bien d'autres…