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
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7427 INSIDE Secure
Updates: <a href="./rfc7296">7296</a> J. Snyder
Category: Standards Track Opus One
ISSN: 2070-1721 January 2015
Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
Abstract
The Internet Key Exchange Version 2 (IKEv2) protocol has limited
support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
The current version only includes support for three Elliptic Curve
groups, and there is a fixed hash algorithm tied to each group. This
document generalizes IKEv2 signature support to allow any signature
method supported by PKIX and also adds signature hash algorithm
negotiation. This is a generic mechanism and is not limited to
ECDSA; it can also be used with other signature algorithms.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7427">http://www.rfc-editor.org/info/rfc7427</a>.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Kivinen & Snyder Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Authentication Payload . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Hash Algorithm Notification . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Selecting the Public Key Algorithm . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#appendix-A">Appendix A</a>. Commonly Used ASN.1 Objects . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.1">A.1</a>. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.1.1">A.1.1</a>. sha1WithRSAEncryption . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.1.2">A.1.2</a>. sha256WithRSAEncryption . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.1.3">A.1.3</a>. sha384WithRSAEncryption . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.1.4">A.1.4</a>. sha512WithRSAEncryption . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.2">A.2</a>. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.2.1">A.2.1</a>. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.2.2">A.2.2</a>. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.3">A.3</a>. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.3.1">A.3.1</a>. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.3.2">A.3.2</a>. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.3.3">A.3.3</a>. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.3.4">A.3.4</a>. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.4">A.4</a>. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.4.1">A.4.1</a>. RSASSA-PSS with Empty Parameters . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.4.2">A.4.2</a>. RSASSA-PSS with Default Parameters . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-A.4.3">A.4.3</a>. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-B">Appendix B</a>. IKEv2 Payload Example . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-B.1">B.1</a>. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document adds a new IKEv2 [<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>] authentication method to
support signature methods in a more general way. The current
signature-based authentication methods in IKEv2 are per algorithm,
i.e., there is one for RSA digital signatures, one for DSS digital
signatures (using SHA-1), and three for different ECDSA curves, each
tied to exactly one hash algorithm. This design is cumbersome when
more signature algorithms, hash algorithms, and elliptic curves need
to be supported:
<span class="grey">Kivinen & Snyder Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
o In IKEv2, authentication using RSA digital signatures calls for
padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS
padding method is now recommended. (See <a href="#section-5">Section 5</a> of "Additional
Algorithms and Identifiers for RSA Cryptography for use in PKIX
Profile" [<a href="./rfc4055" title=""Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC4055</a>].)
o With ECDSA and the Digital Signature Standard (DSS), there is no
way to extract the hash algorithm from the signature. Thus, for
each new hash function to be supported with ECDSA or DSA, new
authentication methods would be needed. Support for new hash
functions is particularly needed for DSS, because the current
restriction to SHA-1 limits its security, meaning there is no
point of using long keys with SHA-1.
o The tying of ECDSA authentication methods to particular elliptic
curve groups requires definition of additional methods for each
new group. The combination of new ECDSA groups and hash functions
will cause the number of required authentication methods to become
unmanageable. Furthermore, the restriction of ECDSA
authentication to a specific group is inconsistent with the
approach taken with DSS.
With the selection of SHA-3, it might be possible that a signature
method can be used with either SHA-3 or SHA-2. This means that a new
mechanism for negotiating the hash algorithm for a signature
algorithm is needed.
This document specifies two things:
1. A new authentication method that includes enough information
inside the Authentication payload data so the signature hash
algorithm can be extracted (see <a href="#section-3">Section 3</a>).
2. A method to indicate supported signature hash algorithms (see
<a href="#section-4">Section 4</a>). This allows the peer to know which hash algorithms
are supported by the other end and use one of them (provided one
is allowed by policy). There is no requirement to actually
negotiate one common hash algorithm, as different hash algorithms
can be used in different directions if needed.
The new digital signature method is flexible enough to include all
current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add
new methods (ECGDSA, ElGamal, etc.) in the future. To support this
flexibility, the signature algorithm is specified in the same way
that PKIX [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] specifies the signature of the Digital
Certificate, by placing a simple ASN.1 object before the actual
signature data. This ASN.1 object contains an OID specifying the
algorithm and associated parameters. When an IKEv2 implementation
<span class="grey">Kivinen & Snyder Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
supports a fixed set of signature methods with commonly used
parameters, it is acceptable for the implementation to treat the
ASN.1 object as a binary blob that can be compared against the fixed
set of known values. IKEv2 implementations can also parse the ASN.1
and extract the signature algorithm and associated parameters.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Authentication Payload</span>
This document specifies a new "Digital Signature" authentication
method. This method can be used with any type of signature. As the
authentication methods are not negotiated in IKEv2, the peer is only
allowed to use this authentication method if the Notify payload of
type SIGNATURE_HASH_ALGORITHMS has been sent and received by each
peer.
In this authentication method, the Authentication Data field inside
the Authentication payload does not just include the signature value,
as do other existing IKEv2 Authentication payloads. Instead, the
signature value is prefixed with an ASN.1 object indicating the
algorithm used to generate the signature. The ASN.1 object contains
the algorithm identification OID, which identifies both the signature
algorithm and the hash used when calculating the signature. In
addition to the OID, the ASN.1 object can contain optional parameters
that might be needed for algorithms such as RSASSA-PSS (see
<a href="./rfc3447#section-8.1">Section 8.1 of [RFC3447]</a>).
To make implementations easier, the ASN.1 object is prefixed by the
8-bit length field. This length field allows simple implementations
to know the length of the ASN.1 object without the need to parse it,
so they can use it as a binary blob to be compared against known
signature algorithm ASN.1 objects. Thus, simple implementations may
not need to be able to parse or generate ASN.1 objects. See
<a href="#appendix-A">Appendix A</a> for commonly used ASN.1 objects.
The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier
of PKIX (see <a href="./rfc5280#section-4.1.1.2">Section 4.1.1.2 of [RFC5280]</a>), encoded using
distinguished encoding rules (DER) [<a href="#ref-CCITT.X690.2002">CCITT.X690.2002</a>]. The algorithm
OID inside the ASN.1 specifies the signature algorithm and the hash
function, both of which are needed for signature verification.
Currently, only the RSASSA-PSS signature algorithm uses the optional
parameters. For other signature algorithms, the parameters are
<span class="grey">Kivinen & Snyder Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
either NULL or missing. Note that for some algorithms there are two
possible ASN.1 encodings, one with optional parameters included but
set to NULL and the other where the optional parameters are omitted.
These dual encodings exist because of the way those algorithms are
specified. When encoding the ASN.1, implementations SHOULD use the
preferred format called for by the algorithm specification. If the
algorithm specification says "preferredPresent", then the parameters
object needs to be present, although it will be NULL if no parameters
are specified. If the algorithm specification says
"preferredAbsent", then the entire optional parameters object is
missing.
The Authentication payload is defined in IKEv2 as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Authentication Payload Format
o Auth Method (1 octet) - Specifies the method of authentication
used.
Mechanism Value
-----------------------------------------------------------------
Digital Signature 14
Computed as specified in <a href="./rfc7296#section-2.15">Section 2.15 of [RFC7296]</a> using a private
key associated with the public key sent in the Certificate payload
and using one of the hash algorithms sent by the other end in the
Notify payload of type SIGNATURE_HASH_ALGORITHMS. If both ends
send and receive SIGNATURE_HASH_ALGORITHMS Notify payloads, and
signature authentication is to be used, then the authentication
method specified in this Authentication payload MUST be used. The
format of the Authentication Data field is different from other
Authentication methods and is specified below.
o Authentication Data (variable length) - See <a href="./rfc7296#section-2.15">Section 2.15 of
[RFC7296]</a>. For "Digital Signature" format, the Authentication
Data is formatted as follows:
<span class="grey">Kivinen & Snyder Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AlgorithmIdentifier ASN.1 object continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Authentication Data Format
* ASN.1 Length (1 octet) - This field contains the length of the
ASN.1-encoded AlgorithmIdentifier object.
* Algorithm Identifier (variable length) - This field contains
the AlgorithmIdentifier ASN.1 object.
* Signature Value (variable length) - This field contains the
actual signature value.
There is no padding between the ASN.1 object and the signature
value. For hash truncation, the method specified in ANSI
X9.62:2005 [<a href="#ref-X9.62" title=""Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>] MUST be used.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Hash Algorithm Notification</span>
The supported hash algorithms that can be used for the signature
algorithms are indicated with a Notify payload of type
SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange.
This notification also implicitly indicates support of the new
"Digital Signature" algorithm method, as well as the list of hash
functions supported by the sending peer.
Both ends send their list of supported hash algorithms. When
calculating the digital signature, a peer MUST pick one algorithm
sent by the other peer. Note that different algorithms can be used
in different directions. The algorithm OID indicating the selected
hash algorithm (and signature algorithm) used when calculating the
signature is sent inside the Authentication Data field of the
Authentication payload (with Auth Method of "Digital Signature" as
defined above).
<span class="grey">Kivinen & Snyder Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Notify Payload Format
The Notify payload format is defined in <a href="./rfc7296#section-3.10">Section 3.10 of [RFC7296]</a>.
When a Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the
Protocol ID field is set to 0, the SPI Size is set to 0, and the
Notify Message Type is set to 16431.
The Notification Data field contains the list of 16-bit hash
algorithm identifiers from the Hash Algorithm Identifiers of IANA's
"Internet Key Exchange Version 2 (IKEv2) Parameters" registry. There
is no padding between the hash algorithm identifiers.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Selecting the Public Key Algorithm</span>
This specification does not provide a way for the peers to indicate
the public/private key pair types they have. This raises the
question of how the responder selects a public/private key pair type
that the initiator supports. This information can be found by
several methods.
One method to signal the key the initiator wants the responder to use
is to indicate that in the IDr (Identification - Responder) payload
of the IKE_AUTH request sent by the initiator. In this case, the
initiator indicates that it wants the responder to use a particular
public/private key pair by sending an IDr payload that indicates that
information. In this case, the responder has different identities
configured, with each of those identities associated to a public/
private key or key type.
Another method to ascertain the key the initiator wants the responder
to use is through a Certificate Request payload sent by the
initiator. For example, the initiator could indicate in the
<span class="grey">Kivinen & Snyder Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
Certificate Request payload that it trusts a certificate authority
certificate signed by an ECDSA key. This indication implies that the
initiator can process ECDSA signatures, which means that the
responder can safely use ECDSA keys when authenticating.
A third method is for the responder to check the key type used by the
initiator and use the same key type that the initiator used. This
method does not work if the initiator is using shared secret or
Extensible Authentication Protocol (EAP) authentication (i.e., is not
using public keys). If the initiator is using public key
authentication, this method is the best way for the responder to
ascertain the type of key the initiator supports.
If the initiator uses a public key type that the responder does not
support, the responder replies with a Notify message with error type
AUTHENTICATION_FAILED. If the initiator has multiple different keys,
it may try a different key (and perhaps a different key type) until
it finds a key that the other end accepts. The initiator can also
use the Certificate Request payload sent by the responder to help
decide which public key should be tried. In normal cases, when the
initiator has multiple public keys, out-of-band configuration is used
to select a public key for each connection.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Tables 2 and 3 of the "Recommendations for Key Management"
[<a href="#ref-NIST800-57">NIST800-57</a>] give recommendations for how to select suitable hash
functions for the signature.
This new digital signature method does not tie the Elliptic Curve to
a specific hash function, which was done in the old IKEv2 ECDSA
methods. This means it is possible to mix different security levels.
For example, it is possible to use a 512-bit Elliptic Curve with
SHA1. This means that the security of the authentication method is
the security of the weakest component (signature algorithm, hash
algorithm, or curve). This complicates the security analysis of the
system.
IKEv2 peers have a series of policy databases (see <a href="./rfc4301#section-4.4">Section 4.4 of
[RFC4301]</a>) that define which security algorithms and methods should
be used during establishment of security associations. To help end
users select the desired security levels for communications protected
by IPsec, implementers may wish to provide a mechanism in the IKE
policy databases to limit the mixing of security levels or to
restrict combinations of protocols.
Security downgrade attacks, where more secure methods are deleted or
modified from a payload by a man-in-the-middle to force lower levels
<span class="grey">Kivinen & Snyder Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
of security, are not a significant concern in IKEv2 Authentication
payloads, as discussed in this RFC. This is because a modified AUTH
payload will be detected when the peer computes a signature over the
IKE messages.
One specific class of downgrade attacks requires selection of
catastrophically weak ciphers. In this type of attack, the man-in-
the-middle attacker is able to "break" the cryptography in real time.
This type of downgrade attack should be blocked by policy regarding
cipher algorithm selection, as discussed above.
The hash algorithm registry does not include MD5 as a supported hash
algorithm, as it is not considered safe enough for signature use
[<a href="#ref-WY05" title=""How to break MD5 and other hash functions"">WY05</a>].
The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known
security vulnerabilities [<a href="#ref-KA08" title=""Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures"">KA08</a>] [<a href="#ref-ME01" title=""Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature"">ME01</a>] and does not allow using newer
padding methods such as RSASSA-PSS. The new method described in this
RFC allows the use of other padding methods.
The current IKEv2 protocol only allows use of normal DSA with SHA-1,
which means the security of the authentication is limited to the
security of SHA-1. This new method allows using longer keys and
longer hashes with DSA.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document creates a new IANA registry for IKEv2 Hash Algorithms.
Changes and additions to this registry are by Expert Review
[<a href="./rfc5226" title="">RFC5226</a>].
The initial values of this registry are:
Hash Algorithm Value
-------------- -----
RESERVED 0
SHA1 1
SHA2-256 2
SHA2-384 3
SHA2-512 4
MD5 is not included in the hash algorithm list, as it is not
considered safe enough for signature hash uses.
Values 5-1023 are Unassigned. Values 1024-65535 are reserved for
Private Use among mutually consenting parties.
<span class="grey">Kivinen & Snyder Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
This specification also adds a new value for
SIGNATURE_HASH_ALGORITHMS (16431) to the "IKEv2 Notify Message Types
- Status Types" registry and adds a new value for Digital Signature
(14) to the "IKEv2 Authentication Method" registry.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008,
<<a href="http://www.rfc-editor.org/info/rfc5280">http://www.rfc-editor.org/info/rfc5280</a>>.
[<a id="ref-RFC7296">RFC7296</a>] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", <a href="./rfc7296">RFC 7296</a>, October 2014,
<<a href="http://www.rfc-editor.org/info/rfc7296">http://www.rfc-editor.org/info/rfc7296</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-CCITT.X690.2002">CCITT.X690.2002</a>]
International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002.
[<a id="ref-KA08">KA08</a>] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
"Variants of Bleichenbacher's Low-Exponent Attack on
PKCS#1 RSA Signatures", Proceedings of Sicherheit 2008,
pp.97-109, 2008.
[<a id="ref-ME01">ME01</a>] Menezes, A., "Evaluation of Security Level of
Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December
2001.
[<a id="ref-NIST800-57">NIST800-57</a>]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management - Part 1: General
(Revised)", NIST Special Publication 800-57, March 2007.
<span class="grey">Kivinen & Snyder Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
[<a id="ref-RFC3279">RFC3279</a>] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", <a href="./rfc3279">RFC 3279</a>, April 2002,
<<a href="http://www.rfc-editor.org/info/rfc3279">http://www.rfc-editor.org/info/rfc3279</a>>.
[<a id="ref-RFC3447">RFC3447</a>] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", <a href="./rfc3447">RFC 3447</a>, February 2003,
<<a href="http://www.rfc-editor.org/info/rfc3447">http://www.rfc-editor.org/info/rfc3447</a>>.
[<a id="ref-RFC4055">RFC4055</a>] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", <a href="./rfc4055">RFC 4055</a>,
June 2005, <<a href="http://www.rfc-editor.org/info/rfc4055">http://www.rfc-editor.org/info/rfc4055</a>>.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005,
<<a href="http://www.rfc-editor.org/info/rfc4301">http://www.rfc-editor.org/info/rfc4301</a>>.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs)", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008, <<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>>.
[<a id="ref-RFC5480">RFC5480</a>] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", <a href="./rfc5480">RFC 5480</a>, March 2009,
<<a href="http://www.rfc-editor.org/info/rfc5480">http://www.rfc-editor.org/info/rfc5480</a>>.
[<a id="ref-RFC5758">RFC5758</a>] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA",
<a href="./rfc5758">RFC 5758</a>, January 2010,
<<a href="http://www.rfc-editor.org/info/rfc5758">http://www.rfc-editor.org/info/rfc5758</a>>.
[<a id="ref-RFC5912">RFC5912</a>] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", <a href="./rfc5912">RFC 5912</a>,
June 2010, <<a href="http://www.rfc-editor.org/info/rfc5912">http://www.rfc-editor.org/info/rfc5912</a>>.
[<a id="ref-WY05">WY05</a>] Wang, X. and H. Yu, "How to break MD5 and other hash
functions", Proceedings of EuroCrypt 2005, Lecture Notes
in Computer Science Vol. 3494, 2005.
[<a id="ref-X9.62">X9.62</a>] American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI
X9.62, November 2005.
<span class="grey">Kivinen & Snyder Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Commonly Used ASN.1 Objects</span>
This section lists commonly used ASN.1 objects in binary form. This
section is not normative, and these values should only be used as
examples. If the ASN.1 object listed in <a href="#appendix-A">Appendix A</a> and the ASN.1
object specified by the algorithm differ, then the algorithm
specification must be used. These values are taken from "New ASN.1
Modules for the Public Key Infrastructure Using X.509 (PKIX)"
[<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>].
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. PKCS#1 1.5 RSA Encryption</span>
The algorithm identifiers here include several different ASN.1
objects with different hash algorithms. This document only includes
the commonly used ones, i.e., the ones using SHA-1 or SHA-2 as the
hash function. Some other algorithms (such as MD2 and MD5) are not
safe enough to be used as signature hash algorithms and are omitted.
The IANA registry does not have code points for these other
algorithms with RSA Encryption. Note that there are no optional
parameters in any of these algorithm identifiers, but all included
here need NULL optional parameters present in the ASN.1.
See "Algorithms and Identifiers for PKIX Profile" [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>] and
"Additional Algorithms and Identifiers for RSA Cryptography for use
in the Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile" [<a href="./rfc4055" title=""Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC4055</a>] for more
information.
<span class="h4"><a class="selflink" id="appendix-A.1.1" href="#appendix-A.1.1">A.1.1</a>. sha1WithRSAEncryption</span>
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
Parameters are required, and they must be NULL.
Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0505 00
<span class="h4"><a class="selflink" id="appendix-A.1.2" href="#appendix-A.1.2">A.1.2</a>. sha256WithRSAEncryption</span>
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
Parameters are required, and they must be NULL.
Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0b05 00
<span class="grey">Kivinen & Snyder Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
<span class="h4"><a class="selflink" id="appendix-A.1.3" href="#appendix-A.1.3">A.1.3</a>. sha384WithRSAEncryption</span>
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
Parameters are required, and they must be NULL.
Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0c05 00
<span class="h4"><a class="selflink" id="appendix-A.1.4" href="#appendix-A.1.4">A.1.4</a>. sha512WithRSAEncryption</span>
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
Parameters are required, and they must be NULL.
Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. DSA</span>
With DSA algorithms, optional parameters are always omitted. Only
algorithm combinations for DSA that are listed in the IANA registry
are included.
See "Algorithms and Identifiers for PKIX Profile" [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>] and "PKIX
Additional Algorithms and Identifiers for DSA and ECDSA" [<a href="./rfc5758" title=""Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA"">RFC5758</a>]
for more information.
<span class="h4"><a class="selflink" id="appendix-A.2.1" href="#appendix-A.2.1">A.2.1</a>. dsa-with-sha1</span>
dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9algorithm(4) 3 }
Parameters are absent.
Name = dsa-with-sha1, oid = 1.2.840.10040.4.3
Length = 11
0000: 3009 0607 2a86 48ce 3804 03
<span class="grey">Kivinen & Snyder Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
<span class="h4"><a class="selflink" id="appendix-A.2.2" href="#appendix-A.2.2">A.2.2</a>. dsa-with-sha256</span>
dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }
Parameters are absent.
Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2
Length = 13
0000: 300b 0609 6086 4801 6503 0403 02
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. ECDSA</span>
With ECDSA algorithms, the optional parameters are always omitted.
Only algorithm combinations for the ECDSA listed in the IANA registry
are included.
See "Elliptic Curve Cryptography Subject Public Key Information"
[<a href="./rfc5480" title=""Elliptic Curve Cryptography Subject Public Key Information"">RFC5480</a>], "Algorithms and Identifiers for PKIX Profile" [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>],
and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA"
[<a href="./rfc5758" title=""Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA"">RFC5758</a>] for more information.
<span class="h4"><a class="selflink" id="appendix-A.3.1" href="#appendix-A.3.1">A.3.1</a>. ecdsa-with-sha1</span>
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) 1 }
Parameters are absent.
Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1
Length = 11
0000: 3009 0607 2a86 48ce 3d04 01
<span class="h4"><a class="selflink" id="appendix-A.3.2" href="#appendix-A.3.2">A.3.2</a>. ecdsa-with-sha256</span>
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
Parameters are absent.
Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2
Length = 12
0000: 300a 0608 2a86 48ce 3d04 0302
<span class="grey">Kivinen & Snyder Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
<span class="h4"><a class="selflink" id="appendix-A.3.3" href="#appendix-A.3.3">A.3.3</a>. ecdsa-with-sha384</span>
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
Parameters are absent.
Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3
Length = 12
0000: 300a 0608 2a86 48ce 3d04 0303
<span class="h4"><a class="selflink" id="appendix-A.3.4" href="#appendix-A.3.4">A.3.4</a>. ecdsa-with-sha512</span>
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
Parameters are absent.
Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4
Length = 12
0000: 300a 0608 2a86 48ce 3d04 0304
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. RSASSA-PSS</span>
With RSASSA-PSS, the algorithm object identifier must always be
id-RSASSA-PSS, and the hash function and padding parameters are
conveyed in the parameters (which are not optional in this case).
See Additional RSA Algorithms and Identifiers [<a href="./rfc4055" title=""Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC4055</a>] for more
information.
<span class="h4"><a class="selflink" id="appendix-A.4.1" href="#appendix-A.4.1">A.4.1</a>. RSASSA-PSS with Empty Parameters</span>
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Parameters are empty, but the ASN.1 part of the sequence must be
present. This means default parameters are used.
0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE
Length = 15
0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
<span class="grey">Kivinen & Snyder Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
<span class="h4"><a class="selflink" id="appendix-A.4.2" href="#appendix-A.4.2">A.4.2</a>. RSASSA-PSS with Default Parameters</span>
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Here the parameters are present and contain the default parameters,
i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1,
saltLength of 20, and trailerField of 1.
0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE
000f : CONTEXT 0
0011 : SEQUENCE
0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26)
001a : NULL
001c : CONTEXT 1
001e : SEQUENCE
0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
002b : SEQUENCE
002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26)
0034 : NULL
0036 : CONTEXT 2
0038 : INTEGER 0x14 (5 bits)
003b : CONTEXT 3
003d : INTEGER 0x1 (1 bits)
Name = RSASSA-PSS with default parameters,
oid = 1.2.840.113549.1.1.10
Length = 64
0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
<span class="grey">Kivinen & Snyder Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
<span class="h4"><a class="selflink" id="appendix-A.4.3" href="#appendix-A.4.3">A.4.3</a>. RSASSA-PSS with SHA-256</span>
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Here the parameters are present and contain hashAlgorithm of SHA-256,
maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1.
0000 : SEQUENCE
0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10)
000d : SEQUENCE
000f : CONTEXT 0
0011 : SEQUENCE
0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
001e : NULL
0020 : CONTEXT 1
0022 : SEQUENCE
0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8
002f : SEQUENCE
0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
003c : NULL
003e : CONTEXT 2
0040 : INTEGER 0x20 (6 bits)
0043 : CONTEXT 3
0045 : INTEGER 0x1 (1 bits)
Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
Length = 72
0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
0030: 0d06 0960 8648 0165 0304 0201 0500 a203
0040: 0201 20a3 0302 0101
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. IKEv2 Payload Example</span>
<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>. sha1WithRSAEncryption</span>
The IKEv2 AUTH payload would start like this:
00000000: NN00 00LL 0e00 0000 0f30 0d06 092a 8648
00000010: 86f7 0d01 0105 0500 ....
Where the NN will be the next payload type (i.e., the value depends
on the next payload after this Authentication payload), the LL will
be the length of this payload, and after the sha1WithRSAEncryption
ASN.1 block (15 bytes) there will be the actual signature, which is
omitted here.
<span class="grey">Kivinen & Snyder Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7427">RFC 7427</a> Signature Authentication in IKEv2 January 2015</span>
Acknowledgements
Most of this work was based on the work done in the IPsecME design
team for the ECDSA. The design team members were: Dan Harkins,
Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
Authors' Addresses
Tero Kivinen
INSIDE Secure
Eerikinkatu 28
Helsinki FI-00180
Finland
EMail: kivinen@iki.fi
Joel Snyder
Opus One
1404 East Lind Road
Tucson, AZ 85719
Phone: +1 520 324 0494
EMail: jms@opus1.com
Kivinen & Snyder Standards Track [Page 18]
</pre>
|
