Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2)

. 852 | 853 | .ti 3 854 | [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 855 | Green, M., Halderman, J., Heninger, N., Springall, D., Thome, E., 856 | Valenta, L., VanderSloot, B., Wustrow, E., Beguelin, S., and 857 | Zimmermann, P., "Imperfect forward secrecy: How Diffie-Hellman fails 858 | in practice", Proc. 22rd ACM SIGSAC Conference on Computer and 859 | Communications Security, pp. 5-17, 2015. 860 | 861 | .ti 3 862 | [NTRU] Hoffstein, J., Pipher, J., and Silverman, J., "NTRU: A Ring-Based 863 | Public Key Cryptosystem", Lecture Notes in Computer Science, pp. 267-288, 864 | 1998. 865 | 866 | .ti 3 867 | [NTRUPRIME] 868 | .ti 14 869 | Bernstein, D., Chuengsatiansup, C., Lange, T., and van Vredendaal, C., 870 | "NTRU Prime", IACR Cryptology ePrint Archive: Report 2016/461, 2016. 871 | 872 | .ti 3 873 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 874 | Levels", RFC 2119, March 1997. 875 | 876 | .ti 3 877 | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and Kivinen, T., 878 | "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014. 879 | 880 | .ti 3 881 | [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) 882 | Message Fragmentation", RFC 7383, November 2014. 883 | 884 | .ti 3 885 | [RFC8019] Nir, Y., Smyslov, V., "Protecting Internet Key Exchange Protocol 886 | Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks", 887 | RFC 8019, November 2016. 888 | 889 | .ti 3 890 | [XMSS] Huelsing, A., Butin, D., Gazdag, S., and Mohaisen, A., 891 | "XMSS: Extended Hash-Based Signatures", Crypto Forum Research Group Internet 892 | Draft, 2017 893 | 894 | 895 | .ti 0 896 | .in 3 897 | Appendix A. Quantum-safe Ciphers 898 | 899 | Each of the specific quantum-safe ciphers is assigned a unique Transform 900 | ID. All of the selected quantum-safe ciphers are based on lattice 901 | construction. Specifically the ciphers fall into the categories of 902 | Ring Learning With Errors, NTRU and Streamlined NTRU Prime. In 903 | each case the selected parameters are chosen so as to achieve at least 128 904 | bits of post-quantum security. 905 | 906 | 907 | .ti 0 908 | .in 3 909 | Appendix A.1. Ring Learning With Errors 910 | 911 | Ring Learning with Errors is a cryptographic primitive that relies 912 | on the worst-case hardness of a shortest vector problem in ideal 913 | lattices. It is commonly abbreviated as RLWE. The security parameters 914 | are given by an integer n which is a power of 2, a prime integer q, an array 915 | of n coefficients denoted by {a} and a standard deviation sigma along with the 916 | type of error distribution X. Note that each coefficient of {a} is less 917 | than the prime q and is sampled from distribution X. Let a(x) be a 918 | polynomial, whose coefficients are given by {a}, the RLWE problem can be 919 | stated as follows: given polynomials a(x), b(x) and a small polynomial e(x), 920 | find the secret s(x) from the relationship a(x) * s(x) + b(x) = e(x) modulo q. 921 | 922 | .nf 923 | RLWE 128 924 | -------- 925 | .fi 926 | This set of parameters follows the system described by Bos et al 927 | [BCNS15]. Using a fixed coefficient array {a} in this way may result 928 | in security vulnerabilities such as "all-for-the-price-of-one" precomputation 929 | attacks such as the Logjam attack on the classical Diffie-Hellman 930 | key exchange [LOGJAM]. As has been pointed out since, this is 931 | straightforwardly solved by the coefficient array {a} being generated 932 | on-the-fly for each key exchange from a seed value shared by the 933 | initiator and responder. The fixed coefficient array {a} is also avoided 934 | in similar fashion in NewHope 128 (see below). 935 | 936 | The set of parameters that is proposed by Bos et al is given as follows: 937 | 938 | .in 6 939 | .nf 940 | n = 1024 941 | q = 2^32 -1 942 | sigma = 8/sqrt(2 * PI) 943 | X = discrete Gaussian 944 | {a} = 29FE0191, DD1A457D, 3534EE4B, 6450ED74, BBFE9F64, 92BF0F31, 945 | .in 12 946 | 8DCF8995, 4C5E30D0, 9E2ED04D, 8C18FE0B, 1A70F2E7, 2625CD93, 947 | 0065DA14, 6E009722, E6A70E8B, AEF6EF56, 8C6C06AF, 9E59E953, 948 | 4995F67B, E918EE9D, 8B4F41A7, 0D811041, F5FE6458, 3C02B584, 949 | CBCFC8FD, 5A01F116, 73408361, 44D3A098, BBDEECF6, 90E09082, 950 | F8538BA4, F9600091, D8D30FEF, 56201487, ACB2159D, 38F47F77, 951 | ED7A864F, 8FC785CA, 7CBD6108, 3CA577DE, FF44CCC2, A1385A79, 952 | 5C88E3AD, 177C46A9, DA4A4DD8, 2AA3594F, A4A5E629, 47CA6F6E, 953 | B2DF1BC6, 6841B78E, 0823F5A8, A18C7D52, 7634A0D1, DA1751BA, 954 | 18B9D25D, 5B2643BC, ACC6975D, 48E786F4, 05E3ED4E, 4DC86568, 955 | 3F5C5F99, 585DBFD7, EF6E0715, 7D36B823, 12D872CD, D7B78F27, 956 | DD672BF5, 2DC7C7EB, A3033801, 50E48348, 9162A260, 0BE8F15B, 957 | ABB563EC, 06624C5A, 812BF7BC, 8637AC35, F44504F3, FF8577AB, 958 | 4A0161B0, 000AEB0E, 311204AF, 2A76831B, 4D903F3A, 97204FA9, 959 | 9EB524E3, 1757AFAC, BA369FEC, CD8F198D, 6B33C246, 51C13FCE, 960 | B58ACC4E, 39ACF8DA, 7BB7EBF7, EDC1449D, C7B47FDB, 9C39148D, 961 | 4E688D7B, FAD0C2C2, 296CE85C, 6045C89C, 6441C0C6, 50C7C83A, 962 | C11764DD, 58D7EEA2, E57B9D0E, 4E142770, B8BFBB59, E143EBAA, 963 | FF60C855, 238727F0, E35B4A5B, 8F96940B, 4498A6BA, 5911093A, 964 | 394DD002, 521B00D2, 140BDAF9, EAB67207, 21E631A6, A04AADA9, 965 | A96A9843, 4B44CC9B, E4D24C33, C7E7AE78, E45A6C72, CBE61D3C, 966 | CE5A4869, 10442A52, DB11F194, 39FC415D, 7E7BDB76, AE9EFA22, 967 | 25F4F262, 472DD0A7, 42EBD7A0, E8038ECE, D3DB002A, 8416D2EC, 968 | DF88C989, 7FEA22D5, C7A3F6FE, 37409982, F45B75E2, 9A4AC289, 969 | 90406FD6, EA1C74A5, 5777B39F, D07F1FA3, CE6EDA0D, D150ECFB, 970 | BEFF71BA, 50129EFC, 51CE65B9, B9FB0AB8, 770C59CB, 11F2354F, 971 | 8623D4BB, D6FCAFD6, B2B1697C, 0D7067E2, 2BA5AFB9, D369C585, 972 | 5B5E156C, D8C81E6E, 80CFDF16, F6F441EB, C173BAF5, 78099E3A, 973 | D38F027B, 4AC8D518, 8D0108A1, E442B0F1, 56F9EA3C, D0D6BBCA, 974 | 4E17DCB4, 69BF743B, 0CCE779F, D5E59851, 63861EA2, B1CB22C1, 975 | BBFD2ACE, DDA390D1, EDF1059F, 04F80F89, B13AF849, 58C66009, 976 | E0D781C0, 588DC348, A305669D, 0D7AF67F, 32BC3C38, D725EFBA, 977 | DC3D9434, 22BD7ED8, 2DFD2926, 4BDEAD3A, B2D5ECE6, 16B05C99, 978 | FEEC7104, F6CAC918, 0944C774, CE00633B, C59DA01A, 41E8E924, 979 | 335DF501, 3049E8EE, 5B4B8AAC, C962FC91, D6BB22B3, 0AC870EB, 980 | C3D99400, A0CEAC28, AF07DE1E, 831C2824, 258C5DDC, 779417E6, 981 | 41CB33D0, 4E51076A, D1DB6038, 9E0B1C41, A9A1F90D, F27E7705, 982 | 75892711, 5D9F1175, 85CC508B, 5CA415BE, 1858C792, FB18632F, 983 | C94111EB, 937C0D28, C2A09970, 386209D9, BBDD9787, 2473F53A, 984 | EF7E7637, CFC8630B, 2BA3B7F8, 3C0047AD, 10D76FF7, B1D9414D, 985 | CEB7B902, A5B543F5, 2E484905, E0233C10, D061A1F8, CED0A901, 986 | AC373CAC, 04281F37, 3609797F, DB80964D, 7B49A74F, 7699656F, 987 | 0DCEC4BC, 0EC49C2D, F1573A4E, A3708464, 9A1E89F0, 6B26DEB6, 988 | 2329FA10, CA4F2BFF, 9E012C8E, 788C1DFD, 2C758156, 2774C544, 989 | 150A1F7D, 50156D6E, 7B675DE1, 5D634703, A7CEB801, 92733DAB, 990 | B213C00B, 304A65B1, 8856CF8E, 7FF7DD67, D0912293, 30064297, 991 | 663D051D, 01BC31B4, 2B1700BD, 39D7D18F, 1EAD5C95, 6FB9CD8B, 992 | A09993A6, B42071C0, 3C1F2195, 7FDF4CF8, C7565A7E, 64703D34, 993 | 14B250EF, 2FA338D2, AEE576DC, 6CCED41D, 612D0913, D0680733, 994 | 8B4DBE8A, 6FFEA3D0, 46197CA2, A77F916F, FA5D7BD6, 01E22AEB, 995 | 18E462DD, 4EC9B937, DE753212, 05113C94, 7786FBD4, FB379F71, 996 | 756CF595, EAADCFAB, BBD74C2E, 1F234AC9, 85E28AEB, 329F7878, 997 | D48FDE09, 47A60D0A, AE95163F, 72E70995, 27F9FCBF, BDCFCC41, 998 | 334BC498, EE7931A1, DFA6AEF4, 1EC5E1BF, 6221870F, CD54AE13, 999 | 7B56EF58, 4847B490, 31640CD3, 10940E14, 556CC334, C9E9B521, 1000 | 499611FF, BEC8D592, 44A7DCB7, 4AC2EABD, 7D387357, 1B76D4B6, 1001 | 2EACE8C9, 52B2D2A4, 0C1F2A64, 50EF2B9A, 3B23F4F4, 8DDE415E, 1002 | F6B92D2D, 9DB0F840, E18F309D, 737B7733, F9F563C5, 3C5D4AEE, 1003 | 8136B0AF, C5AC5550, 6E93DEF9, 946BCCEC, 5163A273, B5C72175, 1004 | 4919EFBD, 222E9B68, 6E43D8EE, AA039B23, 913FD80D, 42206F18, 1005 | 5552C01F, 35B1136D, FDC18279, 5946202B, FAAE3A37, 4C764C88, 1006 | 78075D9B, 844C8BA0, CC33419E, 4B0832F6, 10D15E89, EE0DD05A, 1007 | 27432AF3, E12CECA6, 60A231B3, F81F258E, E0BA44D7, 144F471B, 1008 | B4C8451E, 3705395C, E8A69794, 3C23F27E, 186D2FBA, 3DAED36B, 1009 | F04DEFF1, 0CFA7BDD, FEE45A4F, 5E9A4684, 98438C69, 5F1D921B, 1010 | 7E43FD86, BD0CF049, 28F47D38, 7DF38246, 8EED8923, E524E7FC, 1011 | 089BEC03, 15E3DE77, 78E8AE28, CB79A298, 9F604E2B, 3C6428F7, 1012 | DCDEABF3, 33BAF60A, BF801273, 247B0C3E, E74A8192, B45AC81D, 1013 | FC0D2ABE, F17E99F5, 412BD1C1, 75DF4247, A90FC3C0, B2A99C0E, 1014 | 0D3999D7, D04543BA, 0FBC28A1, EF68C7EF, 64327F30, F11ECDBE, 1015 | 4DBD312C, D71CE03A, AEFDAD34, E1CC7315, 797A865C, B9F1B1EB, 1016 | F7E68DFA, 816685B4, 9F38D44B, 366911C8, 756A7336, 696B8261, 1017 | C2FA21D2, 75085BF3, 2E5402B4, 75E6E744, EAD80B0C, 4E689F68, 1018 | 7A9452C6, A5E1958A, 4B2B0A24, 97E0165E, A4539B68, F87A3096, 1019 | 6543CA9D, 92A8D398, A7D7FDB4, 1EA966B3, 75B50372, 4C63A778, 1020 | 34E8E033, 87C60F82, FC47303B, 8469AB86, 2DAADA50, CFBB663F, 1021 | 711C9C41, E6C1C423, 8751BAA9, 861EC777, 31BCCCE1, C1333271, 1022 | 06864BEE, 41B50595, D2267D30, 878BA5C5, 65267F56, 2118FB18, 1023 | A6DDD3DE, 8D309B98, 68928CB2, FAE967DC, 3CEC52D0, 9CA8404B, 1024 | AADD68A8, 3AC6B1DF, D53D67EA, 95C8D163, B5F03F1D, 3A4C28A7, 1025 | E3C4B709, B8EB7C65, E76B42A3, 25E5A217, 6B6DD2B4, BEFC5DF4, 1026 | 9ACA5758, C17F14D3, B224A9D3, DE1A7C8F, 1382911B, 627A2FB9, 1027 | C66AE36E, 02CC60EF, C6800B20, 7A583C77, E1CECEE8, CA0001B4, 1028 | 6A14CF16, EF45DD21, 64CAA7D5, FF3F1D95, D328C67E, C85868B1, 1029 | 7FBF3FEB, 13D68388, 25373DD9, 8DE47EFB, 47912F26, 65515942, 1030 | C5ED711D, 6A368929, A2405C50, FFA9D6EB, ED39A0D4, E456B8B5, 1031 | 53283330, 7837FD52, 6EE46629, CAFC9D63, B781B08F, DD61D834, 1032 | FB9ACF09, EDA4444A, BB6AA57F, AED2385C, 22C9474D, 36E90167, 1033 | E6DF6150, F1B0DA3B, C3F6800E, 966302E0, 7DB1F627, F9632186, 1034 | B4933075, 81C5C817, 878CA140, 4EDE8FED, 1AF347C1, FDEB72BA, 1035 | 2DA7FF9A, B9BA3638, 2BB883F1, 474D1417, C2F474A4, 1E2CF9F3, 1036 | 231CB6B0, 7E574B53, EDA8E1DA, E1ACB7BB, D1E354A6, 7C32B431, 1037 | 8189991B, 25F9376A, 3FFA8782, CD9038F1, 119EDBD1, 5C571840, 1038 | 3DCA350F, 83923909, 9DC3CF55, 94D79DD0, D683DE2B, ECF4316A, 1039 | 0FFF48D4, 5D8076ED, 12B42C97, 2284CDB4, CB245554, 3025B4D9, 1040 | B0075F35, 43A3802E, 18332B4D, 056C4467, C597E3F7, 3F0EAF9D, 1041 | F48EBB9F, 92F62731, BDB76296, 516D4466, 226102B3, 15E38046, 1042 | A683C4E0, 6C0D1962, E20CB6CA, C90C1D70, D0FF8692, D1419690, 1043 | 2D6F1081, 34782E5E, AE092CD5, 90C99193, E97C0405, EAE201DA, 1044 | 631FB5AC, 279A2821, DF47BA5B, FBE587E2, 6810AD2D, C63E94BD, 1045 | 9AF36B42, F14F0855, 946CE350, 7E3320E0, 34130DFF, 8C57C413, 1046 | AB0723B2, F514C743, 63694BA3, 5665D23D, 6292C0B5, 9D768323, 1047 | 2F8E447C, B99A00FB, 6F8E5970, 69B3BB45, 59253E02, 1C518A02, 1048 | DD7C1232, C6416C38, 77E10340, CF6BEB9A, 006F9239, 0E99B50F, 1049 | 863AD247, 75F0451A, 096E9094, E0C2B357, 7CC81E15, 222759D4, 1050 | EE5BCFD0, 050F829B, 723B8FA9, 76143C55, 3B455EAF, C2683EFD, 1051 | EE7874B4, 9BCE92F7, 6EED7461, 8E93898F, A4EBE1D0, FA4F019F, 1052 | 1B0AD6DA, A39CDE2F, 27002B33, 830D478D, 3EEA937E, 572E7DA3, 1053 | 4BFFA4D1, 5E53DB0B, 708D21EE, B003E23B, 12ED0756, 53CA0412, 1054 | 73237D35, 438EC16B, 295177B8, C85F4EE6, B67FD3B4, 5221BC81, 1055 | D84E3094, 18C84200, 855E0795, 37BEC004, DF9FAFC9, 60BEB6CD, 1056 | 8645F0C5, B1D2F1C3, ECDC4AE3, 424D17F1, 8429238C, 6155EAAB, 1057 | A17BEE21, 218D3637, 88A462CC, 8A1A031E, 3F671EA5, 9FA08639, 1058 | FF4A0F8E, 34167A7D, 1A817F54, 3215F21E, 412DD498, 57B633E7, 1059 | E8A2431F, 397BD699, 5A155288, BB3538E8, A49806D2, 49438A07, 1060 | 24963568, 40414C26, E45C08D4, 61D2435B, 2F36AEDE, 6580370C, 1061 | 02A56A5E, 53B18017, AF2C83FC, F4C83871, D9E5DDC3, 17B90B01, 1062 | ED4A0904, FA6DA26B, 35D9840D, A0C505E4, 3396D0B5, EC66B509, 1063 | C190E41C, 2F0CE5CF, 419C3E94, 220D42CA, 2F611F4F, 47906734, 1064 | 8C2CDB17, D8658F1C, 2F6745CD, 543D0D4F, 818F0469, 380FFDAE, 1065 | F5DD91E2, AD25E46A, E7039205, A9F47165, B2114C12, CF7F626F, 1066 | 54D2C9FF, E4736A36, 16DB09FC, E2B787BB, 9631709A, 72629F66, 1067 | 819EBA08, 7F5D73F3, A0B0B91C, FEDFBA71, 252F14EE, F26F8FA2, 1068 | 92805F94, 43650F7F, 3051124F, 72CA8EAD, 21973E34, A5B70509, 1069 | B36A41CC, C52EDE5F, F706A24E, 8AAF9F92, ADF6D99A, 23746D73, 1070 | 1DA39F70, 9660FC8F, A0A8CFEB, 83D5EFCA, 0AA4A72F, EEF1B2DE, 1071 | 00CFCC66, 8A145369, 6376CEDA, A3262E2E, 3367BBA8, 01488C32, 1072 | 5561A2AD, 40821BF2, F0C89F61, C4FAA6B3, D843377A, 67A76555, 1073 | E8D9F1CE, 943034FF, 2BD468BD, A514D935, 50CDB19D, A09C7E9E, 1074 | 6FEBEC30, B1B36CF7, CD7A30BC, 36C6FE0A, 2DF52C45, 45C9957F, 1075 | 65076A79, BF783DEE, 718D37F0, 098F9117, 9A70C430, 80EB1A53, 1076 | 9F2505B1, 48D10D98, B8D781E9, F2376133, ECF25B98, 5A3B0E18, 1077 | 2F623537, 9F0E34A4, F1027EB6, F9B16022, BA3FEC59, EF7226FD, 1078 | 9F3058AA, BB51DE0E, D5435EA0, 8A6479D5, 077708B8, 9634876A, 1079 | 069A260A, 168D9E6A, 9FD18E94, 8A7ACD53, 8E5A5869, 1B6F35FD, 1080 | A968913B, C72F076B, 7DDA354C, 25B0297C, D07219D5, A66862BA, 1081 | 87E8EE67, FA28809B, 55762443, 31EF4956, F4F4A511, 9A9378CB, 1082 | 42ABDBDE, 7AA484B7, E8EC22ED, CADDEF61, 9D18538A, A81B923E, 1083 | 9C32F92A, 6D278E58, 4CDFC716, AB64814F, F832BF1A, E2C1A36B, 1084 | 20675610, E78D855A, 38332C3D, 5AE0EAD9, 2E23F22D, 3C8683C5, 1085 | A351AF89, 54720D3B, ABC6E51F, 89330C8E, 600D5650, 197EA0C6, 1086 | 7D502A5D, 3A536EA7, 7DF71F32, 456FE645, 3EF5E7A2, 6664BCAF, 1087 | A9D074C2, E9D9E478, 1AE9AB77, FECE7160, C618EEEC, 771B0026, 1088 | 2B54F43C, 145DA102, 1B3D7949, BB6E2D9D, DB8FDC4A, 25397EBA, 1089 | 9228A6E9, 56B4C69D, 337B943C, E35B716C, F7FE89A1, 023AC20D, 1090 | 033165C8, 9F13B130, C1BAFB1D, A2C42C8C, 58E4D431, E10741E6, 1091 | 2547589A, 8D9EF7BD, 7E322280, F49FDDC2, BE21A094, A061178A, 1092 | 34D9F13B, 694D652F, 05084A2A, 2767B991, E8536AB4, EBFADF6F, 1093 | F4C8DFAC, D9967CCA, E04BCF3F, 232B3460, 9FF6E88A, 6DF3A2B0, 1094 | 0FE10E99, 7B059283, 067BFB57, 8DDA26B0, B7D6652F, 85705248, 1095 | 0826240C, 5DF7F52E, 47973463, B9C22D37, 9BEB265D, 493AB6FD, 1096 | 10C0FB07, 947C102A, 5FEC0608, 140E07AE, 8B330F43, 9364A649, 1097 | C9AD63EF, BE4B2475, 1A09AC77, 9E40A4B0, BA9C23E7, 7F4A798D, 1098 | E2C52D66, A26EE9E0, 8C79DCE7, DD7F1C3D, 6AE83B20, 073DBA03, 1099 | B1844D97, 16D7ED6E, 5E0DE0B1, A497D717, FA507AA2, C332649B, 1100 | 21419E15, 384D9CCC, 8B915A8B, BA328FD5, F99E8016, 545725EC, 1101 | ED9840ED, 71E5D78A, 21862496, 6F858B6C, F3736AE2, 8979FC2B, 1102 | 5C8122D0, 0A20EB5A, 2278AA6E, 55275E74, 22D57650, E5FFDC96, 1103 | 6BA86E10, 4EC5BFCC, 05AFA305, FB7FD007, 726EA097, F6A349C4, 1104 | CB2F71E4, 08DD80BA, 892D0E23, BD2E0A55, 40AC0CD3, BFAF5688, 1105 | 6E40A6A5, 6DA1BBE0, 969557A9, FB88629B, 11F845C4, 5FC91C6F, 1106 | 1B0C7E79, D6946953, 27A164A0, 55D20869, 29A2182D, 406AA963, 1107 | 74F40C59, 56A90570, 535AC9C6, 9521EF76, BA38759B, CD6EF76E, 1108 | F2181DB9, 7BE78DA6, F88E4115, ABA7E166, F60DC9B3, FECA1EF3, 1109 | 43DF196A, CC4FC9DD, 428A8961, CF6B4560, 87B30B57, 20E7BAC5, 1110 | BFBDCCDF, F7D3F6BB, 7FC311C8, 2C7835B5, A24F6821, 6A38454C, 1111 | 460E42FD, 2B6BA832, C7068C72, 28CDCE59, AE82A0B4, 25F39572, 1112 | 9B6C7758, E0FE9EBA, A8F03EE1, D70B928E, 95E529D7, DD91DB86, 1113 | F912BA8C, 7F478A6A, 1F017850, 5A717E10, DAC243F9, D235F314, 1114 | 4F80AAE6, A46364D8, A1E3A9E9, 495FEFB1, B9058508, 23A20999, 1115 | 73D18118, CA3EEE2A, 34E1C7E2, AADBADBD. 1116 | .in 3 1117 | .fi 1118 | 1119 | The public key size of RLWE 128 is 4096 octets and it provides 128-bit 1120 | post-quantum security, although it does not provide forward secrecy 1121 | due to the way coefficient array {a} is generated. A set of open source 1122 | ciphersuites has been implemented and included in OpenSSL v1.0.1f and may be 1123 | found within the libcrypto module. The authors anticipate RLWE being 1124 | incorporated into TLS with the RLWE 128 ciphersuites being compatible with 1125 | TLS 1.3. Moreover, the ciphersuites are constant time, and therefore are not 1126 | vulnerable to possible side channel attacks. 1127 | 1128 | .nf 1129 | NewHope 128 1130 | ----------- 1131 | .fi 1132 | This is a variation on the ring learning with errors cipher by Alkim et al 1133 | [ADPS] who set out in their solution to make improvements to RLWE 128. Their 1134 | main improvements are to use a random coefficient array {a} for each key 1135 | exchange and to reduce the size of key exchanges by using a 14-bit modulus 1136 | instead of a 32-bit modulus. Additionally they relax the requirement for the 1137 | error distribution to be discrete Gaussian and substitute the easier to 1138 | generate Binomial distribution and provide a security justification. The set 1139 | of parameters proposed by Alkim et al is given as follows: 1140 | 1141 | .in 6 1142 | .nf 1143 | n = 1024 1144 | q = 12289 1145 | sigma = sqrt(8) 1146 | X = Binomial 1147 | .in 3 1148 | .fi 1149 | 1150 | This cipher provides 128-bit post-quantum security and has a public key size 1151 | of 1792 octets. It features forward secrecy. Open source, constant 1152 | time, side-channel-proof, ciphersuites are publically available. 1153 | 1154 | .ti 0 1155 | .in 3 1156 | Appendix A.2. NTRU Lattices 1157 | 1158 | NTRU lattices are another variant of cryptosystems based on integer lattices. 1159 | The lattices have a cyclic structure as in the case of RLWE, however the 1160 | NTRU problem can be stated as follows: given a polynomial a(x), a small 1161 | secret polynomial e(x) and ciphertext c(x) find the secret e(x) from the 1162 | ciphertext c(x) = a(x) * s(x) + e(x), modulo some integer q, where s(x) is a 1163 | small secret polynomial. In the case of NTRU-Prime 216, the transmitted 1164 | secret is the small polynomial s(x) and e(x) is generated incidentally as 1165 | a result of streamlined data packing of the ciphertext. 1166 | 1167 | .nf 1168 | NTRU EES743EP1 1169 | -------------- 1170 | .fi 1171 | The inventors of the first lattice cryptosystem by Silverman et al in 1996 1172 | have been developing their system ever since. Adoption by the crypto community 1173 | has been hampered by patents and a lack of security proof. Whilst the 1174 | polynomial ring of RLWE is truncated modulo (x^n + 1) where n is an integer 1175 | power of 2, the operations of NTRU EES743EP1 [NTRU] are defined over the 1176 | polynomial ring modulo (x^n - 1) where n is 743, a prime integer. The 1177 | integer modulus q is a power of 2, and it is 2048 in NTRU EES743EP1. The 1178 | QSKE public value is 1030 octets. 1179 | .in 3 1180 | .fi 1181 | 1182 | .nf 1183 | NTRU-Prime 216 1184 | -------------- 1185 | .fi 1186 | The authors, Bernstein et al [NTRUPRIME], of this recent variant of NTRU set 1187 | out to provide increased security in the light of possible vulnerabilities 1188 | in the mathematical structure of rings used in NTRU and RLWE. Accordingly a 1189 | Galois field, not a ring, is used in NTRU-Prime 216 with polynomials reduced 1190 | modulo (x^p - x - 1), where p is a prime integer. Specifically, while the 1191 | operations of NTRU EES743EP1 are defined over the polynomial modulo 1192 | (x^743 - 1), the operations of NTRU-Prime 216 [NTRUPRIME] are defined over 1193 | polynomial modulo (x^743 - x - 1). The integer modulus q is also chosen to 1194 | be a prime to avoid any additional mathematical structure that may be 1195 | potentially exploited. NTRU-Prime 216 has q = 7541. There is another 1196 | parameter, an integer t, which defines the weight of one of the public key 1197 | polynomials. The value of t is chosen to be 157 in this case so as to 1198 | make cryptographic failure an impossibility. Cryptographic failure is 1199 | theoretically possible in some ring based systems but usually these systems 1200 | are designed so that this occurs with infinitesimal probability. 1201 | 1202 | NTRU-Prime 216 has been designed to minimize the public key size and key 1203 | encapsulation data by using streamlined data packing and the resulting 1204 | QSKE public value is 1200 octets long. The ciphertext 1205 | includes a 256 bit key confirmation hash. The system achieves forward 1206 | secrecy. It is a very conservative design achieving 216 bits pre-quantum 1207 | security and at least 128 bits post-quantum security. Open source, constant 1208 | time, side-channel-proof ciphersuites are publicly available. 1209 | 1210 | 1211 | .ti 0 1212 | .in 0 1213 | Authors' Addresses 1214 | 1215 | .in 3 1216 | .sp 1217 | .nf 1218 | C. Tjhai 1219 | Post-Quantum 1220 | EMail: cjt@post-quantum.com 1221 | .sp 1222 | .fi 1223 | 1224 | .in 3 1225 | .sp 1226 | .nf 1227 | M. Tomlinson 1228 | Post-Quantum 1229 | EMail: mt@post-quantum.com 1230 | .sp 1231 | .fi 1232 | 1233 | .in 3 1234 | .sp 1235 | .nf 1236 | A. Cheng 1237 | Post-Quantum 1238 | EMail: ac@post-quantum.com 1239 | .sp 1240 | .fi 1241 | 1242 | .in 3 1243 | .sp 1244 | .nf 1245 | G. Bartlett 1246 | Cisco Systems 1247 | EMail: grbartle@cisco.com 1248 | .sp 1249 | .fi 1250 | -------------------------------------------------------------------------------- /draft-tjhai-ipsecme-hybrid-qske-ikev2-02.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ]> 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) 22 | 23 | Post-Quantum 24 |

25 | 26 | cjt@post-quantum.com 27 |

28 | 29 | 30 | 31 | Post-Quantum 32 |

33 | 34 | mt@post-quantum.com 35 |

36 | 37 | 38 | 39 | Cisco Systems 40 |

41 | 42 | grbartle@cisco.com 43 |

44 | 45 | 46 | 47 | Cisco Systems 48 |

49 | 50 | sfluhrer@cisco.com 51 |

52 | 53 | 54 | 55 | ISARA Corporation 56 |

57 | 58 | daniel.vangeest@isara.com 59 |

60 | 61 | 62 | 63 | Onboard Security 64 |

65 | 66 | zzhang@onboardsecurity.com 67 |

68 | 69 | 70 | 71 | Philips 72 |

73 | 74 | oscar.garcia-morchon@philips.com 75 |

76 | 77 | 78 | 79 | Internet Engineering Task Force 80 | 81 | This document describes how to extend Internet Key Exchange Protocol 82 | Version 2 (IKEv2) so that the shared secret exchanged between peers 83 | has resistance against quantum computer attacks. The basic idea is 84 | to exchange one or more post-quantum key exchange payloads in 85 | conjunction with the existing (Elliptic Curve) Diffie-Hellman payload. 86 | 87 | 88 | 89 | 90 |

91 |

92 | Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 93 | uses the Diffie-Hellman (DH) or Elliptic Curve 94 | Diffie-Hellman (ECDH) algorithm to establish a shared secret 95 | between an initiator and a responder. The security of the DH and 96 | ECDH algorithms relies on the difficulty to solve a discrete logarithm 97 | problem in multiplicative and elliptic curve groups respectively when 98 | the order of the group parameter is large enough. While solving such 99 | a problem remains difficult with current computing power, it is 100 | believed that general purpose quantum computers will be able to solve 101 | this problem, implying that the security of IKEv2 is compromised. 102 | There are, however, a number of cryptosystems that are conjectured to 103 | be resistant against quantum computer attack. This family of 104 | cryptosystems are known as post-quantum cryptography (PQC). It is 105 | ometime also referred to as quantum-safe cryptography (QSC) or 106 | quantum-resistant cryptography (QRC). 107 |

108 | 109 |

110 | This document describes a framework to integrate QSC for IKEv2, while 111 | maintaining backwards compatibility, to derive a set of IKE keys that 112 | have resistance to quantum computer attacks. Our framework allows the 113 | negotiation of one or more QSC algorithm to exchange data, in addition 114 | to the existing DH or ECDH key exchange data. We believe that the 115 | feature of using more than one post-quantum algorithm is important as 116 | many of these algorithms are relatively new and there may be a need to 117 | hedge the security risk with multiple key exchange data from several 118 | distinct QSC algorithms. 119 | 120 | 121 | 122 | The secrets established from each key exchange are combined in a way 123 | such that should the post-quantum secrets not be present, the derived 124 | shared secret is equivalent to that of the standard IKEv2; on the 125 | other hand, a post-quantum shared secret is obtained if both classical 126 | and post-quantum key exchange data are present. This framework also 127 | applies to key exchanges in IKE Security Associations (SAs) for 128 | Encapsulating Security Payload (ESP) or 129 | Authentication Header (AH) , i.e. Child SAs, 130 | in order to provide a stronger guarantee of forward security. 131 | 132 | 133 | Some post-quantum key exchange payloads may have size larger than 134 | the standard MTU size, and therefore there could be issues with 135 | fragmentation at IP layer. IKE does allow transmission over TCP 136 | where fragmentation is not an issue ; 137 | however, we believe that a UDP-based solution will be required 138 | too. IKE does have a mechanism to handle fragmentation within 139 | UDP , however that is only applicable to 140 | messages exchanged after the IKE_SA_INIT. To use this mechanism, 141 | we use the IKE_AUX exchange as outlined in 142 | . With this 143 | mechanism, we do an initial key exchange, using a smaller, possibly 144 | non-quantum resistant primitive, such as ECDH. Then, before we do 145 | the IKE_AUTH exchange, we perform one or more IKE_AUX exchanges, 146 | each of which includes a secondary key exchange. As the IKE_AUX 147 | exchange is encrypted, the IKE fragmentation protocol RFC7383 148 | can be used. The IKE SK values will be updated after each exchange, 149 | and so the final IKE SK values will depend on all the key exchanges, 150 | hence they are secure if any of the key exchanges are secure. 151 | 152 | 153 | Note that readers should consider the approach in this document as 154 | providing a long term solution in upgrading the IKEv2 protocol to 155 | support post-quantum algorithms. A short term solution to make IKEv2 156 | key exchange quantum secure is to use post-quantum pre-shared keys as 157 | discussed in . 158 |

159 | 160 |

161 | Changes in this draft in each version iterations. 162 | 163 | draft-tjhai-ipsecme-hybrid-qske-ikev2-01 164 | 165 | 166 | Use IKE_AUX to perform multiple key exchanges in succession. 167 | 168 | Handle fragmentation by keeping the first key exchange (a standard 169 | IKE_SA_INIT with a few extra notifies) small, and encrypting the rest 170 | of the key exchanges. 171 | 172 | Simplify the negotiation of the ‘extra’ key exchanges. 173 | 174 | 175 | draft-tjhai-ipsecme-hybrid-qske-ikev2-00 176 | 177 | 178 | We added a feature to allow more than one post-quantum key 179 | exchange algorithms to be negotiated and used to exchange a post- 180 | quantum shared secret. 181 | Instead of relying on TCP encapsulation to deal with IP level 182 | fragmentation, we introduced a new key exchange payload that can 183 | be sent as multiple fragments within IKE_SA_INIT message. 184 | 185 | 186 | 187 |

188 | 189 |

190 | The remainder of this document is organized as follows. 191 | summarizes design criteria. describes how 192 | post-quantum key exchange is performed between two IKE peers and how 193 | keying materials are derived. The rationale behind the approach of this 194 | extension is described in . 195 | discusses security considerations an lastly, 196 | discusses IANA considerations for the name spaces introduced in this 197 | document. 198 | 199 | 200 | The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 201 | SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 202 | document, are to be interpreted as described in RFC 2119 . 203 |

204 |

205 | 206 |

207 | The design of the proposed post-quantum IKEv2 is driven by the 208 | following criteria: 209 | 210 | 211 | Need for post-quantum cryptography in IPsec. Quantum computers 212 | 213 | might become feasible in the next 5-10 years. If current 214 | Internet communications are monitored and recorded today (D), 215 | the communications could be decrypted as soon as a quantum- 216 | computer is available (e.g., year Q) if key negotiation only 217 | relies on non post-quantum primitives. This is a high threat 218 | for any information that must remain confidential for a long 219 | period of time T > Q-D. The need is obvious if we assume that Q 220 | is 2040, D is 2020, and T is 30 years. Such a value of T is 221 | typical in classified or healthcare data. 222 | 223 | 224 | 225 | Hybrid. Currently, there does not exist a post-quantum key 226 | 227 | exchange that is trusted at the level that ECDH is trusted 228 | against conventional (non-quantum) adversaries. A hybrid 229 | approach allows introducing promising post-quantum candidates 230 | next to well-established primitives, since the overall security 231 | is at least as strong as each individual primitive. 232 | 233 | 234 | 235 | Focus on quantum-resistant confidentiality. A passive attacker 236 | 237 | can eavesdrop on IPsec communication today and decrypt it once a 238 | quantum computer is available in the future. This is a very 239 | serious attack for which we do not have a solution. An attacker 240 | can only perform active attacks such as impersonation of the 241 | communicating peers once a quantum computer is available, 242 | sometime in the future. Thus, our design focuses on quantum- 243 | resistant confidentiality due to the urgency of this problem. 244 | This document does not address quantum-resistant authentication 245 | since it is less urgent at this stage. 246 | 247 | 248 | 249 | Limit amount of exchanged data. The protocol design should be 250 | 251 | such that the amount of exchanged data, such as public-keys, is 252 | kept as small as possible even if initiator and responder need 253 | to agree on a hybrid group or multiple public-keys need to be 254 | exchanged. 255 | 256 | 257 | 258 | Future proof. Any cryptographic algorithm could be potentially 259 | 260 | broken in the future by currently unknown or impractical 261 | attacks: quantum computers are merely the most concrete example 262 | of this. The design does not categorize algorithms as "post-quantum" 263 | or "non post-quantum" and does not create assumptions 264 | about the properties of the algorithms, meaning that if 265 | algorithms with different properties become necessary in the future, 266 | this framework can be used unchanged to facilitate migration to 267 | those algorithms. 268 | 269 | 270 | 271 | Limited amount of changes. A key goal is to limit the number of 272 | 273 | changes required when enabling a post-quantum handshake. This 274 | ensures easier and quicker adoption in existing implementations. 275 | 276 | 277 | 278 | Localized changes. Another key requirement is that changes to 279 | 280 | the protocol are limited in scope, in particular, limiting 281 | changes in the exchanged messages and in the state machine, so 282 | that they can be easily implemented. 283 | 284 | 285 | 286 | Deterministic operation. This requirement means that the hybrid 287 | 288 | post-quantum exchange, and thus, the computed key, will be based 289 | on algorithms that both client and server wish to support. 290 | 291 | 292 | 293 | Fragmentation support. Some PQC algorithms could be relatively 294 | 295 | bulky and they might require fragmentation. Thus, a design goal 296 | is the adaptation and adoption of an existing fragmentation 297 | method or the design of a new method that allows for the 298 | fragmentation of the key shares. 299 | 300 | 301 | 302 | Backwards compatibility and interoperability. This is a 303 | 304 | fundamental requirement to ensure that hybrid post-quantum IKEv2 305 | and a non-post-quantum IKEv2 implementations are interoperable. 306 | 307 | 308 | 309 | FIPS compliance. IPsec is widely used in Federal Information 310 | 311 | Systems and FIPS certification is an important requirement. 312 | However, algorithms that are believed to be post-quantum are not 313 | FIPS compliant yet. Still, the goal is that the overall hybrid 314 | post-quantum IKEv2 design can be FIPS compliant. 315 | 316 | 317 | 318 | 319 | 320 |

321 | 322 |

323 |

324 | This design assigns new group identifiers (Transform Type 4) to the 325 | various post-quantum key exchanges (which will be defined later). We 326 | specifically do not make a distinction between classical (DH and ECDH) 327 | and post-quantum key exchanges, nor post-quantum algorithms which are 328 | true key exchanges versus post-quantum algorithms that act as key 329 | transport mechanisms; all are treated equivalently by the 330 | protocol. In order to support both hybrid key exchanges (that is, 331 | relying on distinct key exchanges) and fragmentation, the proposed 332 | hybrid post-quantum IKEv2 protocol extends IKE 333 | by adding additional key exchange messages (IKE_AUX) between the 334 | IKE_SA_INIT and the IKE_AUTH exchanges. In order to minimize 335 | communication overhead, only the key shares that are agreed to be used 336 | are actually exchanged. In order to achieve this, the IKE_SA_INIT 337 | exchange now includes notify payloads that negotiate the extra key 338 | exchanges to be used. The initiator IKE_SA_INIT message includes a 339 | notify that lists the extra key exchange policy required by the 340 | initiator; the responder selects one of the listed policies, and 341 | includes that as a notify in the response IKE_SA_INIT message. Then, 342 | the initiator and the responder perform one (or possibly more) IKE_AUX 343 | exchange; each such exchange includes a KE payload for the key exchange 344 | that was negotiated. 345 | 346 | Here is an overview of the initial exchanges: 347 | 348 |

352 | 353 | <-- {IKE_AUX (hybrid post-quantum key exchange)} --> 354 | ... 355 | <-- {IKE_AUX (hybrid post-quantum key exchange)} --> 356 | 357 | <-- {IKE_AUTH} --> 358 | ]]> 359 | 360 | The extra post-quantum key exchanges can use algorithms that are 361 | currently considered to be resistant to quantum computer attacks. These 362 | algorithms are collectively referred to as post-quantum algorithms in 363 | this document. 364 | 365 |

