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
|
<pre>Internet Engineering Task Force (IETF) Y. Oiwa
Request for Comments: 8121 H. Watanabe
Category: Experimental H. Takagi
ISSN: 2070-1721 ITRI, AIST
K. Maeda
Individual Contributor
T. Hayashi
Lepidum
Y. Ioku
Individual Contributor
April 2017
<span class="h1">Mutual Authentication Protocol for HTTP: Cryptographic Algorithms</span>
<span class="h1">Based on the Key Agreement Mechanism 3 (KAM3)</span>
Abstract
This document specifies cryptographic algorithms for use with the
Mutual user authentication method for the Hypertext Transfer Protocol
(HTTP).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. 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). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see <a href="./rfc7841#section-2">Section 2 of RFC 7841</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/rfc8121">http://www.rfc-editor.org/info/rfc8121</a>.
<span class="grey">Oiwa, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
Copyright Notice
Copyright (c) 2017 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Cryptographic Overview (Non-normative) ..........................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Authentication Algorithms .......................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Support Functions and Notations ............................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Functions for Discrete-Logarithm Settings ..................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Functions for Elliptic-Curve Settings ......................<a href="#page-7">7</a>
<a href="#section-4">4</a>. IANA Considerations .............................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. General Implementation Considerations ......................<a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Cryptographic Assumptions and Considerations ..............<a href="#page-10">10</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-11">11</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. (Informative) Group Parameters for Algorithms Based
on the Discrete Logarithm .............................<a href="#page-13">13</a>
<a href="#appendix-B">Appendix B</a>. (Informative) Derived Numerical Values ................<a href="#page-16">16</a>
Authors' Addresses ................................................<a href="#page-17">17</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies algorithms for use with the Mutual
authentication protocol for the Hypertext Transfer Protocol (HTTP)
[<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>] (hereafter referred to as the "core specification"). The
algorithms are based on augmented password-based authenticated key
exchange (augmented PAKE) techniques. In particular, it uses one of
three key exchange algorithms defined in ISO 11770-4 ("Information
technology - Security techniques - Key management - Part 4:
Mechanisms based on weak secrets") [<a href="#ref-ISO.11770-4.2006">ISO.11770-4.2006</a>] as its basis.
<span class="grey">Oiwa, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
To briefly summarize, the Mutual authentication protocol exchanges
four values -- K_c1, K_s1, VK_c, and VK_s -- to perform authenticated
key exchanges, using the password-derived secret pi and its
"augmented version" J(pi). This document defines the set of
functions K_c1, K_s1, and J for a specific algorithm family.
Please note that from the point of view of literature related to
cryptography, the original functionality of augmented PAKE is
separated into the functions K_c1 and K_s1 as defined in this
document, and the functions VK_c and VK_s, which are defined in
<a href="./rfc8120#section-12.2">Section 12.2 of [RFC8120]</a> as "default functions". For the purpose of
security analysis, please also refer to these functions.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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>].
The term "natural numbers" refers to non-negative integers (including
zero) throughout this document.
This document treats both the input (domain) and the output
(codomain) of hash functions as octet strings. When a natural-number
output of hash function H is required, it will be notated, for
example, as INT(H(s)).
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Cryptographic Overview (Non-normative)</span>
The cryptographic primitive used in this algorithm specification is
based on a variant of augmented PAKE called "APKAS-AMP" (augmented
password-authenticated key agreement scheme, version AMP), proposed
by T. Kwon and originally submitted to [<a href="#ref-IEEE-1363.2_2008">IEEE-1363.2_2008</a>]. The
general flow of the successful exchange is shown below for
informative purposes only. The multiplicative notations are used for
group operators, and all modulus operations for finite groups (mod q
and mod r) are omitted.
<span class="grey">Oiwa, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
C: S_c1 = random
C: K_c1 = g^(S_c1)
----- ID, K_c1 ----->
C: t_1 = H1(K_c1) S: t_1 = H1(K_c1)
S: fetch J = g^pi by ID
S: S_s1 = random
S: K_s1 = (J * K_c1^(t_1))^(S_s1)
<----- K_s1 -----
C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1)
C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi))
S: z' = (K_c1 * g^(t_2))^(S_s1)
(assumption at this point: z = z' if authentication succeeded)
C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z')
----- VK_c ------->
S: assert(VK_c = VK_c')
C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z')
<----- VK_s ------
C: assert(VK_s = VK_s')
Note that the concrete (binary) message formats (mapping to HTTP
messages), as well as the formal definitions of equations for the
latter two messages, are defined in the core specification [<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>].
The formal definitions for values corresponding to the first two
messages are defined in the following sections.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Authentication Algorithms</span>
This document specifies one family of algorithms based on APKAS-AMP,
to be used with [<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>]. This family consists of four
authentication algorithms, which differ only in their underlying
mathematical groups and security parameters. These algorithms do not
add any additional parameters. The tokens for these algorithms are
as follows:
o iso-kam3-dl-2048-sha256: for the 2048-bit discrete-logarithm
setting with the SHA-256 hash function.
o iso-kam3-dl-4096-sha512: for the 4096-bit discrete-logarithm
setting with the SHA-512 hash function.
o iso-kam3-ec-p256-sha256: for the 256-bit prime-field
elliptic-curve setting with the SHA-256 hash function.
o iso-kam3-ec-p521-sha512: for the 521-bit prime-field
elliptic-curve setting with the SHA-512 hash function.
<span class="grey">Oiwa, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
For discrete-logarithm settings, the underlying groups are the
2048-bit and 4096-bit Modular Exponential (MODP) groups defined in
[<a href="./rfc3526" title=""More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)"">RFC3526</a>]. See <a href="#appendix-A">Appendix A</a> for the exact specifications for the
groups and associated parameters. Hash function H is SHA-256 for the
2048-bit group and SHA-512 for the 4096-bit group, respectively, as
defined in FIPS PUB 180-4 [<a href="#ref-FIPS.180-4.2015">FIPS.180-4.2015</a>]. The hash iteration
count nIterPi is 16384. The representation of the parameters "kc1",
"ks1", "vkc", and "vks" is base64-fixed-number.
For the elliptic-curve settings, the underlying groups are the
elliptic curves over the prime fields P-256 and P-521, respectively,
as specified in <a href="#appendix-D.1.2">Appendix D.1.2</a> of the FIPS PUB 186-4
[<a href="#ref-FIPS.186-4.2013">FIPS.186-4.2013</a>] specification. Hash function H is SHA-256 for the
P-256 curve and SHA-512 for the P-521 curve, respectively. Cofactors
of these curves are 1. The hash iteration count nIterPi is 16384.
The representation of the parameters "kc1", "ks1", "vkc", and "vks"
is hex-fixed-number.
Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3)
as defined in <a href="#section-6.3">Section 6.3</a> of ISO/IEC 11770-4 [<a href="#ref-ISO.11770-4.2006">ISO.11770-4.2006</a>], with
a few modifications/improvements. However, implementers should
consider this document as normative, because several minor details of
the algorithm have changed and major improvements have been made.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Support Functions and Notations</span>
The algorithm definitions use the support functions and notations
defined below.
Decimal notations are used for integers in this specification by
default. Integers in hexadecimal notations are prefixed with "0x".
In this document, the octet(), OCTETS(), and INT() functions are used
as defined in the core specification [<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>].
Note: The definition of OCTETS() is different from the function
GE2OS_x in the original ISO specification; GE2OS_x takes the shortest
representation without preceding zeros.
All of the algorithms defined in this specification use the default
functions defined in <a href="./rfc8120#section-12.2">Section 12.2 of [RFC8120]</a> for computing the
values pi, VK_c, and VK_s.
<span class="grey">Oiwa, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Functions for Discrete-Logarithm Settings</span>
In this section, an equation (x / y mod z) denotes a natural number w
less than z that satisfies (w * y) mod z = x mod z.
For the discrete logarithm, we refer to some of the domain parameters
by using the following symbols:
o q: for "the prime" defining the MODP group.
o g: for "the generator" associated with the group.
o r: for the order of the subgroup generated by g.
The function J is defined as
J(pi) = g^(pi) mod q
The value of K_c1 is derived as
K_c1 = g^(S_c1) mod q
where S_c1 is a random integer within the range [1, r-1] and r is the
size of the subgroup generated by g. In addition, S_c1 MUST be
larger than log(q)/log(g) (so that g^(S_c1) > q).
The server MUST check the condition 1 < K_c1 < q-1 upon reception.
Let an intermediate value t_1 be
t_1 = INT(H(octet(1) | OCTETS(K_c1)))
The value of K_s1 is derived from J(pi) and K_c1 as
K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod q
where S_s1 is a random number within the range [1, r-1]. The value
of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition is not held,
the server MUST reject the exchange. The client MUST check this
condition upon reception.
Let an intermediate value t_2 be
t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1)))
The value z on the client side is derived by the following equation:
z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod q
<span class="grey">Oiwa, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
The value z on the server side is derived by the following equation:
z = (K_c1 * g^(t_2))^(S_s1) mod q
(Note: The original ISO specification contained a message pair
containing verification of value z along with the "transcript" of the
protocol exchange. This functionality is contained in the functions
VK_c and VK_s.)
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Functions for Elliptic-Curve Settings</span>
For the elliptic-curve settings, we refer to some of the domain
parameters by the following symbols:
o q: for the prime used to define the group.
o G: for the point defined with the underlying group called
"the generator".
o h: for the cofactor of the group.
o r: for the order of the subgroup generated by G.
The function P(p) converts a curve point p into an integer
representing point p, by computing x * 2 + (y mod 2), where (x, y)
are the coordinates of point p. P'(z) is the inverse of function P;
that is, it converts an integer z to a point p that satisfies
P(p) = z. If such p exists, it is uniquely defined. Otherwise,
z does not represent a valid curve point.
The operator "+" indicates the elliptic-curve group operation, and
the operation [x] * p denotes an integer-multiplication of point p:
it calculates p + p + ... (x times) ... + p. See the literature on
elliptic-curve cryptography for the exact algorithms used for those
functions (e.g., <a href="./rfc6090#section-3">Section 3 of [RFC6090]</a>; however, note that [<a href="./rfc6090" title=""Fundamental Elliptic Curve Cryptography Algorithms"">RFC6090</a>]
uses different notations). 0_E represents the infinity point. The
equation (x / y mod z) denotes a natural number w less than z that
satisfies (w * y) mod z = x mod z.
The function J is defined as
J(pi) = [pi] * G
<span class="grey">Oiwa, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
The value of K_c1 is derived as
K_c1 = P(K_c1'), where K_c1' = [S_c1] * G
where S_c1 is a random number within the range [1, r-1]. The server
MUST check that (1) the value of received K_c1 represents a valid
curve point and (2) [h] * K_c1' is not equal to 0_E.
Let an intermediate integer t_1 be
t_1 = INT(H(octet(1) | OCTETS(K_c1)))
The value of K_s1 is derived from J(pi) and K_c1' = P'(K_c1) as
K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1'))
where S_s1 is a random number within the range [1, r-1]. The value
of K_s1 MUST represent a valid curve point and satisfy
[h] * P'(K_s1) <> 0_E. If this condition is not satisfied, the
server MUST reject the exchange. The client MUST check this
condition upon reception.
Let an intermediate integer t_2 be
t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1)))
The value z on the client side is derived by the following equation:
z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1))
The value z on the server side is derived by the following equation:
z = P([S_s1] * (P'(K_c1) + [t_2] * G))
<span class="grey">Oiwa, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
This document defines four new tokens that have been added to the
"HTTP Mutual Authentication Algorithms" registry:
+-------------------------+-----------------------------+-----------+
| Token | Description | Reference |
+-------------------------+-----------------------------+-----------+
| iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | <a href="./rfc8121">RFC 8121</a> |
| | 2048-bit DL | |
| | | |
| iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | <a href="./rfc8121">RFC 8121</a> |
| | 4096-bit DL | |
| | | |
| iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | <a href="./rfc8121">RFC 8121</a> |
| | 256-bit EC | |
| | | |
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | <a href="./rfc8121">RFC 8121</a> |
| | 521-bit EC | |
+-------------------------+-----------------------------+-----------+
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Please refer to the Security Considerations section of the core
specification [<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>] for algorithm-independent considerations.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. General Implementation Considerations</span>
o During the exchange, the value VK_s, defined in [<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>], MUST
only be sent when the server has received a correct (expected)
value of VK_c. This is a cryptographic requirement, as stated in
[<a href="#ref-ISO.11770-4.2006">ISO.11770-4.2006</a>].
o All random numbers used in these algorithms MUST be
cryptographically secure against forward and backward guessing
attacks.
o To prevent timing-based side-channel attacks, computation times of
all numerical operations on discrete-logarithm group elements and
elliptic-curve points MUST be normalized and made independent of
the exact values.
<span class="grey">Oiwa, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Cryptographic Assumptions and Considerations</span>
The notes in this subsection are for those who analyze the security
of this algorithm and those who might want to make a derived work
from this algorithm specification.
o The treatment of an invalid K_s1 value in the exchange has been
changed from the method defined in the original ISO specification,
which specifies that the sender should retry with another random
S_s1 value. We specify that the exchange must be rejected. This
is due to an observation that this condition is less likely to
result from a random error caused by an unlucky choice of S_s1 but
is more likely the result of a systematic failure caused by an
invalid J(pi) value (even implying possible denial-of-service
attacks).
o The usual construction of authenticated key exchange algorithms
consists of a key exchange phase and a key verification phase. To
avoid security risks or vulnerabilities caused by mixing values
from two or more key exchanges, the latter usually involves some
kinds of exchange transactions to be verified. In the algorithms
defined in this document, such verification steps are provided in
the generalized definitions of VK_c and VK_s in [<a href="./rfc8120" title=""Mutual Authentication Protocol for HTTP"">RFC8120</a>]. If the
algorithm defined above is used in other protocols, this aspect
MUST be given careful consideration.
o The domain parameters chosen and specified in this document are
based on a few assumptions. In the discrete-logarithm setting,
q has to be a safe prime ([(q - 1) / 2] must also be prime), and
r should be the largest possible value [(q - 1) / 2]. In the
elliptic-curve setting, r has to be prime. Implementers defining
a variation of this algorithm using a different domain parameter
SHOULD be attentive to these conditions.
<span class="grey">Oiwa, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-FIPS.180-4.2015">FIPS.180-4.2015</a>]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<<a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">http://nvlpubs.nist.gov/nistpubs/FIPS/</a>
<a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">NIST.FIPS.180-4.pdf</a>>.
[<a id="ref-FIPS.186-4.2013">FIPS.186-4.2013</a>]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013,
<<a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">http://nvlpubs.nist.gov/nistpubs/FIPS/</a>
<a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">NIST.FIPS.186-4.pdf</a>>.
[<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>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3526">RFC3526</a>] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
<a href="./rfc3526">RFC 3526</a>, DOI 10.17487/RFC3526, May 2003,
<<a href="http://www.rfc-editor.org/info/rfc3526">http://www.rfc-editor.org/info/rfc3526</a>>.
[<a id="ref-RFC8120">RFC8120</a>] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", <a href="./rfc8120">RFC 8120</a>, DOI 10.17487/RFC8120, April 2017,
<<a href="http://www.rfc-editor.org/info/rfc8120">http://www.rfc-editor.org/info/rfc8120</a>>.
<span class="grey">Oiwa, et al. Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-IEEE-1363.2_2008">IEEE-1363.2_2008</a>]
IEEE, "IEEE Standard Specifications for Password-Based
Public-Key Cryptographic Techniques", IEEE 1363.2-2008,
DOI 10.1109/ieeestd.2009.4773330,
<<a href="http://ieeexplore.ieee.org/servlet/opac?punumber=4773328">http://ieeexplore.ieee.org/servlet/</a>
<a href="http://ieeexplore.ieee.org/servlet/opac?punumber=4773328">opac?punumber=4773328</a>>.
[<a id="ref-ISO.11770-4.2006">ISO.11770-4.2006</a>]
International Organization for Standardization,
"Information technology -- Security techniques -- Key
management -- Part 4: Mechanisms based on weak secrets",
ISO Standard 11770-4, May 2006,
<<a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39723">http://www.iso.org/iso/iso_catalogue/catalogue_tc/</a>
<a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39723">catalogue_detail.htm?csnumber=39723</a>>.
[<a id="ref-RFC6090">RFC6090</a>] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", <a href="./rfc6090">RFC 6090</a>,
DOI 10.17487/RFC6090, February 2011,
<<a href="http://www.rfc-editor.org/info/rfc6090">http://www.rfc-editor.org/info/rfc6090</a>>.
<span class="grey">Oiwa, et al. Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. (Informative) Group Parameters for Algorithms Based on the</span>
Discrete Logarithm
The MODP group used for the iso-kam3-dl-2048-sha256 algorithm is
defined by the following parameters:
The prime is
q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
The generator is
g = 2
The size of the subgroup generated by g is
r = (q - 1) / 2 =
0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
0AB9472D 45565534 7FFFFFFF FFFFFFFF
<span class="grey">Oiwa, et al. Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
The MODP group used for the iso-kam3-dl-4096-sha512 algorithm is
defined by the following parameters:
The prime is
q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFF
The generator is
g = 2
<span class="grey">Oiwa, et al. Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
The size of the subgroup generated by g is
r = (q - 1) / 2 =
0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32
767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263
D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735
F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006
5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598
A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B
C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED
12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553
143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6
8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54
C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC
FFFFFFFF FFFFFFFF
<span class="grey">Oiwa, et al. Experimental [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. (Informative) Derived Numerical Values</span>
This section provides several numerical values for implementing this
protocol. These values are derived from the specifications provided
in <a href="#section-3">Section 3</a>. The values shown in this section are for informative
purposes only.
+----------------+---------+---------+---------+---------+----------+
| | dl-2048 | dl-4096 | ec-p256 | ec-p521 | |
+----------------+---------+---------+---------+---------+----------+
| Size of K_c1, | 2048 | 4096 | 257 | 522 | (bits) |
| etc. | | | | | |
| | | | | | |
| hSize, size of | 256 | 512 | 256 | 512 | (bits) |
| H(...) | | | | | |
| | | | | | |
| Length of | 256 | 512 | 33 | 66 | (octets) |
| OCTETS(K_c1), | | | | | |
| etc. | | | | | |
| | | | | | |
| Length of kc1, | 344* | 684* | 66 | 132 | (octets) |
| ks1 param. | | | | | |
| values | | | | | |
| | | | | | |
| Length of vkc, | 44* | 88* | 64 | 128 | (octets) |
| vks param. | | | | | |
| values | | | | | |
| | | | | | |
| Minimum | 2048 | 4096 | 1 | 1 | |
| allowed S_c1 | | | | | |
+----------------+---------+---------+---------+---------+----------+
(The numbers marked with an "*" do not include any enclosing
quotation marks.)
<span class="grey">Oiwa, et al. Experimental [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8121">RFC 8121</a> HTTP Mutual Authentication: Algorithms April 2017</span>
Authors' Addresses
Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute
Tsukuba Central 1
1-1-1 Umezono
Tsukuba-shi, Ibaraki
Japan
Email: y.oiwa@aist.go.jp
Hajime Watanabe
National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute
Tsukuba Central 1
1-1-1 Umezono
Tsukuba-shi, Ibaraki
Japan
Email: h-watanabe@aist.go.jp
Hiromitsu Takagi
National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute
Tsukuba Central 1
1-1-1 Umezono
Tsukuba-shi, Ibaraki
Japan
Email: takagi.hiromitsu@aist.go.jp
Kaoru Maeda
Individual Contributor
Email: kaorumaeda.ml@gmail.com
Tatsuya Hayashi
Lepidum Co. Ltd.
Village Sasazuka 3, Suite #602
1-30-3 Sasazuka
Shibuya-ku, Tokyo
Japan
Email: hayashi@lepidum.co.jp
Yuichi Ioku
Individual Contributor
Email: mutual-work@ioku.org
Oiwa, et al. Experimental [Page 17]
</pre>
|
