Knowledge

Internet Key Exchange

Source đź“ť

284: 430:
Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management. IKE could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other
206:
User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys and certificates, as required. Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons.
261:
Originally, IKE had numerous configuration options but lacked a general facility for automatic negotiation of a well-known default case that is universally implemented. Consequently, both sides of an IKE had to exactly agree on the type of security association they wanted to create –
225:
key, information identifying the IP endpoints and ports that are to be protected, as well as what type of IPsec tunnel has been created. The IPsec stack, in turn, intercepts the relevant IP packets if and where appropriate and performs encryption/decryption as required. Implementations vary on how
762:
state that breaking a 1024-bit Diffie–Hellman group would break 66% of VPN servers, 18% of the top million HTTPS domains, and 26% of SSH servers, which the researchers claim is consistent with the leaks. This claim was refuted in 2015 by both Eyal Ronen and
262:
option by option – or a connection could not be established. Further complications arose from the fact that in many implementations the debug output was difficult to interpret, if there was any facility to produce diagnostic output at all.
478:
HostA -------------------------------------------------- HostB |HDR(A,0),sai1,kei,Ni--------------------------> | | <----------------------------HDR(A,0),N(cookie)| |HDR(A,0),N(cookie),sai1,kei,Ni----------------> | |
694:
There are a number of implementations of IKEv2 and some of the companies dealing in IPsec certification and interoperability testing are starting to hold workshops for testing as well as updated certification requirements to deal with IKEv2 testing.
441:(DoS) attack resilience: IKEv2 does not perform much processing until it determines if the requester actually exists. This addressed some of the DoS problems suffered by IKE which would perform a lot of expensive cryptographic processing from 246:(shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers and the hash of the shared key by encrypting them; Aggressive Mode does not. 269:
being a case in point), giving rise to different IKE implementations not being able to create an agreed-upon security association at all for many combinations of options, however correctly configured they might appear at either end.
414:
Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets that are very similar to what IPsec ESP uses to protect the IPsec packets. This led to simpler implementations and certifications for
241:
algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP security association. The authentication can be performed using either
411:
Simple message exchange: IKEv2 has one four-message initial exchange mechanism where IKE provided eight distinctly different initial exchange mechanisms, each one of which had slight advantages and disadvantages.
520:
The IETF ipsecme working group has standardized a number of extensions, with the goal of modernizing the IKEv2 protocol and adapting it better to high volume, production environments. These extensions include:
784:
between the offered configurations, with both IKEv1 and IKEv2. This can be avoided by careful segregation of client systems onto multiple service access points with stricter configurations.
590:: improving IKE/IPsec-level protocol synchronization between a cluster of IPsec endpoints and a peer, to reduce the probability of dropped connections after a failover event (RFC  787:
Both versions of the IKE standard are susceptible to an offline dictionary attack when a low entropy password is used. For the IKEv1 this is true for main mode and aggressive mode.
160:
combined these two documents plus additional clarifications into the updated IKEv2, published in September 2010. A later update upgraded the document from Proposed Standard to
59: 1379: 669:
implementations provide an IKE daemon which can configure (i.e., establish SAs) to the KLIPS or XFRM/NETKEY kernel-based IPsec stacks. XFRM/NETKEY is the
253:. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound). Phase 2 operates only in Quick Mode. 1265:; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; VanderSloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (October 2015). 249:
During IKE phase two, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like
1329:
Bhargavan, Karthikeyan; Brzuska, Christina; Fournet, CĂ©dric; Kohlweiss, Markulf; Zanella-BĂ©guelin, Santiago; Green, Matthew (January 2016).
528:: the ability to resume a failed IKE/IPsec "session" after a failure, without the need to go through the entire IKE setup process (RFC  691:
A number of network equipment vendors have created their own IKE daemons (and IPsec implementations), or license a stack from one another.
767:
in their paper "Critical Review of Imperfect Forward Secrecy" and by Paul Wouters of Libreswan in a 2015 article "66% of VPN's [
548:: special tagging of ESP packets that are authenticated but not encrypted, with the goal of making it easier for middleboxes (such as 758:
indicate that IKE is being exploited in an unknown manner to decrypt IPsec traffic, as is ISAKMP. The researchers who discovered the
811: 424: 71: 435:) were developed but not standardized. This meant that different implementations of work-arounds were not always compatible. 226:
the interception of the packets is done—for example, some use virtual devices, others take a slice out of the firewall, etc.
17: 567: 401: 397: 349:
and other extensions that are in common use. IKEv2 combines these in one RFC as well as making improvements to support for
487:(the responder) is experiencing large amounts of half-open IKE connections, it will send an unencrypted reply message of 1169: 563: 1420: 324: 538:: redirection of incoming IKE requests, allowing for simple load-balancing between multiple IKE endpoints (RFC  1504: 1356: 221:(SA) on both sides. The negotiated key material is then given to the IPsec stack. For instance, this could be an 1315: 885: 855: 681: 238: 95: 75: 1387: 1261:
Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex;
801: 677: 222: 86:
are derived. In addition, a security policy for every peer which will connect must be manually maintained.
1410: 391: 354: 337:
The IKEv2 protocol was described in Appendix A of RFC 4306 in 2005. The following issues were addressed:
192: 566:-only (i.e., certificate-less) authentication of both of the IKE peers; the goal is to allow for modern 511:. This is to ensure that the initiator is really capable of handling an IKE response from the responder. 265:
The IKE specifications were open to a significant degree of interpretation, bordering on design faults (
179:(ISOC), has maintained the copyrights of these standards as freely available to the Internet community. 759: 549: 345:(RFCs): The specifications for IKE were covered in at least three RFCs, more if one takes into account 306: 1484: 685: 196: 1449: 1297: 1157: 1148:"RFC 4306: Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p 38-40 1139:"RFC 4306 Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p. 11,33 777: 467: 455: 302: 214:
packets, usually on port 500, and generally requires 4–6 packets with 2–3 round trips to create an
237:
IKE phase one's purpose is to establish a secure authenticated communication channel by using the
816: 776:
IPsec VPN configurations which allow for negotiation of multiple configurations are subject to
631: 387: 211: 364:
Standard Mobility support: There is a standard extension for IKEv2 named (MOBIKE) (see also,
653:
There are several open source implementations of IPsec with associated IKE capabilities. On
580:: minimizing the time until an IKE peer detects that its opposite peer has crashed (RFC  358: 342: 1130:"RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 10-16 383: 369: 1091: 1057: 1023: 989: 955: 922: 218: 99: 47: 8: 1266: 620: 612: 442: 432: 294: 266: 1121:"RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 6 1112:"RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5 390:(UDP port 4500) enables these protocols to pass through a device or firewall performing 1437: 188: 83: 67: 1416: 1218: 438: 200: 161: 1081: 1047: 1013: 979: 945: 912: 889: 859: 796: 781: 427:(FIPS), which require each cryptographic implementation to be separately validated. 176: 165: 153: 145: 137: 126: 116: 106: 416: 55: 1478: 1472: 1466: 1094: 1075: 1060: 1041: 1026: 1007: 992: 973: 958: 939: 925: 906: 639: 635: 591: 581: 571: 553: 539: 529: 365: 169: 157: 149: 141: 130: 123:
defined the Internet Security Association and Key Management Protocol (ISAKMP).
120: 110: 1499: 1348: 1262: 243: 1349:"Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets" 1242: 623:. The ISAKMP/IKE implementation was jointly developed by Cisco and Microsoft. 1493: 723: 616: 405: 379: 350: 346: 79: 1173: 98:(IETF) originally defined IKE in November 1998 in a series of publications ( 1467:
RFC 2407 Internet Security Association and Key Management Protocol (ISAKMP)
727: 670: 604: 1274:. 22nd ACM Conference on Computer and Communications Security (CCS ’15). 753: 66:
certificates for authentication ‒ either pre-shared or distributed using
881:
RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE)
1330: 764: 705: 666: 608: 420: 431:
to initiate an action - which never eventuated. Work arounds (such as
1086: 1052: 1018: 984: 950: 917: 893: 879: 864: 849: 711: 658: 627: 113:
defined the Internet IP Security Domain of Interpretation for ISAKMP.
717: 662: 1158:
Internet Key Exchange: Internet Protocol Security (IPsec): Technet
941:
Internet Security Association and Key Management Protocol (ISAKMP)
851:
RFC 3129: Requirements for Kerberized Internet Negotiation of Keys
698:
The following open source implementations of IKEv2 are available:
1108: 1106: 1104: 734: 1328: 1074:
Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P. (September 2010).
1275: 1268:
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
1194: 215: 1260: 1101: 806: 654: 373: 250: 63: 51: 908:
The Internet IP Security Domain of Interpretation for ISAKMP
1479:
RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
769: 747: 673:
native IPsec implementation available as of version 2.6.
1412:
The Dangers of Key Reuse: Practical Attacks on IPsec IKE
603:
IKE is supported as part of the IPsec implementation in
1073: 1244:
Fielded Capability: End-to-end VPN SPIN9 Design Review
1005: 835:
The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
507:
request with that cookie value in a notify payload to
368:) used to support mobility and multihoming for it and 144:
updated IKE to version two (IKEv2) in December 2005.
877: 688:
much easier. OCF has recently been ported to Linux.
479:<--------------------------HDR(A,B),SAr1,ker,Nr| 229:IKEv1 consists of two phases: phase 1 and phase 2. 1043:IKEv2 Clarifications and Implementation Guidelines 404:protocol as used in Internet telephony protocol, 1491: 1331:"Downgrade Resilience in Key-Exchange Protocols" 1380:"Great Cipher, But Where Did You Get That Key" 1298:"Critical Review of Imperfect Forward Secrecy" 878:Richardson, M.; Redelmeier, D.H. (June 2001), 495:(the initiator) with a notify message of type 1322: 1039: 187:Most IPsec implementations consist of an IKE 152:clarified some open details in October 2006. 1170:"Using IPSec in Windows 2000 and XP, Part 1" 751: 305:. There might be a discussion about this on 102:) known as RFC 2407, RFC 2408 and RFC 2409: 1295: 843: 841: 829: 376:can be used by mobile and multihomed users. 680:also implements IPsec, IKE daemon via the 372:(ESP). By use of this extension IKEv2 and 273: 1296:Ronen, Eyal; Shamir, Adi (October 2015). 1085: 1051: 1017: 983: 949: 916: 863: 325:Learn how and when to remove this message 175:The parent organization of the IETF, the 133:defined the Internet Key Exchange (IKE). 1481:, Internet Engineering Task Force (IETF) 1475:, Internet Engineering Task Force (IETF) 1473:RFC 2409 The Internet Key Exchange (IKE) 1469:, Internet Engineering Task Force (IETF) 1040:Eronen, P.; Hoffman, P. (October 2006). 1006:C. Kaufman (Microsoft) (December 2005). 871: 838: 1313: 812:Kerberized Internet Negotiation of Keys 425:Federal Information Processing Standard 14: 1492: 1408: 1377: 1077:Internet Key Exchange (IKEv2) Protocol 1009:Internet Key Exchange (IKEv2) Protocol 971: 847: 515: 1346: 1316:"66% of VPN's are not in fact broken" 400:(SCTP) support: IKEv2 allows for the 474:, the scenario would look like this: 398:Stream Control Transmission Protocol 277: 256: 54:protocol suite. IKE builds upon the 46:) is the protocol used to set up a 24: 1250:, NSA via 'Der Spiegel', p. 5 750:presentations released in 2014 by 741: 634:partially support IKEv2 (RFC  598: 25: 1516: 1460: 1359:from the original on 10 June 2002 1219:"iked(8) - OpenBSD manual pages" 552:) to analyze the flow (RFC  282: 1402: 1371: 1340: 1307: 1289: 1254: 1235: 1211: 1187: 1162: 1151: 1142: 1133: 1124: 1115: 975:The Internet Key Exchange (IKE) 886:Internet Engineering Task Force 856:Internet Engineering Task Force 773:] are not in fact broken". 682:OpenBSD Cryptographic Framework 678:Berkeley Software Distributions 382:: The encapsulation of IKE and 232: 182: 96:Internet Engineering Task Force 1409:Felsch, Dennis (August 2018). 1347:Pliam, John (2 October 1999). 1314:Wouters, Paul (October 2015). 1067: 1033: 999: 965: 932: 899: 802:Group Domain of Interpretation 684:(OCF), which makes supporting 638:) as well as MOBIKE (RFC  370:Encapsulating Security Payload 13: 1: 1378:McGrew, David (5 July 2011). 822: 570:methods to be used (RFC  568:password-based authentication 1485:Overview of IKE (from Cisco) 588:High availability extensions 7: 790: 550:intrusion detection systems 355:Network Address Translation 239:Diffie–Hellman key exchange 76:Diffie–Hellman key exchange 10: 1521: 686:cryptographic accelerators 199:that processes the actual 195:and an IPsec stack in the 89: 560:Mutual EAP authentication 1353:Johns Hopkins University 848:Thomas, M. (June 2001), 546:IPsec traffic visibility 456:Security Parameter Index 1505:Cryptographic protocols 646:feature (also known as 274:Improvements with IKEv2 817:Key-agreement protocol 752: 632:Windows Server 2008 R2 526:IKE session resumption 388:User Datagram Protocol 210:The IKE protocol uses 578:Quick crash detection 361:traversal in general. 343:Requests for Comments 80:shared session secret 32:Internet Key Exchange 18:Internet key exchange 295:confusing or unclear 219:security association 100:Request for Comments 48:security association 621:Windows Server 2008 613:Windows Server 2003 516:Protocol extensions 433:Dead-Peer-Detection 303:clarify the section 267:Dead Peer Detection 499:, and will expect 84:cryptographic keys 782:downgrade attacks 439:Denial of Service 335: 334: 327: 257:Problems with IKE 172:in October 2014. 162:Internet Standard 70:(preferably with 27:Internet protocol 16:(Redirected from 1512: 1454: 1453: 1447: 1443: 1441: 1433: 1431: 1429: 1406: 1400: 1399: 1397: 1395: 1386:. Archived from 1375: 1369: 1368: 1366: 1364: 1344: 1338: 1337: 1335: 1326: 1320: 1319: 1311: 1305: 1304: 1302: 1293: 1287: 1286: 1284: 1282: 1273: 1258: 1252: 1251: 1249: 1239: 1233: 1232: 1230: 1229: 1215: 1209: 1208: 1206: 1205: 1191: 1185: 1184: 1182: 1181: 1172:. Archived from 1166: 1160: 1155: 1149: 1146: 1140: 1137: 1131: 1128: 1122: 1119: 1113: 1110: 1099: 1098: 1089: 1087:10.17487/RFC5996 1071: 1065: 1064: 1055: 1053:10.17487/RFC4718 1037: 1031: 1030: 1021: 1019:10.17487/RFC4306 1003: 997: 996: 987: 985:10.17487/RFC2409 969: 963: 962: 953: 951:10.17487/RFC2408 936: 930: 929: 920: 918:10.17487/RFC2407 903: 897: 896: 894:10.17487/RFC4322 875: 869: 868: 867: 865:10.17487/RFC3129 845: 836: 833: 797:Computer network 757: 506: 498: 490: 473: 461: 330: 323: 319: 316: 310: 286: 285: 278: 177:Internet Society 164:, published as 21: 1520: 1519: 1515: 1514: 1513: 1511: 1510: 1509: 1490: 1489: 1463: 1458: 1457: 1445: 1444: 1435: 1434: 1427: 1425: 1423: 1407: 1403: 1393: 1391: 1376: 1372: 1362: 1360: 1345: 1341: 1333: 1327: 1323: 1312: 1308: 1300: 1294: 1290: 1280: 1278: 1271: 1263:Heninger, Nadia 1259: 1255: 1247: 1241: 1240: 1236: 1227: 1225: 1223:man.openbsd.org 1217: 1216: 1212: 1203: 1201: 1193: 1192: 1188: 1179: 1177: 1168: 1167: 1163: 1156: 1152: 1147: 1143: 1138: 1134: 1129: 1125: 1120: 1116: 1111: 1102: 1072: 1068: 1038: 1034: 1004: 1000: 970: 966: 938: 937: 933: 905: 904: 900: 876: 872: 846: 839: 834: 830: 825: 793: 744: 742:Vulnerabilities 601: 599:Implementations 518: 504: 496: 488: 480: 471: 459: 417:Common Criteria 331: 320: 314: 311: 300: 287: 283: 276: 259: 235: 185: 92: 56:Oakley protocol 38:, versioned as 28: 23: 22: 15: 12: 11: 5: 1518: 1508: 1507: 1502: 1488: 1487: 1482: 1476: 1470: 1462: 1461:External links 1459: 1456: 1455: 1446:|website= 1421: 1401: 1390:on 9 July 2011 1370: 1339: 1321: 1306: 1288: 1253: 1234: 1210: 1186: 1161: 1150: 1141: 1132: 1123: 1114: 1100: 1066: 1032: 998: 964: 931: 898: 870: 837: 827: 826: 824: 821: 820: 819: 814: 809: 804: 799: 792: 789: 743: 740: 739: 738: 733:iked from the 731: 721: 715: 709: 703: 642:) through the 600: 597: 596: 595: 585: 575: 562:: support for 557: 543: 533: 517: 514: 513: 512: 477: 476: 475: 447: 446: 436: 428: 412: 409: 395: 377: 362: 333: 332: 290: 288: 281: 275: 272: 258: 255: 244:pre-shared key 234: 231: 184: 181: 135: 134: 124: 114: 91: 88: 30:In computing, 26: 9: 6: 4: 3: 2: 1517: 1506: 1503: 1501: 1498: 1497: 1495: 1486: 1483: 1480: 1477: 1474: 1471: 1468: 1465: 1464: 1451: 1439: 1424: 1422:9781939133045 1418: 1414: 1413: 1405: 1389: 1385: 1381: 1374: 1358: 1354: 1350: 1343: 1332: 1325: 1317: 1310: 1299: 1292: 1277: 1270: 1269: 1264: 1257: 1246: 1245: 1238: 1224: 1220: 1214: 1200: 1196: 1190: 1176:on 2008-10-12 1175: 1171: 1165: 1159: 1154: 1145: 1136: 1127: 1118: 1109: 1107: 1105: 1096: 1093: 1088: 1083: 1079: 1078: 1070: 1062: 1059: 1054: 1049: 1045: 1044: 1036: 1028: 1025: 1020: 1015: 1011: 1010: 1002: 994: 991: 986: 981: 977: 976: 968: 960: 957: 952: 947: 943: 942: 935: 927: 924: 919: 914: 910: 909: 902: 895: 891: 888:, p. 5, 887: 883: 882: 874: 866: 861: 858:, p. 1, 857: 853: 852: 844: 842: 832: 828: 818: 815: 813: 810: 808: 805: 803: 800: 798: 795: 794: 788: 785: 783: 779: 774: 772: 771: 766: 761: 760:Logjam attack 756: 755: 749: 736: 732: 729: 725: 722: 719: 716: 713: 710: 707: 704: 701: 700: 699: 696: 692: 689: 687: 683: 679: 674: 672: 668: 664: 660: 656: 651: 649: 645: 644:VPN Reconnect 641: 637: 633: 629: 624: 622: 618: 617:Windows Vista 614: 610: 606: 593: 589: 586: 583: 579: 576: 573: 569: 565: 561: 558: 555: 551: 547: 544: 541: 537: 534: 531: 527: 524: 523: 522: 510: 502: 494: 486: 482: 481: 469: 465: 457: 453: 449: 448: 444: 440: 437: 434: 429: 426: 422: 418: 413: 410: 407: 406:Voice over IP 403: 399: 396: 393: 389: 385: 381: 380:NAT traversal 378: 375: 371: 367: 363: 360: 356: 352: 351:NAT traversal 348: 347:NAT traversal 344: 340: 339: 338: 329: 326: 318: 315:February 2009 308: 307:the talk page 304: 298: 296: 291:This section 289: 280: 279: 271: 268: 263: 254: 252: 247: 245: 240: 230: 227: 224: 220: 217: 213: 208: 204: 202: 198: 194: 191:that runs in 190: 180: 178: 173: 171: 167: 163: 159: 155: 151: 147: 143: 139: 132: 128: 125: 122: 118: 115: 112: 108: 105: 104: 103: 101: 97: 87: 85: 81: 77: 73: 69: 65: 61: 57: 53: 49: 45: 41: 37: 33: 19: 1426:. Retrieved 1411: 1404: 1392:. Retrieved 1388:the original 1383: 1373: 1361:. Retrieved 1352: 1342: 1324: 1309: 1291: 1279:. Retrieved 1267: 1256: 1243: 1237: 1226:. Retrieved 1222: 1213: 1202:. Retrieved 1198: 1189: 1178:. Retrieved 1174:the original 1164: 1153: 1144: 1135: 1126: 1117: 1076: 1069: 1042: 1035: 1008: 1001: 974: 972:D. Harkins. 967: 940: 934: 907: 901: 880: 873: 850: 831: 786: 775: 768: 745: 728:KAME project 697: 693: 690: 675: 652: 647: 643: 625: 605:Windows 2000 602: 587: 577: 559: 545: 536:IKE redirect 535: 525: 519: 508: 500: 492: 484: 463: 451: 336: 321: 312: 301:Please help 292: 264: 260: 248: 236: 233:IKEv1 phases 228: 209: 205: 186: 183:Architecture 174: 136: 93: 78:to set up a 50:(SA) in the 43: 39: 35: 31: 29: 1428:11 February 1394:11 February 1195:"OpenIKEv2" 754:Der Spiegel 505:IKE_SA_INIT 503:to send an 489:IKE_SA_INIT 357:(NAT)) and 82:from which 62:. IKE uses 1494:Categories 1384:Cisco Blog 1363:5 February 1228:2023-06-21 1204:2023-06-21 1180:2009-12-24 823:References 765:Adi Shamir 706:strongSwan 702:OpenIKEv2, 667:strongSwan 626:Microsoft 609:Windows XP 450:Supposing 445:locations. 421:FIPS 140-2 297:to readers 193:user space 74:) ‒ and a 1448:ignored ( 1438:cite book 726:from the 712:Libreswan 659:Libreswan 648:Agile VPN 628:Windows 7 458:(SPI) of 203:packets. 1357:Archived 791:See also 737:project. 718:Openswan 663:Openswan 359:firewall 1281:15 June 780:-based 746:Leaked 735:OpenBSD 466:has an 443:spoofed 408:(VoIP). 293:may be 90:History 1419:  1276:Denver 1199:GitHub 724:Racoon 497:COOKIE 454:has a 341:Fewer 216:ISAKMP 197:kernel 189:daemon 168:  156:  148:  140:  129:  119:  109:  72:DNSSEC 60:ISAKMP 1500:IPsec 1334:(PDF) 1301:(PDF) 1272:(PDF) 1248:(PDF) 807:IPsec 671:Linux 655:Linux 509:HostB 501:HostA 493:HostA 485:HostB 464:HostB 452:HostA 374:IPsec 366:IPsec 251:IPsec 64:X.509 52:IPsec 44:IKEv2 40:IKEv1 1450:help 1430:2020 1417:ISBN 1396:2020 1365:2020 1283:2016 1095:5996 1061:4718 1027:4306 993:2409 959:2408 926:2407 778:MITM 676:The 665:and 640:4555 636:7296 630:and 619:and 592:6311 582:6290 572:5998 554:5840 540:5685 530:5723 462:and 419:and 402:SCTP 170:7296 158:5996 150:4718 142:4306 131:2409 121:2408 111:2407 94:The 58:and 42:and 1092:RFC 1082:doi 1058:RFC 1048:doi 1024:RFC 1014:doi 990:RFC 980:doi 956:RFC 946:doi 923:RFC 913:doi 890:doi 860:doi 770:sic 748:NSA 650:). 564:EAP 491:to 483:If 470:of 468:SPI 392:NAT 386:in 384:ESP 223:AES 212:UDP 166:RFC 154:RFC 146:RFC 138:RFC 127:RFC 117:RFC 107:RFC 68:DNS 36:IKE 1496:: 1442:: 1440:}} 1436:{{ 1415:. 1382:. 1355:. 1351:. 1221:. 1197:. 1103:^ 1090:. 1080:. 1056:. 1046:. 1022:. 1012:. 988:. 978:. 954:. 944:. 921:. 911:. 884:, 854:, 840:^ 661:, 657:, 615:, 611:, 607:, 594:). 584:). 574:). 556:). 542:). 532:). 201:IP 1452:) 1432:. 1398:. 1367:. 1336:. 1318:. 1303:. 1285:. 1231:. 1207:. 1183:. 1097:. 1084:: 1063:. 1050:: 1029:. 1016:: 995:. 982:: 961:. 948:: 928:. 915:: 892:: 862:: 730:, 720:, 714:, 708:, 472:B 460:A 423:( 394:. 353:( 328:) 322:( 317:) 313:( 309:. 299:. 34:( 20:)

Index

Internet key exchange
security association
IPsec
Oakley protocol
ISAKMP
X.509
DNS
DNSSEC
Diffie–Hellman key exchange
shared session secret
cryptographic keys
Internet Engineering Task Force
Request for Comments
RFC
2407
RFC
2408
RFC
2409
RFC
4306
RFC
4718
RFC
5996
Internet Standard
RFC
7296
Internet Society
daemon

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

↑