366 | 367 |

368 | In the simplest case, the initiator is happy with a single key exchange 369 | (and has no interest in supporting multiple), and he is not concerned 370 | with possible fragmentation of the IKE_SA_INIT messages (either because 371 | the key exchange he selects is small enough not to fragment, or he is 372 | confident that fragmentation will be handled either by IP fragmentation, 373 | or transport via TCP). In the following we overview the two protocol 374 | rounds involved in the hybrid post-quantum protocol. 375 | 376 | In this case, the initiator performs the IKE_SA_INIT as standard, 377 | inserting this prefered key exchange (which is possibly a post-quantum 378 | algorithm) as the listed Transform Type 4, and including the initiator 379 | KE payload. If the responder accepts the policy, he responds with an 380 | IKE_SA_INIT response, and IKE continues as usual. 381 | 382 | If the initiator desires to negotiate multiple key exchanges, or he 383 | needs IKE to handle any possible fragmentation, then he uses the protocol 384 | listed below. 385 | 386 |

387 | In the first round, the IKE_SA_INIT request and response messages 388 | negotiate the initial IKE SAs (as currently), as well as the key 389 | exchanges that will be used within the IKE_AUX phase below. 390 | 391 | 392 | The initiator negotiates cryptographic suites as per RFC7296, with the 393 | listed Transform Type 4 (and KE payload) being either the first key 394 | exchange on his desired list of key exchanges, or alternatively a small 395 | classical one (in order to enable fragmentation support of the later 396 | key exchanges). In addition, the initial IKE_SA_INIT message will 397 | include the following two Notify payloads: 398 | 399 | 400 | The N(AUX_EXCHANGE_SUPPORTED) notify, as specified in 401 | . This draft makes 402 | no requirements about the included data. 403 | 404 | An N(EXTRA_KEY_EXCHANGE_POLICY) notify, which has a Protocol ID 405 | and SPI Size of 0, and includes the below data. 406 | 407 | 408 | 409 | This data will be the list of groups that the initiator is willing to 410 | negotiate during the IKE_AUX phase below. The initiator signifies this 411 | by specifying the specific list of the sets of key exchanges that he will 412 | allow. The list MUST be ordered from most prefered to least 413 | prefered. This is encoded as a series of 2 byte values; a specified list 414 | of acceptable groups is given as the specific Transform IDs, followed by 415 | a 0x00 value. For example, if the NewHope post-quantum key exchange is 416 | 0x40, Round2 is 0x42, and SIKE is 0x47, then the data payload: 417 |

