Je suis entrain de monter une configuration NetBSD 3.0 pour faire office
de concentrateur l2tp/ipsec pour des clients windows XP.
Lors de la phase 1, racoon loggue les évènements suivants :
2006-02-23 20:05:07: INFO: respond new phase 1 negotiation: 192.168.1.246[500]<=>192.168.1.105[500]
2006-02-23 20:05:07: INFO: begin Identity Protection mode.
2006-02-23 20:05:07: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2006-02-23 20:05:07: INFO: received Vendor ID: FRAGMENTATION
2006-02-23 20:05:07: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Ça semble être un problème de PSK, le problème est que je ne sais pas
quel identifiant est utilisé par XP, j'ai essayé le hostname, le
fqdn, l'adresse ip de la machine xp, mais ça ne veut rien savoir...
--
SP> L'enfer est pavé de foie gras...
BE> Comment on y va ?
Ben en marchant dessus, c'te question.
-+- BQL in <http://www.le-gnu.net> + Femme de peu de foie gras -+-
Je suis entrain de monter une configuration NetBSD 3.0 pour faire office de concentrateur l2tp/ipsec pour des clients windows XP.
Bon, ca merite un rappel sur la securité des solutions IPsec (je ne suis pas un expert, mais c'est en gros ce que j'ai reussi à comprendre)
Je te rassure, globalement, c'est ca :-)
Je vais juste me permettre d'apporter quelques precisions, voire un peu de chipottage....
La sécurité d'IPsec a pour prérequis la sécurité de l'échange des clés. Celui ci se fait via le protocole IKE.
Disons que l'utilisation de cles negociees augmente le niveau de securite d'IPSec, comme tu le dis plus bas.
IKE marche en deux phases:
1) phase 1, où les parties s'authentifie, et où on obtient une assotiation de sécurité (SA) de phase 1 (on dit aussi SA ISAKMP). Cette SA consiste en un accord entre les daemons IKE sur des clés et des algos de signature et chiffrement. Elle est stoquée dans le daemon IKE.
2) Cette SA de phase 1 est regulièrement utilisée pour négocier une SA de phase 2 (on dit aussi SA IPsec). C'est cette SA qui sert à echanger le traffic entre les parties. La sa de phase 2 est stoquée dans le kerne (dans la Security Assiation Database: SAD), et on l'examine avec la commande setkey -D.
LES SAs de phase2. La IsakmpSA est bidirectionelle, une IPSecSA est unidirectionelle, donc elles vont souvent par paire.
Le phase 1 coute cher et est faite rarement, la phase 2 est plus légère et se fait donc régulièrement. En changeant de clé à intervalle de temps regulier, on complique la tâche des assaillants.
Yep. Sauf que, en pratique, on recommande d'utiliser le PFS en phase2, ce qui fait utiliser a nouveau la lourde mecanique de Diffie-Helmann a chaque nouvelle phase2, ce qui reduit quand meme le cote "plus leger". Mais meme comme ca, une negociation de phase2 reste plus legere qu'une negociaiton de phase1.
[phase1]
a) par clés statiques (PSK), que bon nombre de logiciels appellent mot de passe de groupe. La SA de phase 1 est obtenue par un Diffie-Hellman signé par la PSK. Il faut bien être consicent du fait que toute personne en possession de la PSK peut s'intercaller entre les parties, et jouer un man in the middle. Il n'y a pas de traffic à craquer, il suffit de faire passer des ARP bidons pour se placer entre les deux machines, et se faire passer pour l'une à l'autre et vice-versa
Precision sur l'appellation "mot de passe de groupe": cette appellation apparait surtout sur les implementations "clients Xauth" (Xauth est une couche "supplementaire" d'authentification, apres la phase1, protegee par la IsakmpSA).
Et le "Diffie-Helmann signe par la PSK" est une presentation un peu rapide des chose, mais on va pas trop rentrer dans ces details (RFC2409 pour ceux que ca interesse...).
b) par certificat (RSA et autres). La SA de phase 1 est btenue par un Diffie-Hellman signé par la clé privée du certificat. Dans cette situation, il faut avoir connaissance des clés privées des deux parties pour pouvoir s'intercaller sans que personne ne s'en appercoive.
A verifier, mais j'aurais tendance a supposer qu'il "suffit" d'une seule des cles privees et de l'ensemble des infos publiques pour s'intercaler.
Il est bien important de comprendre quand dans une config L2TP/IPsec, le login/mot de passe L2TP sont protégés par IPsec. Une authentification de phase 1 vulnerable à un man in the middle permettra la capture des credits d'authentifcation L2TP (ainsi que du reste de la session).
Pour rendre L2TP/IPsec sûr, il faut choisir entre - distribuer une PSK par utilisateur, ce qui est difficilement gérable
Des qu'on depasse "quelques utilisateurs", oui.
- utiliser des certificats. A noter que si on donne le même certificat à tous les usagers, le man in the middle n'est pas possible en utilisant le certificat commun des usagers (car le concentrateur d'accès à un certificat différent).
Je maintiens mon doute la dessus, faudra qu'on verifie ce point.
A noter qu'il existe une extension à IKE, qui s'appelle Hybrid authentication, qui casse la symetrie de la phase 1 d'IKE. Le concentrateur d'accès utilisé un certificat, alors que le client ne s'authentifie pas. On obtient une SA de phase 1 sûre, où le client n'est pas authentifié, mais il peut le faire ensuite (par L2TP ou par Xauth).
Par L2TP directement ?
Ca voudrait dire que, d'un point de vue purement IPSec, on aurait negocie une phase2 avec un correspondant non authentifie (puisque tout le traffic L2TP est protege par une paire de IPSec SAs ) !
C'est possible, remarque, mais ca m'etonnerait quand meme un peu....
A +
VANHU.
manu@netbsd.org (Emmanuel Dreyfus) writes:
Eric Masson <emss@free.fr> wrote:
Je suis entrain de monter une configuration NetBSD 3.0 pour faire office
de concentrateur l2tp/ipsec pour des clients windows XP.
Bon, ca merite un rappel sur la securité des solutions IPsec (je ne suis
pas un expert, mais c'est en gros ce que j'ai reussi à comprendre)
Je te rassure, globalement, c'est ca :-)
Je vais juste me permettre d'apporter quelques precisions, voire un
peu de chipottage....
La sécurité d'IPsec a pour prérequis la sécurité de l'échange des clés.
Celui ci se fait via le protocole IKE.
Disons que l'utilisation de cles negociees augmente le niveau de
securite d'IPSec, comme tu le dis plus bas.
IKE marche en deux phases:
1) phase 1, où les parties s'authentifie, et où on obtient une
assotiation de sécurité (SA) de phase 1 (on dit aussi SA ISAKMP). Cette
SA consiste en un accord entre les daemons IKE sur des clés et des algos
de signature et chiffrement. Elle est stoquée dans le daemon IKE.
2) Cette SA de phase 1 est regulièrement utilisée pour négocier une SA
de phase 2 (on dit aussi SA IPsec). C'est cette SA qui sert à echanger
le traffic entre les parties. La sa de phase 2 est stoquée dans le kerne
(dans la Security Assiation Database: SAD), et on l'examine avec la
commande setkey -D.
LES SAs de phase2. La IsakmpSA est bidirectionelle, une IPSecSA est
unidirectionelle, donc elles vont souvent par paire.
Le phase 1 coute cher et est faite rarement, la phase 2 est plus légère
et se fait donc régulièrement. En changeant de clé à intervalle de temps
regulier, on complique la tâche des assaillants.
Yep. Sauf que, en pratique, on recommande d'utiliser le PFS en phase2,
ce qui fait utiliser a nouveau la lourde mecanique de Diffie-Helmann
a chaque nouvelle phase2, ce qui reduit quand meme le cote "plus
leger". Mais meme comme ca, une negociation de phase2 reste plus
legere qu'une negociaiton de phase1.
[phase1]
a) par clés statiques (PSK), que bon nombre de logiciels appellent mot
de passe de groupe. La SA de phase 1 est obtenue par un Diffie-Hellman
signé par la PSK. Il faut bien être consicent du fait que toute personne
en possession de la PSK peut s'intercaller entre les parties, et jouer
un man in the middle. Il n'y a pas de traffic à craquer, il suffit de
faire passer des ARP bidons pour se placer entre les deux machines, et
se faire passer pour l'une à l'autre et vice-versa
Precision sur l'appellation "mot de passe de groupe": cette
appellation apparait surtout sur les implementations "clients Xauth"
(Xauth est une couche "supplementaire" d'authentification, apres la
phase1, protegee par la IsakmpSA).
Et le "Diffie-Helmann signe par la PSK" est une presentation un peu
rapide des chose, mais on va pas trop rentrer dans ces details
(RFC2409 pour ceux que ca interesse...).
b) par certificat (RSA et autres). La SA de phase 1 est btenue par un
Diffie-Hellman signé par la clé privée du certificat. Dans cette
situation, il faut avoir connaissance des clés privées des deux parties
pour pouvoir s'intercaller sans que personne ne s'en appercoive.
A verifier, mais j'aurais tendance a supposer qu'il "suffit" d'une
seule des cles privees et de l'ensemble des infos publiques pour
s'intercaler.
Il est bien important de comprendre quand dans une config L2TP/IPsec, le
login/mot de passe L2TP sont protégés par IPsec. Une authentification de
phase 1 vulnerable à un man in the middle permettra la capture des
credits d'authentifcation L2TP (ainsi que du reste de la session).
Pour rendre L2TP/IPsec sûr, il faut choisir entre
- distribuer une PSK par utilisateur, ce qui est difficilement gérable
Des qu'on depasse "quelques utilisateurs", oui.
- utiliser des certificats. A noter que si on donne le même certificat à
tous les usagers, le man in the middle n'est pas possible en utilisant
le certificat commun des usagers (car le concentrateur d'accès à un
certificat différent).
Je maintiens mon doute la dessus, faudra qu'on verifie ce point.
A noter qu'il existe une extension à IKE, qui s'appelle Hybrid
authentication, qui casse la symetrie de la phase 1 d'IKE. Le
concentrateur d'accès utilisé un certificat, alors que le client ne
s'authentifie pas. On obtient une SA de phase 1 sûre, où le client n'est
pas authentifié, mais il peut le faire ensuite (par L2TP ou par Xauth).
Par L2TP directement ?
Ca voudrait dire que, d'un point de vue purement IPSec, on aurait
negocie une phase2 avec un correspondant non authentifie (puisque tout
le traffic L2TP est protege par une paire de IPSec SAs ) !
C'est possible, remarque, mais ca m'etonnerait quand meme un peu....
Je suis entrain de monter une configuration NetBSD 3.0 pour faire office de concentrateur l2tp/ipsec pour des clients windows XP.
Bon, ca merite un rappel sur la securité des solutions IPsec (je ne suis pas un expert, mais c'est en gros ce que j'ai reussi à comprendre)
Je te rassure, globalement, c'est ca :-)
Je vais juste me permettre d'apporter quelques precisions, voire un peu de chipottage....
La sécurité d'IPsec a pour prérequis la sécurité de l'échange des clés. Celui ci se fait via le protocole IKE.
Disons que l'utilisation de cles negociees augmente le niveau de securite d'IPSec, comme tu le dis plus bas.
IKE marche en deux phases:
1) phase 1, où les parties s'authentifie, et où on obtient une assotiation de sécurité (SA) de phase 1 (on dit aussi SA ISAKMP). Cette SA consiste en un accord entre les daemons IKE sur des clés et des algos de signature et chiffrement. Elle est stoquée dans le daemon IKE.
2) Cette SA de phase 1 est regulièrement utilisée pour négocier une SA de phase 2 (on dit aussi SA IPsec). C'est cette SA qui sert à echanger le traffic entre les parties. La sa de phase 2 est stoquée dans le kerne (dans la Security Assiation Database: SAD), et on l'examine avec la commande setkey -D.
LES SAs de phase2. La IsakmpSA est bidirectionelle, une IPSecSA est unidirectionelle, donc elles vont souvent par paire.
Le phase 1 coute cher et est faite rarement, la phase 2 est plus légère et se fait donc régulièrement. En changeant de clé à intervalle de temps regulier, on complique la tâche des assaillants.
Yep. Sauf que, en pratique, on recommande d'utiliser le PFS en phase2, ce qui fait utiliser a nouveau la lourde mecanique de Diffie-Helmann a chaque nouvelle phase2, ce qui reduit quand meme le cote "plus leger". Mais meme comme ca, une negociation de phase2 reste plus legere qu'une negociaiton de phase1.
[phase1]
a) par clés statiques (PSK), que bon nombre de logiciels appellent mot de passe de groupe. La SA de phase 1 est obtenue par un Diffie-Hellman signé par la PSK. Il faut bien être consicent du fait que toute personne en possession de la PSK peut s'intercaller entre les parties, et jouer un man in the middle. Il n'y a pas de traffic à craquer, il suffit de faire passer des ARP bidons pour se placer entre les deux machines, et se faire passer pour l'une à l'autre et vice-versa
Precision sur l'appellation "mot de passe de groupe": cette appellation apparait surtout sur les implementations "clients Xauth" (Xauth est une couche "supplementaire" d'authentification, apres la phase1, protegee par la IsakmpSA).
Et le "Diffie-Helmann signe par la PSK" est une presentation un peu rapide des chose, mais on va pas trop rentrer dans ces details (RFC2409 pour ceux que ca interesse...).
b) par certificat (RSA et autres). La SA de phase 1 est btenue par un Diffie-Hellman signé par la clé privée du certificat. Dans cette situation, il faut avoir connaissance des clés privées des deux parties pour pouvoir s'intercaller sans que personne ne s'en appercoive.
A verifier, mais j'aurais tendance a supposer qu'il "suffit" d'une seule des cles privees et de l'ensemble des infos publiques pour s'intercaler.
Il est bien important de comprendre quand dans une config L2TP/IPsec, le login/mot de passe L2TP sont protégés par IPsec. Une authentification de phase 1 vulnerable à un man in the middle permettra la capture des credits d'authentifcation L2TP (ainsi que du reste de la session).
Pour rendre L2TP/IPsec sûr, il faut choisir entre - distribuer une PSK par utilisateur, ce qui est difficilement gérable
Des qu'on depasse "quelques utilisateurs", oui.
- utiliser des certificats. A noter que si on donne le même certificat à tous les usagers, le man in the middle n'est pas possible en utilisant le certificat commun des usagers (car le concentrateur d'accès à un certificat différent).
Je maintiens mon doute la dessus, faudra qu'on verifie ce point.
A noter qu'il existe une extension à IKE, qui s'appelle Hybrid authentication, qui casse la symetrie de la phase 1 d'IKE. Le concentrateur d'accès utilisé un certificat, alors que le client ne s'authentifie pas. On obtient une SA de phase 1 sûre, où le client n'est pas authentifié, mais il peut le faire ensuite (par L2TP ou par Xauth).
Par L2TP directement ?
Ca voudrait dire que, d'un point de vue purement IPSec, on aurait negocie une phase2 avec un correspondant non authentifie (puisque tout le traffic L2TP est protege par une paire de IPSec SAs ) !
C'est possible, remarque, mais ca m'etonnerait quand meme un peu....
A +
VANHU.
manu
VANHULLEBUS Yvan wrote:
Bon, ca merite un rappel sur la securité des solutions IPsec (je ne suis pas un expert, mais c'est en gros ce que j'ai reussi à comprendre)
Je te rassure, globalement, c'est ca :-)
Je vais juste me permettre d'apporter quelques precisions, voire un peu de chipottage....
Pas de problème, l'essentiel est que tout le monde sache que je ne sais probablement pas de quoi je parle :-)
Yep. Sauf que, en pratique, on recommande d'utiliser le PFS en phase2, ce qui fait utiliser a nouveau la lourde mecanique de Diffie-Helmann a chaque nouvelle phase2, ce qui reduit quand meme le cote "plus leger". Mais meme comme ca, une negociation de phase2 reste plus legere qu'une negociaiton de phase1.
A l'occasion je veux bien que tu m'explique à quoi sert PFS. En fait je ne me suis jamais trop interessé à ce qui se passait après la phase 1, puisque tout mon travail dans ipsec-tools s'est passé là. (euh, lance ca dans un message distinct de ta réponse au laïus ci-dessous, sinon ca va mousser severement)
Precision sur l'appellation "mot de passe de groupe": cette appellation apparait surtout sur les implementations "clients Xauth"
Il me semble que le client L2TP/IPsec de MacOS X emploie aussi ce terme (à verifier).
[Authentication en phase 1 de IKE]
b) par certificat (RSA et autres). La SA de phase 1 est btenue par un Diffie-Hellman signé par la clé privée du certificat. Dans cette situation, il faut avoir connaissance des clés privées des deux parties pour pouvoir s'intercaller sans que personne ne s'en appercoive.
A verifier, mais j'aurais tendance a supposer qu'il "suffit" d'une seule des cles privees et de l'ensemble des infos publiques pour s'intercaler.
Si j'envisage le cas de deux roadwarriors Bob et Trudy, et d'une passerelle VPN Alice. Bob et Trudy ont le même certificat et la même clé privée. Alice a son propre certificat et une clé privée vraiment confidentielle. Tous les certificats sont signé par une autorité de certification, qui est installée sur Bob, Alice et Trudy.
Trudy va tenter un man in the middle (sacrée Trudy, elle a vraiment de la suite dans les idées!). On a donc un Diffie-Hellman authentifié entre Trudy et Bob d'une part et entre Trudy et Alice d'autre part.
Alice est incapable de s'appercevoir que Trudy à pris la place de Bob. Mais c'est normal: en donnant le même certificat à tout les usagers, on a bien accepté qu'ils ne soient pas authentifiés au cours de la phase 1. Xauth ou L2TP se chargera de les authentifier plus tard.
Par contre Bob est capable de constater que le certificat de Trudy ne corresponds pas au nom de Alice. Il est capable de detecter qu'un man in the middle est en cours, et evitera d'envoyer ses crédits d'authentification à Trudy lors d'une authentification Xauth ou L2TP.
Ceci suppose que Bob a un client correctement programmé qui accomplit correctement les deux actions suivantes: 1) Faire la validation de la signature du certificat qui lui est présenté, en utilisant l'authorité de certification. Sans cela Trudy pourrait se faire sa propre authorité de certification, et se signer un certificat avec le nom de Alice dedans.
2) Verifier que le nom porté sur le certificat qui lui est présenté corresponds bien au nom DNS auquel il souhaite se connecter. Si il ne le fait pas, alors Trudy peut utiliser le certificat générique d'utilisateur qu'elle partage avec Bob, qui est bien signé par la bonne authorité de certification, et se faire passer pour Alice, puisque Bob ne verifie pas à qui il parle (Quel con, ce Bob!).
Sinon le deuxième problème est de construire un canal confidentiel dans lequel on poura faire un Xauth ou un L2TP sans que Trudy ne puisse espionner. Ca, on y arrive si Bob et Alice se mettent d'accord sur un secret partagé sans que Trudy ne le découvre. On sait qu'avec un Diffie Hellman, on peut se mettre d'accord sur un secret partagé alors qu'on est espionné, à condition de pouvoir authentifier la partie adverse. Ce problème est résolu comme nous l'avons vu, donc Bob et Alice peuvent construire un canal de communication où Trudy ne pourra pas espionner les communications.
C'est pour cela que nous n'avons besoin d'un certificat que du coté de la passerelle VPN. Il est à noter que quand tu envoies ton numéro de CB à un serveur HTTP/SSL, tu es dans la même situation: tu authentifie le serveur par un certificat, mais le serveur ne t'authentifie pas.
Un certificat utilisateur est utilisé dans des cas comme la télédéclaration pour se conformer à la legislation sur la signature electronique, mais il n'est pas nescessaire pour assurer la confidentialité de l'envoi d'information par le client.
A noter qu'il existe une extension à IKE, qui s'appelle Hybrid authentication, qui casse la symetrie de la phase 1 d'IKE. Le concentrateur d'accès utilisé un certificat, alors que le client ne s'authentifie pas. On obtient une SA de phase 1 sûre, où le client n'est pas authentifié, mais il peut le faire ensuite (par L2TP ou par Xauth).
Par L2TP directement ?
Ca voudrait dire que, d'un point de vue purement IPSec, on aurait negocie une phase2 avec un correspondant non authentifie (puisque tout le traffic L2TP est protege par une paire de IPSec SAs ) !
Oui, tu as une phase 2 non authentifiée, mais ca ne suffit pas à passer du traffic au travers de la passerelle VPN. Pour le faire, il faut que le client construise un tunnel L2TP, et donc qu'il passe une authentification.
IPsec+Xauth est un peu différent car la passerelle VPN prendra la décision d'accepter de relayer le traffic dès que Xauth sera validé, donc avant même la phase 2.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
VANHULLEBUS Yvan <vanhu@nospam_free.fr> wrote:
Bon, ca merite un rappel sur la securité des solutions IPsec (je ne suis
pas un expert, mais c'est en gros ce que j'ai reussi à comprendre)
Je te rassure, globalement, c'est ca :-)
Je vais juste me permettre d'apporter quelques precisions, voire un
peu de chipottage....
Pas de problème, l'essentiel est que tout le monde sache que je ne sais
probablement pas de quoi je parle :-)
Yep. Sauf que, en pratique, on recommande d'utiliser le PFS en phase2,
ce qui fait utiliser a nouveau la lourde mecanique de Diffie-Helmann
a chaque nouvelle phase2, ce qui reduit quand meme le cote "plus
leger". Mais meme comme ca, une negociation de phase2 reste plus
legere qu'une negociaiton de phase1.
A l'occasion je veux bien que tu m'explique à quoi sert PFS. En fait je
ne me suis jamais trop interessé à ce qui se passait après la phase 1,
puisque tout mon travail dans ipsec-tools s'est passé là. (euh, lance ca
dans un message distinct de ta réponse au laïus ci-dessous, sinon ca va
mousser severement)
Precision sur l'appellation "mot de passe de groupe": cette
appellation apparait surtout sur les implementations "clients Xauth"
Il me semble que le client L2TP/IPsec de MacOS X emploie aussi ce terme
(à verifier).
[Authentication en phase 1 de IKE]
b) par certificat (RSA et autres). La SA de phase 1 est btenue par un
Diffie-Hellman signé par la clé privée du certificat. Dans cette
situation, il faut avoir connaissance des clés privées des deux parties
pour pouvoir s'intercaller sans que personne ne s'en appercoive.
A verifier, mais j'aurais tendance a supposer qu'il "suffit" d'une
seule des cles privees et de l'ensemble des infos publiques pour
s'intercaler.
Si j'envisage le cas de deux roadwarriors Bob et Trudy, et d'une
passerelle VPN Alice. Bob et Trudy ont le même certificat et la même clé
privée. Alice a son propre certificat et une clé privée vraiment
confidentielle. Tous les certificats sont signé par une autorité de
certification, qui est installée sur Bob, Alice et Trudy.
Trudy va tenter un man in the middle (sacrée Trudy, elle a vraiment de
la suite dans les idées!). On a donc un Diffie-Hellman authentifié entre
Trudy et Bob d'une part et entre Trudy et Alice d'autre part.
Alice est incapable de s'appercevoir que Trudy à pris la place de Bob.
Mais c'est normal: en donnant le même certificat à tout les usagers, on
a bien accepté qu'ils ne soient pas authentifiés au cours de la phase 1.
Xauth ou L2TP se chargera de les authentifier plus tard.
Par contre Bob est capable de constater que le certificat de Trudy ne
corresponds pas au nom de Alice. Il est capable de detecter qu'un man in
the middle est en cours, et evitera d'envoyer ses crédits
d'authentification à Trudy lors d'une authentification Xauth ou L2TP.
Ceci suppose que Bob a un client correctement programmé qui accomplit
correctement les deux actions suivantes:
1) Faire la validation de la signature du certificat qui lui est
présenté, en utilisant l'authorité de certification. Sans cela Trudy
pourrait se faire sa propre authorité de certification, et se signer un
certificat avec le nom de Alice dedans.
2) Verifier que le nom porté sur le certificat qui lui est présenté
corresponds bien au nom DNS auquel il souhaite se connecter. Si il ne le
fait pas, alors Trudy peut utiliser le certificat générique
d'utilisateur qu'elle partage avec Bob, qui est bien signé par la bonne
authorité de certification, et se faire passer pour Alice, puisque Bob
ne verifie pas à qui il parle (Quel con, ce Bob!).
Sinon le deuxième problème est de construire un canal confidentiel dans
lequel on poura faire un Xauth ou un L2TP sans que Trudy ne puisse
espionner. Ca, on y arrive si Bob et Alice se mettent d'accord sur un
secret partagé sans que Trudy ne le découvre. On sait qu'avec un Diffie
Hellman, on peut se mettre d'accord sur un secret partagé alors qu'on
est espionné, à condition de pouvoir authentifier la partie adverse. Ce
problème est résolu comme nous l'avons vu, donc Bob et Alice peuvent
construire un canal de communication où Trudy ne pourra pas espionner
les communications.
C'est pour cela que nous n'avons besoin d'un certificat que du coté de
la passerelle VPN. Il est à noter que quand tu envoies ton numéro de CB
à un serveur HTTP/SSL, tu es dans la même situation: tu authentifie le
serveur par un certificat, mais le serveur ne t'authentifie pas.
Un certificat utilisateur est utilisé dans des cas comme la
télédéclaration pour se conformer à la legislation sur la signature
electronique, mais il n'est pas nescessaire pour assurer la
confidentialité de l'envoi d'information par le client.
A noter qu'il existe une extension à IKE, qui s'appelle Hybrid
authentication, qui casse la symetrie de la phase 1 d'IKE. Le
concentrateur d'accès utilisé un certificat, alors que le client ne
s'authentifie pas. On obtient une SA de phase 1 sûre, où le client n'est
pas authentifié, mais il peut le faire ensuite (par L2TP ou par Xauth).
Par L2TP directement ?
Ca voudrait dire que, d'un point de vue purement IPSec, on aurait
negocie une phase2 avec un correspondant non authentifie (puisque tout
le traffic L2TP est protege par une paire de IPSec SAs ) !
Oui, tu as une phase 2 non authentifiée, mais ca ne suffit pas à passer
du traffic au travers de la passerelle VPN. Pour le faire, il faut que
le client construise un tunnel L2TP, et donc qu'il passe une
authentification.
IPsec+Xauth est un peu différent car la passerelle VPN prendra la
décision d'accepter de relayer le traffic dès que Xauth sera validé,
donc avant même la phase 2.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Bon, ca merite un rappel sur la securité des solutions IPsec (je ne suis pas un expert, mais c'est en gros ce que j'ai reussi à comprendre)
Je te rassure, globalement, c'est ca :-)
Je vais juste me permettre d'apporter quelques precisions, voire un peu de chipottage....
Pas de problème, l'essentiel est que tout le monde sache que je ne sais probablement pas de quoi je parle :-)
Yep. Sauf que, en pratique, on recommande d'utiliser le PFS en phase2, ce qui fait utiliser a nouveau la lourde mecanique de Diffie-Helmann a chaque nouvelle phase2, ce qui reduit quand meme le cote "plus leger". Mais meme comme ca, une negociation de phase2 reste plus legere qu'une negociaiton de phase1.
A l'occasion je veux bien que tu m'explique à quoi sert PFS. En fait je ne me suis jamais trop interessé à ce qui se passait après la phase 1, puisque tout mon travail dans ipsec-tools s'est passé là. (euh, lance ca dans un message distinct de ta réponse au laïus ci-dessous, sinon ca va mousser severement)
Precision sur l'appellation "mot de passe de groupe": cette appellation apparait surtout sur les implementations "clients Xauth"
Il me semble que le client L2TP/IPsec de MacOS X emploie aussi ce terme (à verifier).
[Authentication en phase 1 de IKE]
b) par certificat (RSA et autres). La SA de phase 1 est btenue par un Diffie-Hellman signé par la clé privée du certificat. Dans cette situation, il faut avoir connaissance des clés privées des deux parties pour pouvoir s'intercaller sans que personne ne s'en appercoive.
A verifier, mais j'aurais tendance a supposer qu'il "suffit" d'une seule des cles privees et de l'ensemble des infos publiques pour s'intercaler.
Si j'envisage le cas de deux roadwarriors Bob et Trudy, et d'une passerelle VPN Alice. Bob et Trudy ont le même certificat et la même clé privée. Alice a son propre certificat et une clé privée vraiment confidentielle. Tous les certificats sont signé par une autorité de certification, qui est installée sur Bob, Alice et Trudy.
Trudy va tenter un man in the middle (sacrée Trudy, elle a vraiment de la suite dans les idées!). On a donc un Diffie-Hellman authentifié entre Trudy et Bob d'une part et entre Trudy et Alice d'autre part.
Alice est incapable de s'appercevoir que Trudy à pris la place de Bob. Mais c'est normal: en donnant le même certificat à tout les usagers, on a bien accepté qu'ils ne soient pas authentifiés au cours de la phase 1. Xauth ou L2TP se chargera de les authentifier plus tard.
Par contre Bob est capable de constater que le certificat de Trudy ne corresponds pas au nom de Alice. Il est capable de detecter qu'un man in the middle est en cours, et evitera d'envoyer ses crédits d'authentification à Trudy lors d'une authentification Xauth ou L2TP.
Ceci suppose que Bob a un client correctement programmé qui accomplit correctement les deux actions suivantes: 1) Faire la validation de la signature du certificat qui lui est présenté, en utilisant l'authorité de certification. Sans cela Trudy pourrait se faire sa propre authorité de certification, et se signer un certificat avec le nom de Alice dedans.
2) Verifier que le nom porté sur le certificat qui lui est présenté corresponds bien au nom DNS auquel il souhaite se connecter. Si il ne le fait pas, alors Trudy peut utiliser le certificat générique d'utilisateur qu'elle partage avec Bob, qui est bien signé par la bonne authorité de certification, et se faire passer pour Alice, puisque Bob ne verifie pas à qui il parle (Quel con, ce Bob!).
Sinon le deuxième problème est de construire un canal confidentiel dans lequel on poura faire un Xauth ou un L2TP sans que Trudy ne puisse espionner. Ca, on y arrive si Bob et Alice se mettent d'accord sur un secret partagé sans que Trudy ne le découvre. On sait qu'avec un Diffie Hellman, on peut se mettre d'accord sur un secret partagé alors qu'on est espionné, à condition de pouvoir authentifier la partie adverse. Ce problème est résolu comme nous l'avons vu, donc Bob et Alice peuvent construire un canal de communication où Trudy ne pourra pas espionner les communications.
C'est pour cela que nous n'avons besoin d'un certificat que du coté de la passerelle VPN. Il est à noter que quand tu envoies ton numéro de CB à un serveur HTTP/SSL, tu es dans la même situation: tu authentifie le serveur par un certificat, mais le serveur ne t'authentifie pas.
Un certificat utilisateur est utilisé dans des cas comme la télédéclaration pour se conformer à la legislation sur la signature electronique, mais il n'est pas nescessaire pour assurer la confidentialité de l'envoi d'information par le client.
A noter qu'il existe une extension à IKE, qui s'appelle Hybrid authentication, qui casse la symetrie de la phase 1 d'IKE. Le concentrateur d'accès utilisé un certificat, alors que le client ne s'authentifie pas. On obtient une SA de phase 1 sûre, où le client n'est pas authentifié, mais il peut le faire ensuite (par L2TP ou par Xauth).
Par L2TP directement ?
Ca voudrait dire que, d'un point de vue purement IPSec, on aurait negocie une phase2 avec un correspondant non authentifie (puisque tout le traffic L2TP est protege par une paire de IPSec SAs ) !
Oui, tu as une phase 2 non authentifiée, mais ca ne suffit pas à passer du traffic au travers de la passerelle VPN. Pour le faire, il faut que le client construise un tunnel L2TP, et donc qu'il passe une authentification.
IPsec+Xauth est un peu différent car la passerelle VPN prendra la décision d'accepter de relayer le traffic dès que Xauth sera validé, donc avant même la phase 2.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
Une petite autorite de certification en Perl + OpenSSL, utilisation en CLI, generation de pages HTML avec templates... C'est ce que j'ai trouve de mieux sans taper dans IDX-PKI ou OpenCA.
Ah ok, en fait j'utilise un truc à moi http://asyd.net/home/projects/asyd-ca :p (gestion des templates, et la TUI en ncurses est quasiment finie), mais je jetterais un oeil merci
-- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking Solaris User Group
Une petite autorite de certification en Perl + OpenSSL, utilisation en
CLI, generation de pages HTML avec templates... C'est ce que j'ai trouve
de mieux sans taper dans IDX-PKI ou OpenCA.
Ah ok, en fait j'utilise un truc à moi
http://asyd.net/home/projects/asyd-ca :p (gestion des templates, et
la TUI en ncurses est quasiment finie), mais je jetterais un oeil merci
--
http://asyd.net/home/ - Home Page
http://guses.org/home/ - French Speaking Solaris User Group
Une petite autorite de certification en Perl + OpenSSL, utilisation en CLI, generation de pages HTML avec templates... C'est ce que j'ai trouve de mieux sans taper dans IDX-PKI ou OpenCA.
Ah ok, en fait j'utilise un truc à moi http://asyd.net/home/projects/asyd-ca :p (gestion des templates, et la TUI en ncurses est quasiment finie), mais je jetterais un oeil merci
-- http://asyd.net/home/ - Home Page http://guses.org/home/ - French Speaking Solaris User Group
