forked from kimvais/ike
-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-kivinen-ipsecme-ikev2-minimal-01.html
2620 lines (1650 loc) · 108 KB
/
draft-kivinen-ipsecme-ikev2-minimal-01.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="robots" content="index,follow" />
<meta name="creator" content="rfcmarkup version 1.104" />
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
<meta name="DC.Identifier" content="urn:ietf:id:kivinen-ipsecme-ikev2-minimal" />
<meta name="DC.Description.Abstract" content="This document describes minimal version of the Internet Key Exchange" />
<meta name="DC.Creator" content="Tero Kivinen <kivinen@iki.fi>" />
<meta name="DC.Date.Issued" content="2012-10-01" />
<meta name="DC.Title" content="Minimal IKEv2" />
<link rel="icon" href="/images/id.png" type="image/png" />
<link rel="shortcut icon" href="/images/id.png" type="image/png" />
<title>draft-kivinen-ipsecme-ikev2-minimal-01 - Minimal IKEv2</title>
<style type="text/css">
body {
margin: 0px 8px;
font-size: 1em;
}
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
font-weight: bold;
line-height: 0pt;
display: inline;
white-space: pre;
font-family: monospace;
font-size: 1em;
font-weight: bold;
}
pre {
font-size: 1em;
margin-top: 0px;
margin-bottom: 0px;
}
.pre {
white-space: pre;
font-family: monospace;
}
.header{
font-weight: bold;
}
.newpage {
page-break-before: always;
}
.invisible {
text-decoration: none;
color: white;
}
a.selflink {
color: black;
text-decoration: none;
}
@media print {
body {
font-family: monospace;
font-size: 10.5pt;
}
h1, h2, h3, h4, h5, h6 {
font-size: 1em;
}
a:link, a:visited {
color: inherit;
text-decoration: none;
}
.noprint {
display: none;
}
}
@media screen {
.grey, .grey a:link, .grey a:visited {
color: #777;
}
.docinfo {
background-color: #EEE;
}
.top {
border-top: 7px solid #EEE;
}
.bgwhite { background-color: white; }
.bgred { background-color: #F44; }
.bggrey { background-color: #666; }
.bgbrown { background-color: #840; }
.bgorange { background-color: #FA0; }
.bgyellow { background-color: #EE0; }
.bgmagenta{ background-color: #F4F; }
.bgblue { background-color: #66F; }
.bgcyan { background-color: #4DD; }
.bggreen { background-color: #4F4; }
.legend { font-size: 90%; }
.cplate { font-size: 70%; border: solid grey 1px; }
}
</style>
<!--[if IE]>
<style>
body {
font-size: 13px;
margin: 10px 10px;
}
</style>
<![endif]-->
<script type="text/javascript"><!--
function addHeaderTags() {
var spans = document.getElementsByTagName("span");
for (var i=0; i < spans.length; i++) {
var elem = spans[i];
if (elem) {
var level = elem.getAttribute("class");
if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
}
}
}
}
var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </span></td></tr> </table>";
function showElem(id) {
var elem = document.getElementById(id);
elem.innerHTML = eval(id+"_html");
elem.style.visibility='visible';
}
function hideElem(id) {
var elem = document.getElementById(id);
elem.style.visibility='hidden';
elem.innerHTML = "";
}
// -->
</script>
</head>
<body onload="addHeaderTags()">
<div style="height: 13px;">
<div onmouseover="this.style.cursor='pointer';"
onclick="showElem('legend');"
onmouseout="hideElem('legend')"
style="height: 6px; position: absolute;"
class="pre noprint docinfo bgred"
title="Click for colour legend." > </div>
<div id="legend"
class="docinfo noprint pre legend"
style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; "
onmouseover="showElem('legend');"
onmouseout="hideElem('legend');">
</div>
</div>
<span class="pre noprint docinfo top">[<a href="../html/" title="Document search and retrieval page">Docs</a>] [<a href="http://tools.ietf.org/id/draft-kivinen-ipsecme-ikev2-minimal-01.txt" title="Plaintext version of this document">txt</a>|<a href="/pdf/draft-kivinen-ipsecme-ikev2-minimal-01.txt" title="PDF version of this document">pdf</a>|<a href="/id/draft-kivinen-ipsecme-ikev2-minimal-01.xml" title="XML source for this document">xml</a>] [<a href='https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-minimal' title='IESG Datatracker information for this document'>Tracker</a>] [<a href="mailto:draft-kivinen-ipsecme-ikev2-minimal@tools.ietf.org?subject=draft-kivinen-ipsecme-ikev2-minimal%20" title="Send email to the document authors">Email</a>] [<a href="/rfcdiff?difftype=--hwdiff&url2=draft-kivinen-ipsecme-ikev2-minimal-01.txt" title="Inline diff (wdiff)">Diff1</a>] [<a href="/rfcdiff?url2=draft-kivinen-ipsecme-ikev2-minimal-01.txt" title="Side-by-side diff">Diff2</a>] [<a href="/idnits?url=http://tools.ietf.org/id/draft-kivinen-ipsecme-ikev2-minimal-01.txt" title="Run an idnits check of this document">Nits</a>] </span><br />
<span class="pre noprint docinfo"> </span><br />
<span class="pre noprint docinfo">Versions: <a href="./draft-kivinen-ipsecme-ikev2-minimal-00">00</a> <a href="./draft-kivinen-ipsecme-ikev2-minimal-01">01</a> </span><br />
<span class="pre noprint docinfo"> </span><br />
<pre>
IP Security Maintenance and Extensions T. Kivinen
(ipsecme) AuthenTec
Internet-Draft October 1, 2012
Intended status: Informational
Expires: April 4, 2013
<span class="h1">Minimal IKEv2</span>
<span class="h1">draft-kivinen-ipsecme-ikev2-minimal-01.txt</span>
Abstract
This document describes minimal version of the Internet Key Exchange
version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for
performing mutual authentication and establishing and maintaining
Security Associations (SAs). IKEv2 includes several optional
features, which are not needed in minimal implementations. This
document describes what is required from the minimal implementation,
and also describes various optimizations which can be done. The
protocol described here is compliant with full IKEv2 with exception
that this document only describes shared secret authentication (IKEv2
requires support for certificate authentication in addition to shared
secret authentication).
This document does not update or modify <a href="./rfc5996">RFC 5996</a>, but provides more
compact description of the minimal version of the protocol. If this
document and <a href="./rfc5996">RFC 5996</a> conflicts then <a href="./rfc5996">RFC 5996</a> is the authoritative
description.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of <a href="./bcp78">BCP 78</a> and <a href="./bcp79">BCP 79</a>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2013.
Copyright Notice
<span class="grey">Kivinen Expires April 4, 2013 [Page 1]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-2" id="page-2" href="#page-2" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="./bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in <a href="#section-4">Section 4</a>.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
<span class="grey">Kivinen Expires April 4, 2013 [Page 2]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-3" id="page-3" href="#page-3" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1">2.1</a>. Initial Exchange . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Other Exchanges . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-2.3">2.3</a>. Generating Keying Material . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-3">3</a>. Conformance Requirements . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5">5</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6">6</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#appendix-A">Appendix A</a>. Header and Payload Formats . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#appendix-A.1">A.1</a>. The IKE Header . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#appendix-A.2">A.2</a>. Generic Payload Header . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#appendix-A.3">A.3</a>. Security Association Payload . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#appendix-A.3.1">A.3.1</a>. Proposal Substructure . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#appendix-A.3.2">A.3.2</a>. Transform Substructure . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#appendix-A.3.3">A.3.3</a>. Valid Transform Types by Protocol . . . . . . . . . . <a href="#page-27">27</a>
<a href="#appendix-A.3.4">A.3.4</a>. Transform Attributes . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#appendix-A.4">A.4</a>. Key Exchange Payload . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#appendix-A.5">A.5</a>. Identification Payloads . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#appendix-A.6">A.6</a>. Certificate Payload . . . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
<a href="#appendix-A.7">A.7</a>. Certificate Request Payload . . . . . . . . . . . . . . . <a href="#page-31">31</a>
<a href="#appendix-A.8">A.8</a>. Authentication Payload . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
<a href="#appendix-A.9">A.9</a>. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
<a href="#appendix-A.10">A.10</a>. Notify Payload . . . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
<a href="#appendix-A.10.1">A.10.1</a>. Notify Message Types . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
<a href="#appendix-A.11">A.11</a>. Traffic Selector Payload . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
<a href="#appendix-A.11.1">A.11.1</a>. Traffic Selector . . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>
<a href="#appendix-A.12">A.12</a>. Encrypted Payload . . . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
<a href="#appendix-B">Appendix B</a>. Useful Optional Features . . . . . . . . . . . . . . <a href="#page-41">41</a>
<a href="#appendix-B.1">B.1</a>. IKE SA Delete Notification . . . . . . . . . . . . . . . . <a href="#page-41">41</a>
<a href="#appendix-B.2">B.2</a>. Raw RSA keys . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-42">42</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-44">44</a>
<span class="grey">Kivinen Expires April 4, 2013 [Page 3]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-4" id="page-4" href="#page-4" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
<span class="h2"><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</span>
This document tells what minimal IKEv2 implementation could look
like. Minimal IKEv2 implementation only supports initiator end of
the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH
exchanges and does not initiate any other exchanges. It also replies
with empty (or error) message to all incoming requests.
This means that most of the optional features of IKEv2 are left out:
NAT Traversal, IKE SA rekey, Child SA Rekey, Multiple Child SAs,
Deleting Child / IKE SAs, Configuration payloads, EAP authentication,
COOKIEs etc.
Some optimizations can be done because of limited set of supported
features, and this text should not be considered for generic IKEv2
implementations (for example Message IDs can be done as specified as
implementation is only sending out IKE_SA_INIT and IKE_AUTH request,
and do not ever send any other request).
This document should be stand-alone, meaning everything needed to
implement IKEv2 is copied here except the description of the
cryptographic algorithms. The IKEv2 specification has lots of
background information and rationale which has been omitted from this
document.
Numerous additional numeric values from IANA registries have been
omitted from this document, only those which are of interest for
minimal implementation are listed in this document.
For more information check the full IKEv2 specification in <a href="./rfc5996">RFC 5996</a>
[<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>] and [<a href="#ref-IKEV2IANA">IKEV2IANA</a>].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Use Cases</span>
One use case for this kind of minimal implementation is in small
devices doing machine to machine communication. In such environments
the node initiating connections is usually very small and the other
end of the communication channel is some kind of larger device.
An example of the small initiating node could be an remote garage
door opener device. I.e. device having buttons which open and close
garage door, and which connects to the home area network server over
wireless link.
<span class="grey">Kivinen Expires April 4, 2013 [Page 4]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-5" id="page-5" href="#page-5" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
Another example of the such device is some kind of sensor device, for
example room temperature sensor, which sends periodic temperature
data to some centralized node.
Those devices are usually sleeping long times, and only wakes up
because of user interaction or periodically. The data transfer is
always initiated from the sleeping node and after they send packets
there might be ACKs or other packets coming back before they go back
to sleep. If some data needs to be transferred from server node to
the small device, it can be implemented by polling, i.e. small node
periodically polls for the server to see if it for example have some
configuration changes or similar.
<span class="grey">Kivinen Expires April 4, 2013 [Page 5]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-6" id="page-6" href="#page-6" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
<span class="h2"><a class="selflink" name="section-2" href="#section-2">2</a>. Exchanges</span>
<span class="h3"><a class="selflink" name="section-2.1" href="#section-2.1">2.1</a>. Initial Exchange</span>
All IKEv2 communications consist of pairs of messages: a request and
a response. The pair is called an "exchange", and is sometimes
called a "request/response pair". Every request requires a response.
For every pair of IKEv2 messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the
request.
IKEv2 is a reliable protocol: the initiator MUST retransmit a request
until it either receives a corresponding response or deems the IKE SA
to have failed. A retransmission from the initiator MUST be bitwise
identical to the original request. Retransmission times MUST
increase exponentially.
IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be
able to send, receive, and process IKEv2 messages that are up to 1280
octets long. An implementation MUST accept incoming requests even if
the source port is not 500, and MUST respond to the address and port
from which the request was received.
The minimal implementation of IKEv2 only uses first two exchanges
called IKE_SA_INIT and IKE_AUTH. Those are used to create the IKE SA
and the first child SA. In addition to those messages minimal IKEv2
implementation need to understand CREATE_CHILD_SA request so it can
reply with CREATE_CHILD_SA error response saying NO_ADDITIONAL_SAS to
it, and understand INFORMATIONAL request so much, it can reply with
empty INFORMATIONAL response to it. There is no requirement to be
able to respond to any other requests.
All messages following the IKE_SA_INIT exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in
the IKE_SA_INIT exchange.
Every IKEv2 message contains a Message ID as part of its fixed
header. This Message ID is used to match up requests and responses,
and to identify retransmissions of messages.
Minimal implementation need only support of being initiator, so it
does not ever need to send any other request as one IKE_SA_INIT, and
one IKE_AUTH message. As those messages have fixed Message IDs (0
and 1) it does not need to keep track of its own Message IDs for
outgoing requests after that.
<span class="grey">Kivinen Expires April 4, 2013 [Page 6]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-7" id="page-7" href="#page-7" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
Minimal implementations can also optimize Message ID handling of the
incoming requests, as they do not need to protect incoming requests
against replays. This is possible because minimal implementation
will only return error or empty notifications replies to incoming
requests. This means that any of those incoming requests do not have
any effect on the minimal implementation, thus processing them again
does not cause any harm. Because of this the minimal implementation
can always answer to request coming in, with the same Message ID than
what the request had and then forget the request/response pair
immediately. This means there is no need to keep any kind of track
of Message IDs of the incoming requests.
In the following descriptions, the payloads contained in the message
are indicated by names as listed below.
Notation Payload
-----------------------------------------
AUTH Authentication
CERTREQ Certificate Request
D Delete
HDR IKE header (not a payload)
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange
Ni, Nr Nonce
N Notify
SA Security Association
SK Encrypted and Authenticated
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
The initial exchanges are as follows:
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ]
HDR contains the Security Parameter Indexes (SPIs), version numbers,
and flags of various sorts. Each endpoint chooses one of the two
SPIs and MUST choose them so as to be unique identifiers of an IKE
SA. An SPI value of zero is special: it indicates that the remote
SPI value is not yet known by the sender.
<span class="grey">Kivinen Expires April 4, 2013 [Page 7]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-8" id="page-8" href="#page-8" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
Incoming IKEv2 packets are mapped to an IKE SA only using the
packet's SPI, not using (for example) the source IP address of the
packet.
The SAi1 payload states the cryptographic algorithms the initiator
supports for the IKE SA. The KEi and KEr payload contain Diffie-
Hellman values and Ni and Nr are the nonces. The SAr1 contains
chosen cryptographic suite from initiator's offered choices. Minimal
implementation using shared secrets will ignore the CERTREQ payload.
Minimal implementation will most likely support exactly one set of
cryptographic algorithms, meaning the SAi1 payload will be static.
It needs to check that the SAr1 received matches the proposal it
sent.
At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE SA.
SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
prf+ (K,S) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
...
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the
prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
exchange. g^ir is represented as a string of octets in big endian
order padded with zeros if necessary to make it the length of the
modulus. Ni and Nr are the nonces, stripped of any headers.
The SK_d is used for deriving new keys for the Child SAs. The SK_ai
and SK_ar are used as a key to the integrity protection algorithm for
authenticating the component messages of subsequent exchanges. The
SK_ei and SK_er are used for encrypting (and of course decrypting)
all subsequent exchanges. The SK_pi and SK_pr are used when
generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr
MUST be the preferred key length of the PRF agreed upon.
A separate SK_e and SK_a is computed for each direction. The keys
<span class="grey">Kivinen Expires April 4, 2013 [Page 8]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-9" id="page-9" href="#page-9" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
used to protect messages from the original initiator are SK_ai and
SK_ei. The keys used to protect messages in the other direction are
SK_ar and SK_er. The notation SK { ... } indicates that these
payloads are encrypted and integrity protected using that direction's
SK_e and SK_a.
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, AUTH, SAr2, TSi, TSr}
The initiator asserts its identity with the IDi payload, proves
knowledge of the secret corresponding to IDi and integrity protects
the contents of the first message using the AUTH payload. The
responder asserts its identity with the IDr payload, authenticates
its identity and protects the integrity of the second message with
the AUTH payload.
As minimal implementation usually has only one host where it
connects, and that means it has only one shared secret. This means
it does not need to care about IDr payload that much. If the other
end sends AUTH payload which initiator can verify using the shared
secret it has, then it knows the other end is the peer it was
configured to talk to.
In the IKE_AUTH initiator sends SA offer(s) in the SAi2 payload, and
the proposed Traffic Selectors for the proposed Child SA in the TSi
and TSr payloads. The responder replies with the accepted offer in
an SAr2 payload, and selected Traffic Selectors. The selected
Traffic Selectors may be a subset of what the initiator proposed.
In the minimal implementation both SA payloads and TS payloads are
going to be mostly static. The SA payload will have the SPI value
used in the ESP, but the algorithms are most likely going to be the
one and only supported set. The TS payloads on the initiator end
will most likely say from any to any, i.e. full wildcard ranges, or
from the local IP to the remote IP. In the wildcard case the server
quite often narrow the range down to the one IP address pair. Using
single IP address pair as a traffic selectors when sending IKE_AUTH
will simplify processing as then server will either accept that pair
or return error. If wildcard ranges are used, there is possibility
that server narrows the range to some other range than what was
<span class="grey">Kivinen Expires April 4, 2013 [Page 9]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-10" id="page-10" href="#page-10" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
intended.
The IKE_AUTH (and IKE_SA_INIT) responses may contain multiple status
notification payloads which can be ignored by minimal implementation.
There can also be Vendor ID, Certificate, Certificate Request or
Configuration payloads, but any payload unknown to minimal
implementation can simply be skipped over (response messages cannot
have critical unsupported payloads).
The exchange above includes N(INITIAL_CONTACT) notification in the
request as that is quite commonly sent by the minimal implementation.
It indicates to the other end that the initiator does not have any
other IKE SAs between them, and if there is any left from previous
runs they can be deleted. As minimal implementation does not delete
IKE SAs by sending IKE SA delete, this will help server to clean up
leftover state.
When using shared secret authentication, the peers are authenticated
by having each calculating a MAC over a block of data:
For the initiator:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
<ResponderSignedOctets>)
The string "Key Pad for IKEv2" is 17 ASCII characters without null
termination. The implementation can precalculate the inner prf and
only store the output of it. This is possible because minimal IKEv2
implementation usually only supports one PRF.
The initiator signs the first message (IKE_SA_INIT request), starting
with the first octet of the first SPI in the header and ending with
the last octet of the last payload in that first message. Appended
to this (for purposes of computing the signature) are the responder's
nonce Nr, and the value prf(SK_pi, IDi').
For the responder, the octets to be signed start with the first octet
of the first SPI in the header of the second message (IKE_SA_INIT
response) and end with the last octet of the last payload in that
second message. Appended to this are the initiator's nonce Ni, and
the value prf(SK_pr, IDr').
In these calculations, IDi' and IDr' are the entire ID payloads
excluding the fixed header and the Ni, and Nr are only the value, not
the payload containing it. Note that neither the nonce Ni/Nr nor the
value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted.
<span class="grey">Kivinen Expires April 4, 2013 [Page 10]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-11" id="page-11" href="#page-11" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
The initiator's signed octets can be described as:
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
The responder's signed octets can be described as:
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
RestOfRespIDPayload = IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
Note that all of the payloads inside the RestOfMessageX are included
under the signature, including any payload types not listed in this
document.
The initiator might also get unauthenticated response back having
notification payload with error code inside. As that error code will
be unauthenticated and may be faked, there is no need to do anything
for those. Minimal implementation can simply ignore those errors,
and retransmit its request until it times out and if that happens
then the IKE SA (and Child SA) creation failed.
Responder might also reply with IKE_AUTH response packet which do not
contain payloads needed to set up Child SA (SAr2, TSi and TSr), but
contains AUTH payload and an error. As minimal implementation
probably do not support multiple SAs nor sending the CREATE_CHILD_SA
exchanges the IKE SA is useless for initiator. It can delete the IKE
SA and start over from the beginning (which might fail again if this
is configuration error, or it might succeed if this was temporal
failure).
<span class="h3"><a class="selflink" name="section-2.2" href="#section-2.2">2.2</a>. Other Exchanges</span>
Minimal implementation MUST be able to reply to INFORMATIONAL request
by sending empty response back:
<span class="grey">Kivinen Expires April 4, 2013 [Page 11]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-12" id="page-12" href="#page-12" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
Initiator Responder
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: none, Message ID=m),
SK {...}
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator | Response,
Message ID=m),
SK {} -->
Minimal implementation also MUST be able to reply to incoming
CREATE_CHILD_SA requests. Typical implementation will reject the
CREATE_CHILD_SA exchanges by sending NO_ADDITIONAL_SAS error notify
back:
Initiator Responder
-------------------------------------------------------------------
<-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA,
Flags: none, Message ID=m),
SK {...}
HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA,
Flags: Initiator | Response, Message ID=m),
SK {N(NO_ADDITIONAL_SAS)} -->
Note, that INFORMATIONAL and CREATE_CHILD_SA requests might contain
unsupported critical payloads, in which case complient implementation
MUST ignore the request, and send response message back having the
UNSUPPORTED_CRITICAL_PAYLOAD notification. That notification payload
data contains one-octet payload type of the unsupported critical
payload.
<span class="h3"><a class="selflink" name="section-2.3" href="#section-2.3">2.3</a>. Generating Keying Material</span>
Keying material for Child SA created by the IKE_AUTH exchange is
generated as follows:
KEYMAT = prf+(SK_d, Ni | Nr)
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange.
A single CHILD_SA negotiation may result in multiple Security
Associations. ESP and AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them.
The keying material for each Child SA MUST be taken from the expanded
KEYMAT using the following rules:
<span class="grey">Kivinen Expires April 4, 2013 [Page 12]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-13" id="page-13" href="#page-13" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
o All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
o If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits and the integrity key (if any) MUST be
taken from the remaining bits.
Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm, or negotiated in SA
payloads.
<span class="grey">Kivinen Expires April 4, 2013 [Page 13]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-14" id="page-14" href="#page-14" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
<span class="h2"><a class="selflink" name="section-3" href="#section-3">3</a>. Conformance Requirements</span>
For an implementation to be called conforming to <a href="./rfc5996">RFC 5996</a>
specification, it MUST be possible to configure it to accept the
following:
o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN.
o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.
o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key
authentication.
This document only supports the second bullet, it does not support
PKIX certificates at all. As full <a href="./rfc5996">RFC5996</a> responders must also
support that shared key authentication, this allows minimal
implementation to be able to interoperate with all <a href="./rfc5996">RFC 5996</a> compliant
implementations.
PKIX certificates are left out from the minimal implementation as
those would add quite a lot of complexity to the implementation. The
actual code changes needed in the IKEv2 protocol are small, but the
certificate validation code would be more complex than the whole
minimal IKEv2 implementation itself. If public key based
authentication is needed for scalability reasons, then raw RSA keys
would probably be the best compromize (see <a href="#appendix-B.2">Appendix B.2</a>).
<span class="grey">Kivinen Expires April 4, 2013 [Page 14]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-15" id="page-15" href="#page-15" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
<span class="h2"><a class="selflink" name="section-4" href="#section-4">4</a>. Security Considerations</span>
As this implements same protocol as <a href="./rfc5996">RFC 5996</a> this means all security
considerations from it also apply to this document.
<span class="grey">Kivinen Expires April 4, 2013 [Page 15]</span>
</pre><!--NewPage--><pre class='newpage'><a name="page-16" id="page-16" href="#page-16" class="invisible"> </a>
<span class="grey">Internet-Draft Minimal IKEv2 October 2012</span>
<span class="h2"><a class="selflink" name="section-5" href="#section-5">5</a>. IANA Considerations</span>
There is no new IANA considerations in this document.