422 | will signify that the initiator is willing to perform IKE_AUX with 423 | either NewHope, Round2 followed by SIKE, or only Round2. 424 | 425 | If the initiator is willing to skip the IKE_AUX phase, he can signify 426 | that by including a 0000 value as a list; for example: 427 |

433 | would signify either (NewHope), (Round2, SIKE), (Round2) or skipping 434 | the IKE_AUX entirely. 435 | 436 | When the responder that supports the hybrid exchange receives an 437 | IKE_SA_INIT message with the AUX_EXHANGE_SUPPORTED and 438 | EXTRA_KEY_EXCHANGE_POLICY notifies, then (after processing the IKE 439 | message as normal), it scans through the policy listed within the 440 | EXTRA_KEY_EXCHANGE_POLICY Notify payload. If the responder finds a list 441 | of key exchanges that is consistent with its own policy, it includes 442 | N(AUX_EXCHANGE_SUPPORTED) and N(EXTRA_KEY_EXCHANGE_LIST) notifies, 443 | which both have 0 Protocol IDs and SPI sizes. The data for the 444 | EXTRA_KEY_EXCHANGE_LIST notify would have data specifying the list of 445 | acceptable Transform IDs as a series of 2 byte values. If the 446 | responder’s policy requires it to perform the extra key exchange, but 447 | none of the key exchange lists are acceptable, it returns an error in 448 | a notification with type NO_PROPOSAL_CHOSEN. 449 | 450 | For example, if the single transform Round2 is accepted, then the data 451 | payload will consist of: 452 |

455 | If the set Round2 and SIKE is accepted, then the data payload will 456 | consist of: 457 |

460 | If no IKE_AUX transforms is desired, then the data payload will be 461 | empty (or alternatively no such notification is included, which 462 | implies the same thing). 463 | 464 | On success, the responder will create the IKE SA and SK values based 465 | on SAi1, SAr1 and KE payloads as normal. 466 | 467 | When the initiator receives the reply IKE_SA_INIT message, it checks 468 | for the existence of the AUX_EXCHANGE_SUPPORTED and 469 | EXTRA_KEY_EXCHANGE_LIST notifies. If those notifies are not present, 470 | then the initiator treats it as if no extra key exchanges were chosen 471 | (and then can proceed by either rejecting the exchange, or proceed using 472 | the single negotiated key exchange, depending on local policy). 473 | 474 | If those notifies are present, then the responder verifies that the 475 | key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST are one of the 476 | options within its local policy; if so, it processes the IKE_SA_INIT 477 | message as normal, and then proceeds to the IKE_AUX round. 478 | 479 |

480 | One reason that the initiator may select the initial key exchange 481 | (the type 4 transform within the SAi1 payload) is not for security, 482 | but instead to simply establish keys to allow fragmentation of the 483 | IKE_AUX message. Because of this possibility, if the receiver sees 484 | a list of key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST 485 | that satisfies its policies, it SHOULD accept it (assuming that the 486 | SAi1 payload is otherwise acceptable), even if the key payload within 487 | the SAi1 is not necessary according to its policy. 488 |

489 |

490 | 491 |

501 | <-- HDR, SK {Nr2, KEr2} 502 | ]]> 503 | 504 | The initiator sends a nonce in the Ni2 payload, and the key exchange 505 | payload in the KEi2; the group id of the KEi2 payload MUST match the 506 | negotiated extra key exchange. This packet is encrypted with the 507 | current IKE SK keys. 508 | 509 | On receiving this, the responder sends a nonce in the Nr2 payload, 510 | and the key exchange payload KEr2; again, this packet is encrypted 511 | with the current IKE SA keys. 512 | 513 | Once this exchange is done, then both sides compute an updated 514 | keying material: 515 |

518 | where KE2result is the shared secret of the key exchange. Then, 519 | SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: 520 |

535 | 536 |

537 | After the IKE_AUX exchanges have completed, then the initiator and 538 | the responder will perform an IKE_AUTH exchange. This exchange is 539 | the standard IKE exchange, except that the initiator and responder 540 | signed octets are modified as described in 541 | . 542 |

543 |

544 | 545 |

In generating keying material within IKEv2, 547 | both initiator and responder negotiate up to four cryptographic 548 | algorithms in the SA payload of an IKE_SA_INIT or a CREATE_CHILD_SA 549 | exchange. One of the negotiated algorithms is a Diffie-Hellman 550 | algorithm, which is used for key exchange. This negotiation is 551 | done using the Transform Type 4 (Diffie-Hellman Group) where each 552 | Diffie-Hellman group is assigned a unique value. 553 | 554 | We expect that in the future, IANA will assign permanent values to 555 | these transforms. Until it does, we will use the following values 556 | for the below key exchanges (which will need to be specified in more 557 | detail elsewhere). Official identifiers will be maintained by IANA 558 | and updated during the NIST standardization process. 559 | 560 |

568 | 569 | 570 | Because we are using transforms in the private use space, both the 571 | initiator and responder must include a vendor id with this payload: 572 | 573 | 574 | d4 48 11 94 c0 c3 4c 9d d1 22 76 aa 9a 4e 80 d5 575 | 576 | 577 | This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange 578 | v1"). If the other side does not include this vendor id, an 579 | implementation MUST NOT process these private use transforms as 580 | listed in this draft. 581 | 582 |

583 | 584 |

585 | Most post-quantum key agreement algorithms are relatively new, and 586 | thus are not fully trusted. There are also many proposed algorithms, 587 | with different trade-offs and relying on different hard problems. The 588 | concern is that some of these hard problems may turn out to be easier 589 | to solve than anticipated (and thus the key agreement algorithm not be 590 | as secure as expected). A hybrid solution allows us to deal with this 591 | uncertainty by combining a classical key exchanges with a post-quantum 592 | one, as well as leaving open the possibility of multiple post-quantum 593 | key exchanges. 594 | 595 | The method that we use to perform hybrid key exchange also addresses 596 | the fragmentation issue. The initial IKE_INIT messages do not have any 597 | inherent fragmentation support within IKE; however that can include a 598 | relatively short KE payload (e.g. one for group 14, 19 or 31). The 599 | rest of the KE payloads are encrypted within IKE_AUX messages; because 600 | they are encrypted, the standard IKE fragmentation solution 601 | is available. 602 |

603 | 604 |

This method of 605 | performing hybrid key exchanges, by performing multiple exchanges in 606 | series, solves the issue by making the IKE SK values be a function of 607 | all the key exchanges performed. Hence, we achieve the goal of making 608 | the IKE exchange secure if any of the key exchanges are secure. 609 | 610 | 611 | 612 | This proposal allows the support of multiple post-quantum algorithms 613 | (in case we don’t have full confidence in any one); this is implemented 614 | by having the initiator list all the combinations of extra key exchanges 615 | he finds acceptable. It is not anticipated that there will be a need 616 | for a large number of different combinations of key exchanges, hence 617 | this relatively simple encoding method was selected as a reasonable 618 | compromise between simplicity and functionality. 619 | 620 | 621 | This method also allows us to fragment large post-quantum key 622 | exchanges; all the initiator needs to assure is that the initial 623 | key exchange (which has the KE payloads exchanged during IKE_SA_INIT) 624 | is small enough not to cause fragmentation. 625 | 626 |

627 | 628 |

629 | This section gives an overview on a number of alternative approaches 630 | that we have considered, but later discarded. These approaches are: 631 | 632 | 633 | Sending the classical and post-quantum key 634 | exchanges as a single transform 635 | We considered combining the various key exchanges into a single large 636 | KE payload; this effort is documented in a previous version of this 637 | draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This does allow us 638 | to cleanly apply hybrid key exchanges during the child SA; however it 639 | does add considerable complexity, and requires an independant 640 | fragmentation solution. 641 | 642 | 643 | Sending post-quantum proposals and policies in KE payload 644 | only 645 | With the objective of not introducing unnecessary notify 646 | payloads, we considered communicating the hybrid post-quantum proposal 647 | in the KE payload during the first pass of the protocol 648 | exchange. Unfortunately, this design is susceptible to the following 649 | downgrade attack. Consider the scenario where there is an MitM attacker 650 | sitting between an initiator and a responder. The initiator proposes, 651 | through SAi payload, to use a hybrid post-quantum group and as a backup 652 | a Diffie-Hellman group, and through KEi payload, the initiator proposes 653 | a list of hybrid post-quantum proposals and policies. The MitM attacker 654 | intercepts this traffic and replies with N(INVALID_KE_PAYLOAD) suggesting 655 | to downgrade to the backup Diffie-Hellman group instead. The initiator 656 | then resends the same SAi payload and the KEi payload containing the 657 | public value of the backup Diffie-Hellman group. Note that the attacker 658 | may forward the second IKE_SA_INIT message only to the responder, and 659 | therefore at this point in time, the responder will not have the 660 | information that the initiator prefers the hybrid group. Of course, 661 | it is possible for the responder to have a policy to reject an 662 | IKE_SA_INIT message that (a) offers a hybrid group but not offering 663 | the corresponding public value in the KEi payload; and (b) the 664 | responder has not specifically acknowledged that it does not 665 | supported the requested hybrid group. However, the checking of this 666 | policy introduces unnecessary protocol complexity. Therefore, in 667 | order to fully prevent any downgrade attacks, using KE payload alone 668 | is not sufficient and that the initiator MUST always indicate its 669 | preferred post-quantum proposals and policies in a notify payload 670 | in the subsequent IKE_SA_INIT messages following a 671 | N(INVALID_KE_PAYLOAD) response. 672 | 673 | New payload types to negotiate hybrid proposal and to carry post- 674 | quantum public values 675 | Semantically, it makes sense to use a new payload type, which 676 | mimics the SA payload, to carry a hybrid proposal. Likewise, another new 677 | payload type that mimics the KE payload, could be used to transport hybrid 678 | public value. Although, in theory a new payload type could be made 679 | backwards compatible by not setting its critical flag as per Section 2.5 680 | of RFC7296, we believe that it may not be that simple in practice. Since 681 | the original release of IKEv2 in RFC4306, no new payload type has ever 682 | been proposed and therefore, this creates a potential risk of having a 683 | backward compatibility issue from non-conforming RFC IKEv2 684 | implementations. Since we could not see any other compelling advantages 685 | apart from a semantic one, we use the existing transform type and 686 | notify payloads instead. In fact, as described above, we use the KE 687 | payload in the first IKE_SA_INIT request round and the notify payload 688 | to carry the post-quantum proposals and policies. We use one or more 689 | of the existing KE payloads to carry the hybrid public values. 690 | 691 | 692 | Hybrid public value payload 693 | One way to transport the negotiated hybrid public payload, which contains 694 | one classical Diffie-Hellman public value and one or more post-quantum 695 | public values, is to bundle these into a single KE payload. Alternatively, 696 | these could also be transported in a single new hybrid public value 697 | payload, but following the same reasoning as above, this may not be 698 | a good idea from a backward compatibility perspective. Using a single 699 | KE payload would require an encoding or formatting to be defined so 700 | that both peers are able to compose and extract the individual public 701 | values. However, we believe that it is cleaner to send the hybrid 702 | public values in multiple KE payloads--one for each group or 703 | algorithm. Furthermore, at this point in the protocol exchange, both 704 | peers should have indicated support of handling multiple KE payloads. 705 | 706 | 707 | Fragmentation 708 | Handling of large IKE_SA_INIT messages has been one of the most 709 | challenging tasks. A number of approaches have been considered 710 | and the two prominent ones that we have discarded are outlined as 711 | follows. 712 | 713 | The first approach was to treat the entire IKE_SA_INIT message as 714 | a stream of bytes, which we then split it into a number of 715 | fragments, each of which is wrapped onto a payload that would fit 716 | into the size of the network MTU. The payload that wraps each 717 | fragment is a new payload type and it was envisaged that this new 718 | payload type will not cause a backward compatibility issue because 719 | at this stage of the protocol, both peers should have indicated 720 | support of fragmentation in the first pass of the IKE_SA_INIT 721 | exchange. The negotiation of fragmentation is performed using a 722 | notify payload, which also defines supporting parameters such as 723 | the size of fragment in octets and the fragment identifier. The 724 | new payload that wraps each fragment of the messages in this 725 | exchange is assigned the same fragment identifier. Furthermore, it 726 | also has other parameters such as a fragment index and total 727 | number of fragments. We decided to discard this approach due to 728 | its blanket approach to fragmentation. In cases where only a few 729 | payloads need to be fragmented, we felt that this approach is 730 | overly complicated. 731 | 732 | Another idea that was discarded was fragmenting an individual 733 | payload without introducing a new payload type. The idea was to 734 | use the 9-th bit (the bit after the critical flag in the RESERVED 735 | field) in the generic payload header as a flag to mark that this 736 | payload is fragmented. As an example, if a KE payload is to be 737 | fragmented, it may look as follows. 738 | 739 | 740 | 741 | 742 | 743 |

807 | 808 |

809 | The key length of the Encryption Algorithm (Transform Type 1), the 810 | Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 811 | (Transform Type 3), all have to be of sufficient length to prevent 812 | attacks using Grover's algorithm . In order to use the 813 | extension proposed in this document, the key lengths of these 814 | transforms SHALL be at least 256 bits long in order to provide 815 | sufficient resistance to quantum attacks. Accordingly the 816 | post-quantum security level achieved is at least 128 bits. 817 | 818 | SKEYSEED is calculated from shared, KEx, using an algorithm defined 819 | in Transform Type 2. While a quantum attacker may learn the value 820 | of KEx', if this value is obtained by means of a classical key exchange, 821 | other KEx values generated by means of a quantum-resistant algorithm 822 | ensure that the final SKEYSEED is not compromised. This assumes that 823 | the algorithm defined in the Transform Type 2 is post-quantum. 824 | 825 | 826 | 827 | The main focus of this document is to prevent a passive attacker 828 | performing a "harvest and decrypt" attack. In other words, an attacker 829 | that records messages exchanges today and proceeds to decrypt them once 830 | he owns a quantum computer. This attack is prevented due to the hybrid 831 | nature of the key exchange. Other attacks involving an active attacker 832 | using a quantum-computer are not completely solved by this 833 | document. This is for two reasons. 834 | 835 | 836 | The first reason is because the authentication step remains 837 | classical. In particular, the authenticity of the SAs established 838 | under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 839 | algorithms. Whilst the pre-shared key option, provided the key is 840 | long enough, is post-quantum, the other algorithms are not. Moreover, 841 | in implementations where scalability is a requirement, the pre-shared 842 | key method may not be suitable. Quantum-safe authenticity may be 843 | provided by using a quantum-safe digital signature and several 844 | quantum-safe digital signature methods are being explored by 845 | IETF. For example, if the implementation is able to reliably 846 | track state, the hash based method, XMSS has the status of an RFC, 847 | see . Currently, quantum-safe authentication 848 | methods are not specified in this document, but are planned to be 849 | incorporated in due course. 850 | 851 | 852 | It should be noted that the purpose of post-quantum algorithms is 853 | to provide resistance to attacks mounted in the future. The current 854 | threat is that encrypted sessions are subject to eavesdropping and 855 | archived with decryption by quantum computers taking place at some 856 | point in the future. Until quantum computers become available there 857 | is no point in attacking the authenticity of a connection because 858 | there are no possibilities for exploitation. These only occur at 859 | the time of the connection, for example by mounting a MitM 860 | attack. Consequently there is not such a pressing need for 861 | quantum-safe authenticity. 862 | 863 | This draft does not attempt to address key exchanges with KE payloads 864 | longer than 64k; the current IKE payload format does not allow that as 865 | a possibility. If such huge KE payloads are required, a work around 866 | (such as making the KE payload a URL and a hash of the real payload) 867 | would be needed. At the current time, it appears likely that there 868 | will be plenty of key exchanges available that would not require such 869 | a workaround. 870 |

871 | 872 | 873 | 874 | 875 | 876 | 877 | 878 | IP Authentication Header 879 | 880 | 881 | 882 | 883 | 884 | 885 | 886 | 887 | IP Encapsulating Security Payload (ESP) 888 | 889 | 890 | 891 | 892 | 893 | 894 | 895 | &I-D.ietf-ipsecme-qr-ikev2; 896 | 897 | &I-D.smyslov-ipsecme-ikev2-aux; 898 | 899 | 900 | A Fast Quantum Mechanical Algorithm for Database Search 901 | 902 | 903 | 904 | 905 | 906 | 907 | 908 | &RFC2119; 909 | 910 | &RFC7296; 911 | 912 | &RFC7383; 913 | 914 | &RFC8229; 915 | 916 | &RFC8391; 917 | 918 | 919 | 920 |

921 | The authors would like to thanks Frederic Detienne and Olivier 922 | Pelerin for their comments and suggestions, including the idea to 923 | negotiate the post-quantum algorithms using the existing KE payload. 924 | 925 |

926 | 927 | 928 | 929 | 930 | -------------------------------------------------------------------------------- /draft-tjhai-ipsecme-hybrid-qske-ikev2-03.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ]> 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) 23 | 24 | Post-Quantum 25 |

26 | 27 | cjt@post-quantum.com 28 |

29 | 30 | 31 | 32 | Post-Quantum 33 |

34 | 35 | mt@post-quantum.com 36 |

37 | 38 | 39 | 40 | Cisco Systems 41 |

42 | 43 | grbartle@cisco.com 44 |

45 | 46 | 47 | 48 | Cisco Systems 49 |

50 | 51 | sfluhrer@cisco.com 52 |

53 | 54 | 55 | 56 | ISARA Corporation 57 |

58 | 59 | daniel.vangeest@isara.com 60 |

61 | 62 | 63 | 64 | Philips 65 |

66 | 67 | oscar.garcia-morchon@philips.com 68 |

69 | 70 | 71 | 72 | ELVIS-PLUS 73 |

74 | 75 | svan@elvis.ru 76 |

77 | 78 | 79 | 80 | Internet Engineering Task Force 81 | 82 | This document describes how to extend Internet Key Exchange Protocol 83 | Version 2 (IKEv2) so that the shared secret exchanged between peers 84 | has resistance against quantum computer attacks. The basic idea is 85 | to exchange one or more post-quantum key exchange payloads in 86 | conjunction with the existing (Elliptic Curve) Diffie-Hellman payload. 87 | 88 | 89 | 90 | 91 |

92 |

93 | Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 94 | uses the Diffie-Hellman (DH) or Elliptic Curve 95 | Diffie-Hellman (ECDH) algorithm to establish a shared secret 96 | between an initiator and a responder. The security of the DH and 97 | ECDH algorithms relies on the difficulty to solve a discrete logarithm 98 | problem in multiplicative and elliptic curve groups respectively when 99 | the order of the group parameter is large enough. While solving such 100 | a problem remains difficult with current computing power, it is 101 | believed that general purpose quantum computers will be able to solve 102 | this problem, implying that the security of IKEv2 is compromised. 103 | There are, however, a number of cryptosystems that are conjectured to 104 | be resistant against quantum computer attack. This family of 105 | cryptosystems are known as post-quantum cryptography (PQC). It is 106 | sometimes also referred to as quantum-safe cryptography (QSC) or 107 | quantum-resistant cryptography (QRC). 108 |

109 | 110 |

111 | This document describes a framework to integrate QSC for IKEv2, while 112 | maintaining backwards compatibility, to derive a set of IKE keys that 113 | have resistance to quantum computer attacks. Our framework allows the 114 | negotiation of one or more QSC algorithm to exchange data, in addition 115 | to the existing DH or ECDH key exchange data. We believe that the 116 | feature of using more than one post-quantum algorithm is important as 117 | many of these algorithms are relatively new and there may be a need to 118 | hedge the security risk with multiple key exchange data from several 119 | distinct QSC algorithms. 120 | 121 | 122 | 123 | The secrets established from each key exchange are combined in a way 124 | such that should the post-quantum secrets not be present, the derived 125 | shared secret is equivalent to that of the standard IKEv2; on the 126 | other hand, a post-quantum shared secret is obtained if both classical 127 | and post-quantum key exchange data are present. This framework also 128 | applies to key exchanges in IKE Security Associations (SAs) for 129 | Encapsulating Security Payload (ESP) or 130 | Authentication Header (AH) , i.e. Child SAs, 131 | in order to provide a stronger guarantee of forward security. 132 | 133 | 134 | Some post-quantum key exchange payloads may have size larger than 135 | the standard MTU size, and therefore there could be issues with 136 | fragmentation at IP layer. IKE does allow transmission over TCP 137 | where fragmentation is not an issue ; 138 | however, we believe that a UDP-based solution will be required 139 | too. IKE does have a mechanism to handle fragmentation within 140 | UDP , however that is only applicable to 141 | messages exchanged after the IKE_SA_INIT. To use this mechanism, 142 | we use the INTERMEDIATE exchange as outlined in 143 | . With this 144 | mechanism, we do an initial key exchange, using a smaller, possibly 145 | non-quantum resistant primitive, such as ECDH. Then, before we do 146 | the IKE_AUTH exchange, we perform one or more INTERMEDIATE exchanges, 147 | each of which includes a secondary key exchange. As the INTERMEDIATE 148 | exchange is encrypted, the IKE fragmentation protocol RFC7383 149 | can be used. The IKE SK values will be updated after each exchange, 150 | and so the final IKE SK values will depend on all the key exchanges, 151 | hence they are secure if any of the key exchanges are secure. 152 | 153 | 154 | Note that readers should consider the approach in this document as 155 | providing a long term solution in upgrading the IKEv2 protocol to 156 | support post-quantum algorithms. A short term solution to make IKEv2 157 | key exchange quantum secure is to use post-quantum pre-shared keys as 158 | discussed in . 159 |

160 | 161 |

162 | Changes in this draft in each version iterations. 163 | 164 | draft-tjhai-ipsecme-hybrid-qske-ikev2-02 165 | 166 | Use new transform types to negotiate additional key exchanges, 167 | rather than using the KE payloads of IKE SA. 168 | 169 | 170 | draft-tjhai-ipsecme-hybrid-qske-ikev2-01 171 | 172 | 173 | Use INTERMEDIATE to perform multiple key exchanges in succession. 174 | 175 | Handle fragmentation by keeping the first key exchange (a standard 176 | IKE_SA_INIT with a few extra notifies) small, and encrypting the rest 177 | of the key exchanges. 178 | 179 | Simplify the negotiation of the ‘extra’ key exchanges. 180 | 181 | 182 | draft-tjhai-ipsecme-hybrid-qske-ikev2-00 183 | 184 | 185 | We added a feature to allow more than one post-quantum key 186 | exchange algorithms to be negotiated and used to exchange a post- 187 | quantum shared secret. 188 | Instead of relying on TCP encapsulation to deal with IP level 189 | fragmentation, we introduced a new key exchange payload that can 190 | be sent as multiple fragments within IKE_SA_INIT message. 191 | 192 | 193 | 194 |

195 | 196 |

197 | The remainder of this document is organized as follows. 198 | summarizes design criteria. describes how 199 | post-quantum key exchange is performed between two IKE peers and how 200 | keying materials are derived for both SAs and child SAs. A summary of alternative 201 | approaches that have been considered, but later discarded, are described 202 | in . 203 | discusses IANA considerations for the namespaces introduced in this 204 | document, and lastly discusses security considerations. 205 | 206 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 207 | "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted 208 | as described in BCP 14 when, and only when, 209 | they appear in all capitals, as shown here. 210 | 211 |

212 |

213 | 214 |

215 | The design of the proposed post-quantum IKEv2 is driven by the 216 | following criteria: 217 | 218 | 219 | Need for post-quantum cryptography in IPsec. Quantum computers 220 | 221 | might become feasible in the next 5-10 years. If current 222 | Internet communications are monitored and recorded today (D), 223 | the communications could be decrypted as soon as a quantum- 224 | computer is available (e.g., year Q) if key negotiation only 225 | relies on non post-quantum primitives. This is a high threat 226 | for any information that must remain confidential for a long 227 | period of time T > Q-D. The need is obvious if we assume that Q 228 | is 2040, D is 2020, and T is 30 years. Such a value of T is 229 | typical in classified or healthcare data. 230 | 231 | 232 | 233 | Hybrid. Currently, there does not exist a post-quantum key 234 | 235 | exchange that is trusted at the level that ECDH is trusted 236 | against conventional (non-quantum) adversaries. A hybrid 237 | approach allows introducing promising post-quantum candidates 238 | next to well-established primitives, since the overall security 239 | is at least as strong as each individual primitive. 240 | 241 | 242 | 243 | Focus on quantum-resistant confidentiality. A passive attacker 244 | 245 | can eavesdrop on IPsec communication today and decrypt it once a 246 | quantum computer is available in the future. This is a very 247 | serious attack for which we do not have a solution. An attacker 248 | can only perform active attacks such as impersonation of the 249 | communicating peers once a quantum computer is available, 250 | sometime in the future. Thus, our design focuses on quantum- 251 | resistant confidentiality due to the urgency of this problem. 252 | This document does not address quantum-resistant authentication 253 | since it is less urgent at this stage. 254 | 255 | 256 | 257 | Limit amount of exchanged data. The protocol design should be 258 | 259 | such that the amount of exchanged data, such as public-keys, is 260 | kept as small as possible even if initiator and responder need 261 | to agree on a hybrid group or multiple public-keys need to be 262 | exchanged. 263 | 264 | 265 | 266 | Future proof. Any cryptographic algorithm could be potentially 267 | 268 | broken in the future by currently unknown or impractical 269 | attacks: quantum computers are merely the most concrete example 270 | of this. The design does not categorize algorithms as "post-quantum" 271 | or "non post-quantum" and does not create assumptions 272 | about the properties of the algorithms, meaning that if 273 | algorithms with different properties become necessary in the future, 274 | this framework can be used unchanged to facilitate migration to 275 | those algorithms. 276 | 277 | 278 | 279 | Limited amount of changes. A key goal is to limit the number of 280 | 281 | changes required when enabling a post-quantum handshake. This 282 | ensures easier and quicker adoption in existing implementations. 283 | 284 | 285 | 286 | Localized changes. Another key requirement is that changes to 287 | 288 | the protocol are limited in scope, in particular, limiting 289 | changes in the exchanged messages and in the state machine, so 290 | that they can be easily implemented. 291 | 292 | 293 | 294 | Deterministic operation. This requirement means that the hybrid 295 | 296 | post-quantum exchange, and thus, the computed key, will be based 297 | on algorithms that both client and server wish to support. 298 | 299 | 300 | 301 | Fragmentation support. Some PQC algorithms could be relatively 302 | 303 | bulky and they might require fragmentation. Thus, a design goal 304 | is the adaptation and adoption of an existing fragmentation 305 | method or the design of a new method that allows for the 306 | fragmentation of the key shares. 307 | 308 | 309 | 310 | Backwards compatibility and interoperability. This is a 311 | 312 | fundamental requirement to ensure that hybrid post-quantum IKEv2 313 | and a non-post-quantum IKEv2 implementations are interoperable. 314 | 315 | 316 | 317 | FIPS compliance. IPsec is widely used in Federal Information 318 | 319 | Systems and FIPS certification is an important requirement. 320 | However, algorithms that are believed to be post-quantum are not 321 | FIPS compliant yet. Still, the goal is that the overall hybrid 322 | post-quantum IKEv2 design can be FIPS compliant. 323 | 324 | 325 | 326 | 327 | 328 |

329 | 330 |

331 |

332 | This design assigns new group identifiers (Transform Type 4) to the 333 | various post-quantum key exchanges (which will be defined later). We 334 | specifically do not make a distinction between classical (DH and ECDH) 335 | and post-quantum key exchanges, nor post-quantum algorithms which are 336 | true key exchanges versus post-quantum algorithms that act as key 337 | transport mechanisms; all are treated equivalently by the 338 | protocol. In order to support both hybrid key exchanges (that is, 339 | relying on distinct key exchanges) and fragmentation, the proposed 340 | hybrid post-quantum IKEv2 protocol extends IKE 341 | by adding additional key exchange messages (INTERMEDIATE) between the 342 | IKE_SA_INIT and the IKE_AUTH exchanges. In order to minimize 343 | communication overhead, only the key shares that are agreed to be used 344 | are actually exchanged. In order to achieve this, the IKE_SA_INIT 345 | exchange now includes notify payloads that negotiate the extra key 346 | exchanges to be used. The initiator IKE_SA_INIT message includes a 347 | notify that lists the extra key exchange policy required by the 348 | initiator; the responder selects one of the listed policies, and 349 | includes that as a notify in the response IKE_SA_INIT message. Then, 350 | the initiator and the responder perform one (or possibly more) INTERMEDIATE 351 | exchange; each such exchange includes a KE payload for the key exchange 352 | that was negotiated. 353 | 354 | Here is an overview of the initial exchanges: 355 | 356 |

360 | 361 | <-- {INTERMEDIATE (hybrid post-quantum key exchange)} --> 362 | ... 363 | <-- {INTERMEDIATE (hybrid post-quantum key exchange)} --> 364 | 365 | <-- {IKE_AUTH} --> 366 | ]]> 367 | 368 | The extra post-quantum key exchanges can use algorithms that are 369 | currently considered to be resistant to quantum computer attacks. These 370 | algorithms are collectively referred to as post-quantum algorithms in 371 | this document. 372 | 373 | Most post-quantum key agreement algorithms are relatively new, and 374 | thus are not fully trusted. There are also many proposed algorithms, 375 | with different trade-offs and relying on different hard problems. The 376 | concern is that some of these hard problems may turn out to be easier 377 | to solve than anticipated (and thus the key agreement algorithm not be 378 | as secure as expected). A hybrid solution allows us to deal with this 379 | uncertainty by combining a classical key exchanges with a post-quantum 380 | one, as well as leaving open the possibility of multiple post-quantum 381 | key exchanges. 382 | 383 | The method that we use to perform hybrid key exchange also addresses 384 | the fragmentation issue. The initial IKE_INIT messages do not have any 385 | inherent fragmentation support within IKE; however that can include a 386 | relatively short KE payload (e.g. one for group 14, 19 or 31). The 387 | rest of the KE payloads are encrypted within INTERMEDIATE messages; because 388 | they are encrypted, the standard IKE fragmentation solution 389 | is available. 390 | 391 |

392 | 393 |

394 | In the simplest case, the initiator is happy with a single key exchange 395 | (and has no interest in supporting multiple), and he is not concerned 396 | with possible fragmentation of the IKE_SA_INIT messages (either because 397 | the key exchange he selects is small enough not to fragment, or he is 398 | confident that fragmentation will be handled either by IP fragmentation, 399 | or transport via TCP). In the following we overview the two protocol 400 | rounds involved in the hybrid post-quantum protocol. 401 | 402 | In this case, the initiator performs the IKE_SA_INIT as standard, 403 | inserting this preferred key exchange (which is possibly a post-quantum 404 | algorithm) as the listed Transform Type 4, and including the initiator 405 | KE payload. If the responder accepts the policy, he responds with an 406 | IKE_SA_INIT response, and IKE continues as usual. 407 | 408 | If the initiator desires to negotiate multiple key exchanges, or he 409 | needs IKE to handle any possible fragmentation, then he uses the protocol 410 | listed below. 411 | 412 |

413 | Multiple key exchanges are negotiated using the standard IKEv2 mechanism, via SA payload. 414 | For this purpose several new transform types, namely Additional Key Exchange 1, Additional Key Exchange 2, 415 | Additional Key Exchange 3, etc., are defined. They are collectively called Additional Key Exchanges 416 | and have slightly different semantics than existing IKEv2 transform types. 417 | They are interpreted as additional key exchanges that peers agreed to perform 418 | in a series of INTERMEDIATE exchanges. The possible transform IDs for these transform types 419 | are the same as IDs for the transform type 4 (Diffie-Hellman Group), so they all share 420 | a single IANA registry for transform IDs. 421 | 422 | Key exchange method negotiated via transform type 4 MUST always take place 423 | in the IKE_SA_INIT exchange. Additional Key Exchanges negotiated via newly 424 | defined transforms MUST take place in series of INTERMEDIATE exchanges, in an order of the values of their transform types, 425 | so that key exchange negotiated using transform type N always precedes that of 426 | transform type N + 1. Each INTERMEDIATE exchange MUST bear exactly one key exchange method. 427 | Note that with this semantics, Additional Key Exchanges transforms are not associated 428 | with any particular type of key exchange and don't have any specific per transform type transform ID IANA registry. 429 | Instead they all share a single registry for transform IDs - "Diffie-Hellman Group Transform IDs", as well as Transform Type 4. 430 | All new key exchange algorithms (both classical or quantum safe) should be added to this registry. 431 | This approach gives peers flexibility in defining the ways they want 432 | to combine different key exchange methods. 433 | 434 | When forming a proposal the initiator adds transforms for the IKE_SA_INIT exchange 435 | using transform type 4. In most cases they will contain classical key exchange methods, however 436 | it is not a requirement. Additional key exchange methods are proposed using Additional Key Exchanges 437 | transform types. All these transform types are optional, the initiator is free 438 | to select any of them for proposing additional key exchange methods. Consequently, 439 | if none of Additional Key Exchanges are included in the proposal, then this proposal 440 | indicates performing standard IKEv2, as defined in . 441 | If the initiator includes any transform of type N (where N is among Additional Key Exchanges) in the proposal, 442 | the responder MUST select one of the algorithms proposed using this type. A transform ID NONE 443 | may be added to those transform types which contain key exchange methods that the initiator believes are optional. 444 | 445 | The responder performs negotiation using standard IKEv2 procedure described in Section 3.3 of . 446 | However, for the Additional Key Exchange types the responder's choice MUST NOT contain equal transform IDs (apart from NONE), 447 | and the ID selected for Transform Type 4 MUST NOT appear in any of Additional Key Exchange transforms. 448 | In other words, all selected key exchange methods must be different. 449 | 450 |

451 | 452 |

462 | <-- HDR, SK {Nr2, KEr2} 463 | ]]> 464 | 465 | The initiator sends a nonce in the Ni2 payload, and the key exchange 466 | payload in the KEi2; the group id of the KEi2 payload MUST match the 467 | negotiated extra key exchange. This packet is encrypted with the 468 | current IKE SK keys. 469 | 470 | On receiving this, the responder sends a nonce in the Nr2 payload, 471 | and the key exchange payload KEr2; again, this packet is encrypted 472 | with the current IKE SA keys. 473 | 474 | Once this exchange is done, then both sides compute an updated 475 | keying material: 476 |

479 | where KE2result is the shared secret of the key exchange. Then, 480 | SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: 481 |

485 | 486 | Note that the negotiated transform types (the encryption type, 487 | hash type, prf type) are not modified. 488 | 489 | Both the initiator and the responder will use this updated key 490 | values for the next message. 491 | 492 |

493 | 494 |

495 | After the INTERMEDIATE exchanges have completed, then the initiator and 496 | the responder will perform an IKE_AUTH exchange. This exchange is 497 | the standard IKE exchange, except that the initiator and responder 498 | signed octets are modified as described in 499 | . 500 |

501 | 502 |

503 | The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose 504 | of creating additional Child SAs, rekeying them and rekeying IKE SA itself. 505 | When creating or rekeying Child SAs, the peers may optionally 506 | perform a Diffie-Hellmann key exchange to add a fresh entropy into the session keys, 507 | in case of IKE SA rekeying, the key exchange is mandatory. 508 | 509 | If the IKE SA was created using multiple key exchange methods, the peers 510 | may want continue using multiple key exchanges in the CREATE_CHILD_SA exchange too. 511 | If the initiator includes any Additional Key Exchanges transform in the SA payload 512 | (along with Transform Type 4) and the responder agrees to perform additional 513 | key exchanges, then the additional key exchanges are performed in a series 514 | of the INFORMATIONAL exchanges that follows the CREATE_CHILD_SA exchange 515 | in an order of the values of their transform types, so that 516 | key exchange negotiated using transform type N always precedes key exchange negotiated using 517 | transform type N + 1. Each INFORMATIONAL exchange MUST bear exactly one key exchange method. 518 | Key exchange negotiated via Transform Type 4 always takes place 519 | in the CREATE_CHILD_SA exchange, as per IKEv2 specification. 520 | 521 | Since after IKE SA is created the window size may be greater than one, and multiple 522 | concurrent exchanges may be active, it is essential to link the INFORMATIONAL exchanges together and 523 | with the CREATE_CHILD_SA exchange. A new status type notification ADDITIONAL_KEY_EXCHANGE 524 | is used for this purpose. Its Notify Message Type is <TBA by IANA>, Protocol ID and SPI Size 525 | are both set to 0. The data associated with this notification is a blob meaningful 526 | only to the responder, so that the responder can correctly link successive 527 | exchanges. For the initiator the content of this notification is an opaque blob. 528 | 529 | The responder MUST include this notification in a CREATE_CHILD_SA or 530 | INFORMATIONAL response message in case next exchange is expected, filling it with 531 | some data that would allow linking this exchange to the next one. The initiator 532 | MUST copy the received notification with its content intact into the request 533 | message of the next exchange. 534 | 535 | 536 | Below is an example of three additional key exchanges. 537 | 538 | 539 |

543 | <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 544 | N(ADDITIONAL_KEY_EXCHANGE)(link1)} 545 | 546 | HDR(INFORMATIONAL), SK {Ni2, KEi2, 547 | N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 548 | <-- HDR(INFORMATIONAL), SK {Nr2, KEr2, 549 | N(ADDITIONAL_KEY_EXCHANGE)(link2)} 550 | 551 | HDR(INFORMATIONAL), SK {Ni3, KEi3, 552 | N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 553 | <-- HDR(INFORMATIONAL), SK {Nr3, KEr3, 554 | N(ADDITIONAL_KEY_EXCHANGE)(link3)} 555 | 556 | HDR(INFORMATIONAL), SK {Ni4, KEi4, 557 | N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 558 | <-- HDR(INFORMATIONAL), SK {Nr4, KEr4} 559 | ]]> 560 | 561 | 562 |

563 |

564 |

565 | 566 |

567 | This section gives an overview on a number of alternative approaches 568 | that we have considered, but later discarded. These approaches are: 569 | 570 | 571 | Sending the classical and post-quantum key 572 | exchanges as a single transform 573 | We considered combining the various key exchanges into a single large 574 | KE payload; this effort is documented in a previous version of this 575 | draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This does allow us 576 | to cleanly apply hybrid key exchanges during the child SA; however it 577 | does add considerable complexity, and requires an independent 578 | fragmentation solution. 579 | 580 | 581 | Sending post-quantum proposals and policies in KE payload 582 | only 583 | With the objective of not introducing unnecessary notify 584 | payloads, we considered communicating the hybrid post-quantum proposal 585 | in the KE payload during the first pass of the protocol 586 | exchange. Unfortunately, this design is susceptible to the following 587 | downgrade attack. Consider the scenario where there is an MitM attacker 588 | sitting between an initiator and a responder. The initiator proposes, 589 | through SAi payload, to use a hybrid post-quantum group and as a backup 590 | a Diffie-Hellman group, and through KEi payload, the initiator proposes 591 | a list of hybrid post-quantum proposals and policies. The MitM attacker 592 | intercepts this traffic and replies with N(INVALID_KE_PAYLOAD) suggesting 593 | to downgrade to the backup Diffie-Hellman group instead. The initiator 594 | then resends the same SAi payload and the KEi payload containing the 595 | public value of the backup Diffie-Hellman group. Note that the attacker 596 | may forward the second IKE_SA_INIT message only to the responder, and 597 | therefore at this point in time, the responder will not have the 598 | information that the initiator prefers the hybrid group. Of course, 599 | it is possible for the responder to have a policy to reject an 600 | IKE_SA_INIT message that (a) offers a hybrid group but not offering 601 | the corresponding public value in the KEi payload; and (b) the 602 | responder has not specifically acknowledged that it does not 603 | supported the requested hybrid group. However, the checking of this 604 | policy introduces unnecessary protocol complexity. Therefore, in 605 | order to fully prevent any downgrade attacks, using KE payload alone 606 | is not sufficient and that the initiator MUST always indicate its 607 | preferred post-quantum proposals and policies in a notify payload 608 | in the subsequent IKE_SA_INIT messages following a 609 | N(INVALID_KE_PAYLOAD) response. 610 | 611 | New payload types to negotiate hybrid proposal and to carry post- 612 | quantum public values 613 | Semantically, it makes sense to use a new payload type, which 614 | mimics the SA payload, to carry a hybrid proposal. Likewise, another new 615 | payload type that mimics the KE payload, could be used to transport hybrid 616 | public value. Although, in theory a new payload type could be made 617 | backwards compatible by not setting its critical flag as per Section 2.5 618 | of RFC7296, we believe that it may not be that simple in practice. Since 619 | the original release of IKEv2 in RFC4306, no new payload type has ever 620 | been proposed and therefore, this creates a potential risk of having a 621 | backward compatibility issue from non-conforming RFC IKEv2 622 | implementations. Since we could not see any other compelling advantages 623 | apart from a semantic one, we use the existing transform type and 624 | notify payloads instead. In fact, as described above, we use the KE 625 | payload in the first IKE_SA_INIT request round and the notify payload 626 | to carry the post-quantum proposals and policies. We use one or more 627 | of the existing KE payloads to carry the hybrid public values. 628 | 629 | 630 | Hybrid public value payload 631 | One way to transport the negotiated hybrid public payload, which contains 632 | one classical Diffie-Hellman public value and one or more post-quantum 633 | public values, is to bundle these into a single KE payload. Alternatively, 634 | these could also be transported in a single new hybrid public value 635 | payload, but following the same reasoning as above, this may not be 636 | a good idea from a backward compatibility perspective. Using a single 637 | KE payload would require an encoding or formatting to be defined so 638 | that both peers are able to compose and extract the individual public 639 | values. However, we believe that it is cleaner to send the hybrid 640 | public values in multiple KE payloads--one for each group or 641 | algorithm. Furthermore, at this point in the protocol exchange, both 642 | peers should have indicated support of handling multiple KE payloads. 643 | 644 | 645 | Fragmentation 646 | Handling of large IKE_SA_INIT messages has been one of the most 647 | challenging tasks. A number of approaches have been considered 648 | and the two prominent ones that we have discarded are outlined as 649 | follows. 650 | 651 | The first approach was to treat the entire IKE_SA_INIT message as 652 | a stream of bytes, which we then split it into a number of 653 | fragments, each of which is wrapped onto a payload that would fit 654 | into the size of the network MTU. The payload that wraps each 655 | fragment is a new payload type and it was envisaged that this new 656 | payload type will not cause a backward compatibility issue because 657 | at this stage of the protocol, both peers should have indicated 658 | support of fragmentation in the first pass of the IKE_SA_INIT 659 | exchange. The negotiation of fragmentation is performed using a 660 | notify payload, which also defines supporting parameters such as 661 | the size of fragment in octets and the fragment identifier. The 662 | new payload that wraps each fragment of the messages in this 663 | exchange is assigned the same fragment identifier. Furthermore, it 664 | also has other parameters such as a fragment index and total 665 | number of fragments. We decided to discard this approach due to 666 | its blanket approach to fragmentation. In cases where only a few 667 | payloads need to be fragmented, we felt that this approach is 668 | overly complicated. 669 | 670 | Another idea that was discarded was fragmenting an individual 671 | payload without introducing a new payload type. The idea was to 672 | use the 9-th bit (the bit after the critical flag in the RESERVED 673 | field) in the generic payload header as a flag to mark that this 674 | payload is fragmented. As an example, if a KE payload is to be 675 | fragmented, it may look as follows. 676 | 677 | 678 | 679 | 680 | 681 |

745 | 746 |

747 | This document also adds the following Transform Types to the "Transform Type Values" registry: 748 |

749 | 760 | 761 | This document also defines a new Notify Message Types in the "Notify Message Types - Status Types" registry: 762 |

763 | ADDITIONAL_KEY_EXCHANGE 765 | ]]> 766 | 767 |

768 | 769 | 770 |

771 | The key length of the Encryption Algorithm (Transform Type 1), the 772 | Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 773 | (Transform Type 3), all have to be of sufficient length to prevent 774 | attacks using Grover's algorithm . In order to use the 775 | extension proposed in this document, the key lengths of these 776 | transforms SHALL be at least 256 bits long in order to provide 777 | sufficient resistance to quantum attacks. Accordingly the 778 | post-quantum security level achieved is at least 128 bits. 779 | 780 | SKEYSEED is calculated from shared, KEx, using an algorithm defined 781 | in Transform Type 2. While a quantum attacker may learn the value 782 | of KEx', if this value is obtained by means of a classical key exchange, 783 | other KEx values generated by means of a quantum-resistant algorithm 784 | ensure that the final SKEYSEED is not compromised. This assumes that 785 | the algorithm defined in the Transform Type 2 is post-quantum. 786 | 787 | 788 | 789 | The main focus of this document is to prevent a passive attacker 790 | performing a "harvest and decrypt" attack. In other words, an attacker 791 | that records messages exchanges today and proceeds to decrypt them once 792 | he owns a quantum computer. This attack is prevented due to the hybrid 793 | nature of the key exchange. Other attacks involving an active attacker 794 | using a quantum-computer are not completely solved by this 795 | document. This is for two reasons. 796 | 797 | 798 | The first reason is because the authentication step remains 799 | classical. In particular, the authenticity of the SAs established 800 | under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 801 | algorithms. Whilst the pre-shared key option, provided the key is 802 | long enough, is post-quantum, the other algorithms are not. Moreover, 803 | in implementations where scalability is a requirement, the pre-shared 804 | key method may not be suitable. Quantum-safe authenticity may be 805 | provided by using a quantum-safe digital signature and several 806 | quantum-safe digital signature methods are being explored by 807 | IETF. For example, if the implementation is able to reliably 808 | track state, the hash based method, XMSS has the status of an RFC, 809 | see . Currently, quantum-safe authentication 810 | methods are not specified in this document, but are planned to be 811 | incorporated in due course. 812 | 813 | 814 | It should be noted that the purpose of post-quantum algorithms is 815 | to provide resistance to attacks mounted in the future. The current 816 | threat is that encrypted sessions are subject to eavesdropping and 817 | archived with decryption by quantum computers taking place at some 818 | point in the future. Until quantum computers become available there 819 | is no point in attacking the authenticity of a connection because 820 | there are no possibilities for exploitation. These only occur at 821 | the time of the connection, for example by mounting a MitM 822 | attack. Consequently there is not such a pressing need for 823 | quantum-safe authenticity. 824 | 825 | This draft does not attempt to address key exchanges with KE payloads 826 | longer than 64k; the current IKE payload format does not allow that as 827 | a possibility. If such huge KE payloads are required, a work around 828 | (such as making the KE payload a URL and a hash of the real payload) 829 | would be needed. At the current time, it appears likely that there 830 | will be plenty of key exchanges available that would not require such 831 | a workaround. 832 |

833 | 834 | 835 | 836 | 837 | 838 | 839 | &RFC2119; 840 | 841 | &RFC8174; 842 | 843 | &RFC7296; 844 | 845 | &I-D.smyslov-ipsecme-ikev2-aux; 846 | 847 | 848 | 849 | 850 | &RFC4302; 851 | 852 | &RFC4303; 853 | 854 | &RFC7383; 855 | 856 | &RFC8229; 857 | 858 | 859 | A Fast Quantum Mechanical Algorithm for Database Search 860 | 861 | 862 | 863 | 864 | 865 | 866 | 867 | &I-D.ietf-ipsecme-qr-ikev2; 868 | 869 | &RFC8391; 870 | 871 | 872 | 873 |

874 | The authors would like to thanks Frederic Detienne and Olivier 875 | Pelerin for their comments and suggestions, including the idea to 876 | negotiate the post-quantum algorithms using the existing KE payload. 877 | 878 |

879 | 880 | 881 | 882 | 883 | -------------------------------------------------------------------------------- /draft-tjhai-ipsecme-hybrid-qske-ikev2-04.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ]> 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | Framework to Integrate Post-quantum Key Exchanges into Internet Key Exchange Protocol Version 2 (IKEv2) 23 | 24 | Post-Quantum 25 |

26 | 27 | cjt@post-quantum.com 28 |

29 | 30 | 31 | 32 | Post-Quantum 33 |

34 | 35 | mt@post-quantum.com 36 |

37 | 38 | 39 | 40 | Cisco Systems 41 |

42 | 43 | grbartle@cisco.com 44 |

45 | 46 | 47 | 48 | Cisco Systems 49 |

50 | 51 | sfluhrer@cisco.com 52 |

53 | 54 | 55 | 56 | ISARA Corporation 57 |

58 | 59 | daniel.vangeest@isara.com 60 |

61 | 62 | 63 | 64 | Philips 65 |

66 | 67 | oscar.garcia-morchon@philips.com 68 |

69 | 70 | 71 | 72 | ELVIS-PLUS 73 |

74 | 75 | svan@elvis.ru 76 |

92 |

109 | 110 |

111 | 112 | This document describes a framework to integrate QSC for IKEv2, while 113 | maintaining backwards compatibility, to derive a set of IKE keys that 114 | have resistance to quantum computer attacks. Our framework allows the 115 | negotiation of one or more QSC algorithm to exchange data, in addition 116 | to the existing DH or ECDH key exchange data. We believe that the 117 | feature of using more than one post-quantum algorithm is important as 118 | many of these algorithms are relatively new and there may be a need to 119 | hedge the security risk with multiple key exchange data from several 120 | distinct QSC algorithms. 121 | 122 | 123 | 124 | The secrets established from each key exchange are combined in a way 125 | such that should the post-quantum secrets not be present, the derived 126 | shared secret is equivalent to that of the standard IKEv2; on the 127 | other hand, a post-quantum shared secret is obtained if both classical 128 | and post-quantum key exchange data are present. This framework also 129 | applies to key exchanges in IKE Security Associations (SAs) for 130 | Encapsulating Security Payload (ESP) or 131 | Authentication Header (AH) , i.e. Child SAs, 132 | in order to provide a stronger guarantee of forward security. 133 | 134 | 135 | Some post-quantum key exchange payloads may have size larger than 136 | the standard maximum transmission unit (MTU) size, and therefore there could be issues with 137 | fragmentation at IP layer. IKE does allow transmission over TCP 138 | where fragmentation is not an issue ; 139 | however, we believe that a UDP-based solution will be required 140 | too. IKE does have a mechanism to handle fragmentation within 141 | UDP , however that is only applicable to 142 | messages exchanged after the IKE_SA_INIT. To use this mechanism, 143 | we use the IKE_INTERMEDIATE exchange as outlined in 144 | . With this 145 | mechanism, we do an initial key exchange, using a smaller, possibly 146 | non-quantum resistant primitive, such as ECDH. Then, before we do 147 | the IKE_AUTH exchange, we perform one or more IKE_INTERMEDIATE exchanges, 148 | each of which includes a secondary key exchange. As the IKE_INTERMEDIATE 149 | exchange is encrypted, the IKE fragmentation protocol RFC7383 150 | can be used. The IKE SK_* values are updated after each exchange, 151 | and so the final IKE SK_* values depend on all the key exchanges, 152 | hence they are secure if any of the key exchanges are secure. 153 | 154 | 155 | Note that readers should consider the approach in this document as 156 | providing a long term solution in upgrading the IKEv2 protocol to 157 | support post-quantum algorithms. A short term solution to make IKEv2 158 | key exchange quantum secure is to use post-quantum pre-shared keys as 159 | discussed in . 160 | 161 | Note also, that the proposed approach of performing multiple successive key exchanges 162 | in such a way that resulting session keys depend on all of them is not limited 163 | to achieving quantum resistance only. In can also be used when all 164 | the performed key exchanges are classical (EC)DH ones, but for some reasons 165 | (e.g. policy requirements) it is essential to perform multiple of them. 166 | 167 |

168 | 169 |

170 | RFC EDITOR PLEASE DELETE THIS SECTION. 171 | 172 | Changes in this draft in each version iterations. 173 | 174 | draft-tjhai-ipsecme-hybrid-qske-ikev2-04 175 | 176 | Clarification about key derivation in case of multiple key exchanges in CREATE_CHILD_SA is added. 177 | Resolving rekey collisions in case of multiple key exchanges is clarified. 178 | 179 | 180 | draft-tjhai-ipsecme-hybrid-qske-ikev2-03 181 | 182 | Using multiple key exchanges CREATE_CHILD_SA is defined. 183 | 184 | 185 | draft-tjhai-ipsecme-hybrid-qske-ikev2-02 186 | 187 | Use new transform types to negotiate additional key exchanges, 188 | rather than using the KE payloads of IKE SA. 189 | 190 | 191 | draft-tjhai-ipsecme-hybrid-qske-ikev2-01 192 | 193 | Use IKE_INTERMEDIATE to perform multiple key exchanges in succession. 194 | Handle fragmentation by keeping the first key exchange (a standard 195 | IKE_SA_INIT with a few extra notifies) small, and encrypting the rest 196 | of the key exchanges. 197 | 198 | Simplify the negotiation of the ‘extra’ key exchanges. 199 | 200 | 201 | draft-tjhai-ipsecme-hybrid-qske-ikev2-00 202 | 203 | We added a feature to allow more than one post-quantum key 204 | exchange algorithms to be negotiated and used to exchange a post- 205 | quantum shared secret. 206 | Instead of relying on TCP encapsulation to deal with IP level 207 | fragmentation, we introduced a new key exchange payload that can 208 | be sent as multiple fragments within IKE_SA_INIT message. 209 | 210 | 211 |

212 | 213 |

214 | 215 | The remainder of this document is organized as follows. 216 | summarizes design criteria. describes how 217 | post-quantum key exchange is performed between two IKE peers and how 218 | keying materials are derived for both SAs and child SAs. A summary of alternative 219 | approaches that have been considered, but later discarded, are described 220 | in . 221 | discusses IANA considerations for the namespaces introduced in this 222 | document, and lastly discusses security considerations. 223 | 224 | 225 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 226 | "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted 227 | as described in BCP 14 when, and only when, 228 | they appear in all capitals, as shown here. 229 | 230 |

231 |

232 | 233 |

338 | 339 |

340 |

341 | This design assigns new Transform Type 4 identifiers to the 342 | various post-quantum key exchanges (which will be defined later). We 343 | specifically do not make a distinction between classical (DH and ECDH) 344 | and post-quantum key exchanges, nor post-quantum algorithms which are 345 | true key exchanges versus post-quantum algorithms that act as key 346 | transport mechanisms; all are treated equivalently by the 347 | protocol. To make this more clear for implementers this document 348 | renames Transform Type 4 from "Diffie-Hellman Group Transform IDs" 349 | to "Key Exchange Method Transform IDs". 350 | 351 | 352 | In order to support both hybrid key exchanges (that is, 353 | relying on distinct key exchanges) and fragmentation, the proposed 354 | hybrid post-quantum IKEv2 protocol extends IKE 355 | by adding additional key exchange messages between the 356 | IKE_SA_INIT and the IKE_AUTH exchanges by utilizing IKE_INTERMEDIATE exchange 357 | described in . 358 | 359 | 360 | In order to minimize communication overhead, only the key shares that are agreed to be used 361 | are actually exchanged. In order to achieve this several new 362 | Transform Types are defined, each sharing possible Transform IDs 363 | with Transform Type 4. The IKE_SA_INIT message includes one or more newly defined SA transforms 364 | that lists the extra key exchange policy required by the 365 | initiator; the responder selects single transform of each type, and 366 | returns them back in the response IKE_SA_INIT message. 367 | Then, provided that additional key exchanges are negotiated the initiator and the responder 368 | perform one or more IKE_INTERMEDIATE exchanges; each such exchange includes a KE payload 369 | for one of the negotiated key exchanges. 370 | 371 | Here is an overview of the initial exchanges: 372 | 373 |

377 | 378 | <-- {IKE_INTERMEDIATE (additional key exchange)} --> 379 | 380 | ... 381 | 382 | <-- {IKE_INTERMEDIATE (additional key exchange)} --> 383 | 384 | <-- {IKE_AUTH} --> 385 | ]]> 386 | 387 | The extra post-quantum key exchanges can use algorithms that are 388 | currently considered to be resistant to quantum computer attacks. These 389 | algorithms are collectively referred to as post-quantum algorithms in 390 | this document. 391 | 392 | Most post-quantum key agreement algorithms are relatively new, and 393 | thus are not fully trusted. There are also many proposed algorithms, 394 | with different trade-offs and relying on different hard problems. The 395 | concern is that some of these hard problems may turn out to be easier 396 | to solve than anticipated (and thus the key agreement algorithm not be 397 | as secure as expected). A hybrid solution allows us to deal with this 398 | uncertainty by combining a classical key exchanges with a post-quantum 399 | one, as well as leaving open the possibility of multiple post-quantum 400 | key exchanges. 401 | 402 | The method that we use to perform hybrid key exchange also addresses 403 | the fragmentation issue. The initial IKE_INIT messages do not have any 404 | inherent fragmentation support within IKE; however that can include a 405 | relatively short KE payload (e.g. one for group 14, 19 or 31). The 406 | rest of the KE payloads are encrypted within IKE_INTERMEDIATE messages; because 407 | they are encrypted, the standard IKE fragmentation solution 408 | is available. 409 |

410 | 411 |

412 | In the simplest case, the initiator is happy with a single key exchange 413 | (and has no interest in supporting multiple), and he is not concerned 414 | with possible fragmentation of the IKE_SA_INIT messages (either because 415 | the key exchange he selects is small enough not to fragment, or he is 416 | confident that fragmentation will be handled either by IP fragmentation, 417 | or transport via TCP). In the following we overview the two protocol 418 | rounds involved in the hybrid post-quantum protocol. 419 | 420 | In this case, the initiator performs the IKE_SA_INIT as standard, 421 | inserting a preferred key exchange (which is possibly a post-quantum 422 | algorithm) as the listed Transform Type 4, and including the initiator 423 | KE payload. If the responder accepts the policy, he responds with an 424 | IKE_SA_INIT response, and IKE continues as usual. 425 | 426 | If the initiator desires to negotiate multiple key exchanges, or he 427 | needs IKE to handle any possible fragmentation, then he uses the protocol 428 | listed below. 429 | 430 |

431 | Multiple key exchanges are negotiated using the standard IKEv2 mechanism, via SA payload. 432 | For this purpose several new transform types, namely Additional Key Exchange 1, Additional Key Exchange 2, 433 | Additional Key Exchange 3, etc., are defined. They are collectively called Additional Key Exchanges 434 | and have slightly different semantics than existing IKEv2 transform types. 435 | They are interpreted as additional key exchanges that peers agreed to perform 436 | in a series of IKE_INTERMEDIATE exchanges. The possible transform IDs for these transform types 437 | are the same as IDs for the Transform Type 4, so they all share a single IANA registry for transform IDs. 438 | 439 | 440 | Key exchange method negotiated via Transform Type 4 MUST always take place 441 | in the IKE_SA_INIT exchange. Additional key exchanges negotiated via newly 442 | defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges, in an order of the values of their transform types, 443 | so that key exchange negotiated using Transform Type N always precedes that of 444 | Transform Type N + 1. Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. 445 | Note that with this semantics, Additional Key Exchanges transforms are not associated 446 | with any particular type of key exchange and don't have any specific per transform type transform IDs IANA registry. 447 | Instead they all share a single registry for transform IDs - "Key Exchange Method Transform IDs", as well as Transform Type 4. 448 | All new key exchange algorithms (both classical or quantum safe) should be added to this registry. 449 | This approach gives peers flexibility in defining the ways they want 450 | to combine different key exchange methods. 451 | 452 | 453 | When forming a proposal the initiator adds transforms for the IKE_SA_INIT exchange 454 | using Transform Type 4. In most cases they will contain classical key exchange methods, however 455 | it is not a requirement. Additional key exchange methods are proposed using Additional Key Exchanges 456 | transform types. All these transform types are optional, the initiator is free 457 | to select any of them for proposing additional key exchange methods. Consequently, 458 | if none of Additional Key Exchange transforms are included in the proposal, then this proposal 459 | indicates performing standard IKEv2, as defined in . 460 | If the initiator includes any transform of type N (where N is among Additional Key Exchanges) in the proposal, 461 | the responder MUST select one of the algorithms proposed using this type. A transform ID NONE 462 | may be added to those transform types which contain key exchange methods that the initiator believes are optional. 463 | 464 | 465 | The responder performs negotiation using standard IKEv2 procedure described in Section 3.3 of . 466 | However, for the Additional Key Exchange types the responder's choice MUST NOT contain equal transform IDs (apart from NONE), 467 | and the ID selected for Transform Type 4 MUST NOT appear in any of Additional Key Exchange transforms. 468 | In other words, all selected key exchange methods must be different. 469 | 470 |

471 | 472 |

473 | For each extra key exchange agreed to in the IKE_SA_INIT exchange, 474 | the initiator and the responder perform one or more IKE_INTERMEDIATE exchanges, as 475 | described in . 476 | 477 | These exchanges are as follows: 478 | 479 |

483 | <-- HDR, SK {Nr(n), KEr(n)} 484 | ]]> 485 | 486 | The initiator sends a nonce in the Ni(n) payload, and the key exchange 487 | payload in the KEi(n). This packet is encrypted with the current IKE SK_* keys. 488 | 489 | On receiving this, the responder sends a nonce in the Nr(n) payload, 490 | and the key exchange payload KEr(n); again, this packet is encrypted 491 | with the current IKE SA keys. 492 | 493 | The Diffie-Hellman Group Num field in the KEi(n) and KEr(n) payloads MUST match the 494 | n-th negotiated extra key exchange. Note that the negotiated transform types (the encryption type, 495 | hash type, prf type) are not modified. 496 | 497 | Once this exchange is done, then both sides compute an updated 498 | keying material: 499 | 500 |

503 | 504 | where KE(n) is the resulting shared secret of this key exchange and SK_d(n-1) is the 505 | last generated SK_d, (derived from the previous IKE_INTERMEDIATE exchange, 506 | or the IKE_SA_INIT if there haven't already been any IKE_INTERMEDIATE exchanges). 507 | Then, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: 508 | 509 |

513 | 514 | Both the initiator and the responder use this updated key 515 | values in the next exchange. 516 |

517 | 518 |

519 | After all IKE_INTERMEDIATE exchanges have completed, the initiator and 520 | the responder perform an IKE_AUTH exchange. This exchange is 521 | the standard IKE exchange, except that the initiator and responder 522 | signed octets are modified as described in 523 | . 524 | 525 | Note, that despite the fact, that a fresh pair of nonces is exchanged 526 | in each IKE_INTERMEDIATE exchange, only nonces from the IKE_SA_INIT are included 527 | in calculation of AUTH payload (see Section 2.15 of ). 528 | 529 |

530 | 531 |

532 | The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose 533 | of creating additional Child SAs, rekeying them and rekeying IKE SA itself. 534 | When creating or rekeying Child SAs, the peers may optionally 535 | perform a Diffie-Hellmann key exchange to add a fresh entropy into the session keys. 536 | In case of IKE SA rekey, the key exchange is mandatory. 537 | 538 | 539 | If the IKE SA was created using multiple key exchange methods, the peers 540 | may want continue using multiple key exchanges in the CREATE_CHILD_SA exchange too. 541 | If the initiator includes any Additional Key Exchanges transform in the SA payload 542 | (along with Transform Type 4) and the responder agrees to perform additional 543 | key exchanges, then the additional key exchanges are performed in a series 544 | of the INFORMATIONAL exchanges that follows the CREATE_CHILD_SA exchange. 545 | These key exchanges are performed in an order of the values of their transform types, so that 546 | key exchange negotiated using Transform Type N always precedes key exchange negotiated using 547 | Transform Type N + 1. Each INFORMATIONAL exchange MUST bear exactly one key exchange method. 548 | Key exchange negotiated via Transform Type 4 always takes place 549 | in the CREATE_CHILD_SA exchange, as per IKEv2 specification. 550 | 551 | 552 | Since after IKE SA is created the window size may be greater than one and multiple 553 | concurrent exchanges may be active, it is essential to link the INFORMATIONAL exchanges together and 554 | with the corresponding CREATE_CHILD_SA exchange. A new status type notification ADDITIONAL_KEY_EXCHANGE 555 | is used for this purpose. Its Notify Message Type is <TBA by IANA>, Protocol ID and SPI Size 556 | are both set to 0. The data associated with this notification is a blob meaningful 557 | only to the responder, so that the responder can correctly link successive 558 | exchanges. For the initiator the content of this notification is an opaque blob. 559 | 560 | 561 | The responder MUST include this notification in a CREATE_CHILD_SA or 562 | INFORMATIONAL response message in case next exchange is expected, filling it with 563 | some data that would allow linking this exchange to the next one. The initiator 564 | MUST copy the received notification with its content intact into the request 565 | message of the next exchange. 566 | 567 | 568 | Below is an example of three additional key exchanges. 569 | 570 | 571 |

575 | <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, 576 | N(ADDITIONAL_KEY_EXCHANGE)(link1)} 577 | 578 | HDR(INFORMATIONAL), SK {Ni2, KEi2, 579 | N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> 580 | <-- HDR(INFORMATIONAL), SK {Nr2, KEr2, 581 | N(ADDITIONAL_KEY_EXCHANGE)(link2)} 582 | 583 | HDR(INFORMATIONAL), SK {Ni3, KEi3, 584 | N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> 585 | <-- HDR(INFORMATIONAL), SK {Nr3, KEr3, 586 | N(ADDITIONAL_KEY_EXCHANGE)(link3)} 587 | 588 | HDR(INFORMATIONAL), SK {Ni4, KEi4, 589 | N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> 590 | <-- HDR(INFORMATIONAL), SK {Nr4, KEr4} 591 | ]]> 592 | 593 | It is possible that due to some unexpected events (e.g. reboot) 594 | the Initiator could forget that he/she is in the process of performing 595 | additional key exchanges and never starts next INFORMATIONAL exchanges. 596 | The Responder MUST handle this situation gracefully and delete 597 | the associated state if he/she doesn't receive the next expected 598 | INFORMATIONAL request after some reasonable period of time. 599 | 600 | 601 | If Responder receives INFORMATIONAL request containing ADDITIONAL_KEY_EXCHANGE 602 | notification and the content of this notify doesn't correspond to any active key exchange 603 | state the Responder has, he/she MUST send back a new error type notification 604 | STATE_NOT_FOUND. This is a non-fatal notification, its Notify Message Type is <TBA by IANA>, 605 | Protocol ID and SPI Size are both set to 0 and the data is empty. If Initiator receives 606 | this notification in response to INFORMATIONAL exchange performing additional 607 | key exchange, he/she MUST cancel this exchange and MUST treat the whole series 608 | of exchanges started from the CREATE_CHILD_SA exchange as failed. 609 | In most cases, the receipt of this notification is caused by premature deletion 610 | of the corresponding state on the Responder (the time period between 611 | INFORMATIONAL exchanges appeared too long from Responder's point of view, e.g. 612 | due to a temporary network failure). After receiving this notification the Initiator MAY 613 | start a new CREATE_CHILD_SA exchange (eventually followed by the INFORMATIONAL exchanges) 614 | to retry the failed attempt. If the Initiator continues to receive 615 | STATE_NOT_FOUND notifications after several retries, he/she MUST treat it 616 | as fatal error and delete IKE SA (sending DELETE payload). 617 | 618 | 619 | When rekeying IKE SA or Child SA it is possible that the peers start doing this 620 | at the same time, which is called simultaneous rekeying. Sections 2.8.1 and 2.8.2 of 621 | describes how IKEv2 handles this situation. In a nutshell 622 | IKEv2 follows the rule that if in case of simultaneous rekeying two identical new 623 | IKE SAs (or two pairs of Child SAs) are created, then one of them should be deleted. 624 | Which one is to be deleted is determined by comparing the values of four nonces, 625 | that were used in the colliding CREATE_CHILD_SA exchanges - the IKE SA (or pair of Child SAs) 626 | that was created by the exchange in which the smallest nonce was used should be deleted by 627 | the initiator of this exchange. 628 | 629 | 630 | With multiple key exchanges the SAs are not yet created once the CRETE_CHILD_SA is completed, 631 | they would be created only after the series of INFORMATIONAL exchanges is finished. 632 | For this reason if additional key exchanges were negotiated in the CREATE_CHILD_SA initiated by the losing side, 633 | there is nothing to delete and this side just stops the rekeying process - he/she MUST not initiate 634 | INFORMATIONAL exchange with next key exchange. 635 | 636 | 637 | In most cases rekey collisions are resolved in the CREATE_CHILD_SA exchange. 638 | However, a situation may occur when due to packet loss one of the peers receives CREATE_CHILD_SA message 639 | requesting rekeying SA that is already being rekeyed by this peer (i.e. the CREATE_CHILD_SA 640 | exchange initiated by this peer has been already completed and the series of INFORMATIONAL exchanges is in progress). 641 | In this case TEMPORARY_FAILURE notification MUST be sent in response to such request. 642 | 643 | 644 | If multiple key exchanges were negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are 645 | computed as follows. In case of IKE SA rekey: 646 | 647 | 648 |

652 | 653 | In case of Child SA creating or rekey: 654 | 655 | 656 |

660 | 661 | In both cases SK_d is from existing IKE SA; KE, Ni, Nr - shared key and nonces 662 | from the CREATE_CHILD_SA; KE(1)..KE(n), Ni(1)..Ni(n), Nr(1)..Nr(n) - shared keys and nonces 663 | from additional key exchanges. 664 | 665 | 666 |

667 |

668 |

669 | 670 |

671 | This document renames "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs" 672 | 673 | This document also adds the following Transform Types to the "Transform Type Values" registry: 674 |

685 | 686 | This document also defines a new Notify Message Type in the "Notify Message Types - Status Types" registry: 687 | 688 |

ADDITIONAL_KEY_EXCHANGE 690 | ]]> 691 | 692 | and a new Notify Message Type in the "Notify Message Types - Error Types" registry: 693 | 694 |

STATE_NOT_FOUND 696 | ]]> 697 |

698 | 699 |

700 | 701 | The key length of the Encryption Algorithm (Transform Type 1), the 702 | Pseudorandom Function (Transform Type 2) and the Integrity Algorithm 703 | (Transform Type 3), all have to be of sufficient length to prevent 704 | attacks using Grover's algorithm . In order to use the 705 | extension proposed in this document, the key lengths of these 706 | transforms SHALL be at least 256 bits long in order to provide 707 | sufficient resistance to quantum attacks. Accordingly the 708 | post-quantum security level achieved is at least 128 bits. 709 | 710 | SKEYSEED is calculated from shared, KEx, using an algorithm defined 711 | in Transform Type 2. While a quantum attacker may learn the value 712 | of KEx', if this value is obtained by means of a classical key exchange, 713 | other KEx values generated by means of a quantum-resistant algorithm 714 | ensure that the final SKEYSEED is not compromised. This assumes that 715 | the algorithm defined in the Transform Type 2 is post-quantum. 716 | 717 | 718 | 719 | The main focus of this document is to prevent a passive attacker 720 | performing a "harvest and decrypt" attack. In other words, an attacker 721 | that records messages exchanges today and proceeds to decrypt them once 722 | he owns a quantum computer. This attack is prevented due to the hybrid 723 | nature of the key exchange. Other attacks involving an active attacker 724 | using a quantum-computer are not completely solved by this 725 | document. This is for two reasons. 726 | 727 | 728 | The first reason is because the authentication step remains 729 | classical. In particular, the authenticity of the SAs established 730 | under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA 731 | algorithms. Whilst the pre-shared key option, provided the key is 732 | long enough, is post-quantum, the other algorithms are not. Moreover, 733 | in implementations where scalability is a requirement, the pre-shared 734 | key method may not be suitable. Quantum-safe authenticity may be 735 | provided by using a quantum-safe digital signature and several 736 | quantum-safe digital signature methods are being explored by 737 | IETF. For example, if the implementation is able to reliably 738 | track state, the hash based method, XMSS has the status of an RFC, 739 | see . Currently, quantum-safe authentication 740 | methods are not specified in this document, but are planned to be 741 | incorporated in due course. 742 | 743 | 744 | It should be noted that the purpose of post-quantum algorithms is 745 | to provide resistance to attacks mounted in the future. The current 746 | threat is that encrypted sessions are subject to eavesdropping and 747 | archived with decryption by quantum computers taking place at some 748 | point in the future. Until quantum computers become available there 749 | is no point in attacking the authenticity of a connection because 750 | there are no possibilities for exploitation. These only occur at 751 | the time of the connection, for example by mounting a MitM 752 | attack. Consequently there is not such a pressing need for 753 | quantum-safe authenticity. 754 | 755 | This draft does not attempt to address key exchanges with KE payloads 756 | longer than 64k; the current IKE payload format does not allow that as 757 | a possibility. If such huge KE payloads are required, a work around 758 | (such as making the KE payload a URL and a hash of the real payload) 759 | would be needed. At the current time, it appears likely that there 760 | will be plenty of key exchanges available that would not require such 761 | a workaround. 762 |

763 | 764 |

765 | The authors would like to thanks Frederic Detienne and Olivier 766 | Pelerin for their comments and suggestions, including the idea to 767 | negotiate the post-quantum algorithms using the existing KE payload. 768 | The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. 769 |

770 | 771 | 772 | 773 | 774 | 775 | 776 | &RFC2119; 777 | 778 | &RFC8174; 779 | 780 | &RFC7296; 781 | 782 | &I-D.ietf-ipsecme-ikev2-intermediate; 783 | 784 | 785 | 786 | 787 | &RFC4302; 788 | 789 | &RFC4303; 790 | 791 | &RFC7383; 792 | 793 | &RFC8229; 794 | 795 | 796 | A Fast Quantum Mechanical Algorithm for Database Search 797 | 798 | 799 | 800 | 801 | 802 | 803 | 804 | &I-D.ietf-ipsecme-qr-ikev2; 805 | 806 | &RFC8391; 807 | 808 | 809 | 810 |

811 | 812 | This section gives an overview on a number of alternative approaches 813 | that we have considered, but later discarded. These approaches are: 814 | 815 | 816 | Sending the classical and post-quantum key 817 | exchanges as a single transform 818 | We considered combining the various key exchanges into a single large 819 | KE payload; this effort is documented in a previous version of this 820 | draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This does allow us 821 | to cleanly apply hybrid key exchanges during the child SA; however it 822 | does add considerable complexity, and requires an independent 823 | fragmentation solution. 824 | 825 | 826 | Sending post-quantum proposals and policies in KE payload 827 | only 828 | With the objective of not introducing unnecessary notify 829 | payloads, we considered communicating the hybrid post-quantum proposal 830 | in the KE payload during the first pass of the protocol 831 | exchange. Unfortunately, this design is susceptible to the following 832 | downgrade attack. Consider the scenario where there is an MitM attacker 833 | sitting between an initiator and a responder. The initiator proposes, 834 | through SAi payload, to use a hybrid post-quantum group and as a backup 835 | a Diffie-Hellman group, and through KEi payload, the initiator proposes 836 | a list of hybrid post-quantum proposals and policies. The MitM attacker 837 | intercepts this traffic and replies with N(INVALID_KE_PAYLOAD) suggesting 838 | to downgrade to the backup Diffie-Hellman group instead. The initiator 839 | then resends the same SAi payload and the KEi payload containing the 840 | public value of the backup Diffie-Hellman group. Note that the attacker 841 | may forward the second IKE_SA_INIT message only to the responder, and 842 | therefore at this point in time, the responder will not have the 843 | information that the initiator prefers the hybrid group. Of course, 844 | it is possible for the responder to have a policy to reject an 845 | IKE_SA_INIT message that (a) offers a hybrid group but not offering 846 | the corresponding public value in the KEi payload; and (b) the 847 | responder has not specifically acknowledged that it does not 848 | supported the requested hybrid group. However, the checking of this 849 | policy introduces unnecessary protocol complexity. Therefore, in 850 | order to fully prevent any downgrade attacks, using KE payload alone 851 | is not sufficient and that the initiator MUST always indicate its 852 | preferred post-quantum proposals and policies in a notify payload 853 | in the subsequent IKE_SA_INIT messages following a 854 | N(INVALID_KE_PAYLOAD) response. 855 | 856 | New payload types to negotiate hybrid proposal and to carry post- 857 | quantum public values 858 | Semantically, it makes sense to use a new payload type, which 859 | mimics the SA payload, to carry a hybrid proposal. Likewise, another new 860 | payload type that mimics the KE payload, could be used to transport hybrid 861 | public value. Although, in theory a new payload type could be made 862 | backwards compatible by not setting its critical flag as per Section 2.5 863 | of RFC7296, we believe that it may not be that simple in practice. Since 864 | the original release of IKEv2 in RFC4306, no new payload type has ever 865 | been proposed and therefore, this creates a potential risk of having a 866 | backward compatibility issue from non-conforming RFC IKEv2 867 | implementations. Since we could not see any other compelling advantages 868 | apart from a semantic one, we use the existing transform type and 869 | notify payloads instead. In fact, as described above, we use the KE 870 | payload in the first IKE_SA_INIT request round and the notify payload 871 | to carry the post-quantum proposals and policies. We use one or more 872 | of the existing KE payloads to carry the hybrid public values. 873 | 874 | 875 | Hybrid public value payload 876 | One way to transport the negotiated hybrid public payload, which contains 877 | one classical Diffie-Hellman public value and one or more post-quantum 878 | public values, is to bundle these into a single KE payload. Alternatively, 879 | these could also be transported in a single new hybrid public value 880 | payload, but following the same reasoning as above, this may not be 881 | a good idea from a backward compatibility perspective. Using a single 882 | KE payload would require an encoding or formatting to be defined so 883 | that both peers are able to compose and extract the individual public 884 | values. However, we believe that it is cleaner to send the hybrid 885 | public values in multiple KE payloads--one for each group or 886 | algorithm. Furthermore, at this point in the protocol exchange, both 887 | peers should have indicated support of handling multiple KE payloads. 888 | 889 | 890 | Fragmentation 891 | Handling of large IKE_SA_INIT messages has been one of the most 892 | challenging tasks. A number of approaches have been considered 893 | and the two prominent ones that we have discarded are outlined as 894 | follows. 895 | 896 | The first approach was to treat the entire IKE_SA_INIT message as 897 | a stream of bytes, which we then split it into a number of 898 | fragments, each of which is wrapped onto a payload that would fit 899 | into the size of the network MTU. The payload that wraps each 900 | fragment is a new payload type and it was envisaged that this new 901 | payload type will not cause a backward compatibility issue because 902 | at this stage of the protocol, both peers should have indicated 903 | support of fragmentation in the first pass of the IKE_SA_INIT 904 | exchange. The negotiation of fragmentation is performed using a 905 | notify payload, which also defines supporting parameters such as 906 | the size of fragment in octets and the fragment identifier. The 907 | new payload that wraps each fragment of the messages in this 908 | exchange is assigned the same fragment identifier. Furthermore, it 909 | also has other parameters such as a fragment index and total 910 | number of fragments. We decided to discard this approach due to 911 | its blanket approach to fragmentation. In cases where only a few 912 | payloads need to be fragmented, we felt that this approach is 913 | overly complicated. 914 | 915 | Another idea that was discarded was fragmenting an individual 916 | payload without introducing a new payload type. The idea was to 917 | use the 9-th bit (the bit after the critical flag in the RESERVED 918 | field) in the generic payload header as a flag to mark that this 919 | payload is fragmented. As an example, if a KE payload is to be 920 | fragmented, it may look as follows. 921 | 922 | 923 | 924 | 925 | 926 |

990 | 991 | 992 | 993 | 994 | 995 | --------------------------------------------------------------------------------