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
|
<pre>Internet Engineering Task Force (IETF) K. Burgin
Request for Comments: 6380 National Security Agency
Category: Informational M. Peck
ISSN: 2070-1721 The MITRE Corporation
October 2011
<span class="h1">Suite B Profile for Internet Protocol Security (IPsec)</span>
Abstract
The United States Government has published guidelines for "NSA
Suite B Cryptography" dated July, 2005, which defines cryptographic
algorithm policy for national security applications. This document
specifies the conventions for using Suite B cryptography in IP
Security (IPsec).
Since many of the Suite B algorithms are used in other environments,
the majority of the conventions needed for the Suite B
algorithms are already specified in other documents. This document
references the source of these conventions, with some relevant
detail repeated to aid developers who choose to support Suite B.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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="./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/rfc6380">http://www.rfc-editor.org/info/rfc6380</a>.
<span class="grey">Burgin & Peck Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
Copyright Notice
Copyright (c) 2011 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.
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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Suite B Requirements ............................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Minimum Levels of Security (minLOS) .............................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Non-Signature Primitives ...................................<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Suite B IPsec Cryptographic Suites .........................<a href="#page-4">4</a>
<a href="#section-4.3">4.3</a>. Suite B IKEv2 Authentication ...............................<a href="#page-5">5</a>
<a href="#section-4.4">4.4</a>. Digital Signatures and Certificates ........................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Suite B Security Associations (SAs) for IKEv2 and IPsec .........<a href="#page-6">6</a>
<a href="#section-6">6</a>. The Key Exchange Payload in the IKE_SA_INIT Exchange ............<a href="#page-7">7</a>
<a href="#section-7">7</a>. Generating Keying Material for the IKE SA .......................<a href="#page-7">7</a>
<a href="#section-8">8</a>. Additional Requirements .........................................<a href="#page-7">7</a>
<a href="#section-9">9</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-10">10</a>. References .....................................................<a href="#page-9">9</a>
<a href="#section-10.1">10.1</a>. Normative References ......................................<a href="#page-9">9</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-10">10</a>
<span class="grey">Burgin & Peck Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies the conventions for using NSA Suite B
Cryptography [<a href="#ref-SuiteB" title=""NSA Suite B Cryptography"">SuiteB</a>] in IP Security (IPsec).
IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. The
Internet Key Exchange (IKE) provides an automated key management for
IPsec, performing mutual authentication between two parties and
establishing security associations (SAs) that protects both IKE and
IPsec communications. Suite B compliant implementations for IPsec
MUST use IKEv2 [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>].
[<a id="ref-RFC6379">RFC6379</a>] defines a set of four cryptographic user interface suites
for IPsec that are comprised of Suite B algorithms. The four suites
specify options for IKEv2 and for the IP Encapsulating Security
Payload (ESP), [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>]. Suite B compliant implementations for
IPsec MUST use one of these four suites depending upon the desired
security level and security services.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</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>. Suite B Requirements</span>
Suite B requires that key establishment and signature algorithms be
based upon Elliptic Curve Cryptography and that the encryption
algorithm be AES [<a href="#ref-FIPS197" title=""Advanced Encryption Standard (AES)"">FIPS197</a>]. Suite B includes [<a href="#ref-SuiteB" title=""NSA Suite B Cryptography"">SuiteB</a>]:
Encryption: Advanced Encryption Standard (AES) (key sizes
of 128 and 256 bits)
Digital Signature Elliptic Curve Digital Signature Algorithm
(ECDSA) [<a href="#ref-FIPS186-3" title=""Digital Signature Standard (DSS)"">FIPS186-3</a>] (using the curves with 256-
and 384-bit prime moduli)
Key Exchange Elliptic Curve Diffie-Hellman (ECDH)
[<a href="#ref-SP800-56A" title=""Recommendation for Pair-wise Key Establishment Schemes Using Discrete Logarithm Cryptography"">SP800-56A</a>], (using the curves with 256- and
384-bit prime moduli)
Hashes SHA-256 and SHA-384 [<a href="#ref-FIPS180-3" title=""Secure Hash Standard"">FIPS180-3</a>]
<span class="grey">Burgin & Peck Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
The two elliptic curves used in Suite B appear in the literature
under two different names. For the sake of clarity, we list both
names below:
Curve NIST name SECG name IANA assigned DH group #
-----------------------------------------------------------------
P-256 nistp256 secp256r1 19
P-384 nistp384 secp384r1 20
IANA has already registered these DH groups in [<a href="#ref-IKEV2IANA" title=""Internet Key Exchange Version 2 (IKEv2) Parameters"">IKEV2IANA</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Minimum Levels of Security (minLOS)</span>
Suite B provides for two levels of cryptographic security, namely a
128-bit minimum level of security (minLOS_128) and a 192-bit minimum
level of security (minLOS_192). Each level defines a minimum
strength that all cryptographic algorithms must provide.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Non-Signature Primitives</span>
We divide the Suite B non-signature primitives into two columns as
shown in Table 1.
Column 1 Column 2
+-------------------+------------------+
Encryption | AES-128 | AES-256 |
+-------------------+------------------+
Key Agreement | ECDH on P-256 | ECDH on P-384 |
+-------------------+------------------+
Hash for PRF/MAC | SHA256 | SHA384 |
+-------------------+------------------+
Table 1: Suite B Cryptographic Non-Signature Primitives
At the 128-bit minimum level of security:
- the non-signature primitives MUST either come exclusively from
Column 1 or exclusively from Column 2.
At the 192-bit minimum level of security:
- the non-signature primitives MUST come exclusively from Column 2.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Suite B IPsec Cryptographic Suites</span>
Each system MUST specify a security level of a minimum of 128 bits or
192 bits. The security level determines which suites from [<a href="./rfc6379" title=""Suite B Cryptographic Suites for IPsec"">RFC6379</a>]
are allowed.
<span class="grey">Burgin & Peck Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
The four Suite B cryptographic user interface suites ("UI suites")
[<a href="./rfc6379" title=""Suite B Cryptographic Suites for IPsec"">RFC6379</a>]: Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or
Suite-B-GMAC-256, satisfy the requirements of <a href="#section-3">Section 3</a>.
At the 128-bit minimum level of security:
- one of Suite-B-GCM-128, Suite-B-GMAC-128, Suite-B-GCM-256 or
Suite-B-GMAC-256 MUST be used by Suite B IPsec compliant
implementations [<a href="./rfc6379" title=""Suite B Cryptographic Suites for IPsec"">RFC6379</a>].
At the 192-bit minimum level of security:
- one of Suite-B-GCM-256 or Suite-B-GMAC-256 MUST be used by Suite B
IPsec compliant implementations [<a href="./rfc6379" title=""Suite B Cryptographic Suites for IPsec"">RFC6379</a>].
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Suite B IKEv2 Authentication</span>
Digital signatures using ECDSA MUST be used for authentication by
Suite B compliant implementations. [<a href="./rfc4754" title=""IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)"">RFC4754</a>] defines two digital
signature algorithms: ECDSA-256 and ECDSA-384. Following the
direction of <a href="./rfc4754">RFC 4754</a>, ECDSA-256 represents an instantiation of the
ECDSA algorithm using the P-256 curve and the SHA-256 hash function.
ECDSA-384 represents an instantiation of the ECDSA algorithm using
the P-384 curve and the SHA-384 hash function.
If configured at a minimum level of security of 128 bits, a system
MUST use either ECDSA-256 or ECDSA-384 for IKE authentication. It is
allowable for one party to authenticate with ECDSA-256 and the other
party to authenticate with ECDSA-384. This flexibility will allow
interoperability between an initiator and a responder that have
different sizes of ECDSA authentication keys.
Initiators and responders in a system configured at a minimum level
of security of 128 bits MUST be able to verify ECDSA-256 signatures
and SHOULD be able to verify ECDSA-384 signatures.
If configured at a minimum level of security of 192 bits, ECDSA-384
MUST be used by both parties for IKEv2 authentication.
Initiators and responders in a system configured at a minimum level
of security of 192 bits MUST be able to verify ECDSA-384 signatures.
For Suite B compliant systems, authentication methods other than
ECDSA-256 and ECDSA-384 MUST NOT be used for IKEv2 authentication.
If a relying party receives a message signed with any other
authentication method, it MUST return an AUTHENTICATION_FAILED
notification and stop processing the message.
<span class="grey">Burgin & Peck Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Digital Signatures and Certificates</span>
The initiator and responder, at both minimum levels of security, MUST
each use an X.509 certificate that complies with the "Suite B
Certificate and Certificate Revocation List (CRL) Profile" [<a href="./rfc5759" title=""Suite B Certificate and Certificate Revocation List (CRL) Profile"">RFC5759</a>]
and that contains an elliptic curve public key with the key usage bit
set for digital signature.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Suite B Security Associations (SAs) for IKEv2 and IPsec</span>
The four suites in [<a href="./rfc6379" title=""Suite B Cryptographic Suites for IPsec"">RFC6379</a>] specify options for ESP [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] and
IKEv2 [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>]. The four suites are differentiated by cryptographic
algorithm strength and a choice of whether ESP is to provide both
confidentiality and integrity or integrity only. The suite names are
based upon the AES mode ("GCM" or "GMAC") and the AES key length
specified for ESP ("128" or "256"). Suites with "GCM" in their name
MUST be used when ESP integrity protection and encryption are both
needed. Suites with "GMAC" in their name MUST be used only when
there is no need for ESP encryption.
An initiator in a system configured at a minimum level of security of
128 bits MUST offer one or more of the four suites: Suite-B-GCM-128,
Suite-B-GMAC-128, Suite-B-GCM-256, or Suite-B-GMAC-256 [<a href="./rfc6379" title=""Suite B Cryptographic Suites for IPsec"">RFC6379</a>].
Suite-B-GCM-128 and Suite-B-GMAC-128, if offered, MUST appear in the
IKEv2 and IPsec SA payloads before any offerings of Suite-B-GCM-256
and Suite-B-GMAC-256.
A responder in a system configured at a minimum level of security of
128 bits MUST support one or both of the two suites Suite-B-GCM-128
or Suite-B-GMAC-128 and SHOULD support one or both of the two suites
Suite-B-GCM-256 or Suite-B-GMAC-256. The responder MUST accept one
of the Suite B UI suites. If none of the four suites are offered,
the responder MUST return a Notify payload with the error
"NO_PROPOSAL_CHOSEN" when operating in Suite B compliant mode.
An initiator in a system configured at a minimum level of security of
192 bits MUST offer either one or both suites: Suite-B-GCM-256 or
Suite-B-GMAC-256.
A responder configured in a system at a minimum level of security of
192 bits MUST choose one of Suite-B-GCM-256 or Suite-B-GMAC-256. If
neither suite is offered, the responder MUST return a Notify payload
with the error "NO_PROPOSAL_CHOSEN".
<span class="grey">Burgin & Peck Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. The Key Exchange Payload in the IKE_SA_INIT Exchange</span>
A Suite B IPsec compliant initiator and responder MUST each generate
an ephemeral elliptic curve key pair to be used in the elliptic curve
Diffie-Hellman (ECDH) key exchange. If the 256-bit random ECP group
for Transform Type 4 is selected, each side MUST generate an EC key
pair using the P-256 elliptic curve [<a href="#ref-SP800-57" title=""Recommendation for Key Management - Part 1"">SP800-57</a>]. If the 384-bit
random ECP group for Transform Type 4 is selected, each side MUST
generate an EC key pair using the P-384 elliptic curve [<a href="#ref-SP800-57" title=""Recommendation for Key Management - Part 1"">SP800-57</a>].
The ephemeral public keys MUST be stored in the key exchange payload
as in [<a href="./rfc5903" title=""Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2"">RFC5903</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Generating Keying Material for the IKE SA</span>
The ECDH shared secret established during the key exchange consists
of the x value of the ECDH common value [<a href="./rfc5903" title=""Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2"">RFC5903</a>]. The x value is
256 or 384 bits when using the P-256 or P-384 curve, respectively.
IKEv2 [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>] allows for the reuse of Diffie-Hellman ephemeral
keys. <a href="#section-5.6.4.3">Section 5.6.4.3</a> of NIST SP800-56A states that an ephemeral
private key MUST be used in exactly one key establishment transaction
and MUST be zeroized after its use. <a href="#section-5.8">Section 5.8</a> of SP800-56A states
that the Diffie-Hellman shared secret MUST be zeroized immediately
after its use. Suite B compliant IPsec systems MUST follow the
mandates in SP800-56A.
If using PRF-HMAC-SHA-256, SKEYSEED, SK_d, SK_pi, and SK_pr MUST each
be generated to be 256 bits long per <a href="./rfc5996">RFC 5996</a> ([<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>], <a href="#section-2.14">Section</a>
<a href="#section-2.14">2.14</a>). If using PRF-HMAC-SHA-384, SKEYSEED, SK_d, SK_pi and SK_pr
MUST each be generated to be 384 bits long. SK_ai and SK_ar MUST be
256 or 384 bits long if using HMAC-SHA-256-128 or HMAC-SHA-384-192,
respectively. SK_ei and SK_er MUST be 128 or 256 bits long if the
key length attribute for AES_ENC_CBC is set to 128 or 256,
respectively.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Additional Requirements</span>
AH is not supported in Suite B compliant implementations.
Per [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>], although ESP does not directly include a Diffie-
Hellman exchange, a Diffie-Hellman group MAY be negotiated for the
Child SA. This allows the peers to employ Diffie-Hellman in the
CREATE_CHILD_SA exchange. If a transform Type 4 is specified for an
SA for ESP, the value of the transform MUST match that of the
transform used by the IKE SA.
<span class="grey">Burgin & Peck Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
Per <a href="./rfc5996">RFC 5996</a>, if a CREATE_CHILD_SA exchange includes a KEi payload,
at least one of the SA offers MUST include the Diffie-Hellman group
of the KEi. For Suite B IPsec compliant implementations, the Diffie-
Hellman group of the KEi MUST use the same random ECP group used in
the IKE_INIT_SA.
For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both
parties. The initiator of this exchange MAY include a new Diffie-
Hellman key; if it is included, it MUST use the same random ECP group
used in the IKE_INIT_SA. If the initiator of the exchange includes a
Diffie-Hellman key, the responder MUST include a Diffie-Hellman key,
and it MUST use the same random ECP group.
Suite B IPsec compliant systems MUST support IKEv2 and MUST NOT use
IKEv1 between a Suite B compliant initiator and responder. To
accommodate backward compatibility, a Suite B IPsec compliant system
can be configured to use IKEv1 so long as only IKEv2 is used between
a Suite B compliant initiator and responder. However, when IKEv1 is
being used, the system is not being operated in a Suite B compliant
mode.
IKEv2 does not specify how Identification Payloads (IDi and IDr) in
the IKE_AUTH exchanges are used for policy lookup. For Suite B
compliant systems, the IKEv2 authentication method MUST NOT use the
Identification Payloads for policy lookup. Instead, the
authentication method MUST use an end-entity found in the end-entity
certificate provided by the authenticating party.
The administrative user interface (UI) for a system that conforms to
this profile MUST allow the operator to specify a single suite. If
only one suite is specified in the administrative UI, the IKEv2
implementation MUST only offer algorithms for that one suite.
The administrative UI MAY allow the operator to specify more than one
suite; if it allows this, it MUST allow the operator to specify a
preferred order for the suites that are to be offered or accepted.
The preferred order MUST follow the direction provided in <a href="#section-4">Section 4</a>.
If more than one suite is specified in the administrative UI, the
IKEv2 implementation MUST only offer algorithms for those suites.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This document discusses security requirements throughout, and it
inherits the security considerations of [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>], [<a href="./rfc4754" title=""IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)"">RFC4754</a>],
[<a href="./rfc5759" title=""Suite B Certificate and Certificate Revocation List (CRL) Profile"">RFC5759</a>], and [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>].
<span class="grey">Burgin & Peck Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.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 id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC4754">RFC4754</a>] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication
Using the Elliptic Curve Digital Signature Algorithm
(ECDSA)", <a href="./rfc4754">RFC 4754</a>, January 2007.
[<a id="ref-RFC5759">RFC5759</a>] Solinas, J. and L. Zieglar, "Suite B Certificate and
Certificate Revocation List (CRL) Profile", <a href="./rfc5759">RFC 5759</a>,
January 2010.
[<a id="ref-RFC5996">RFC5996</a>] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", <a href="./rfc5996">RFC</a>
<a href="./rfc5996">5996</a>, September 2010.
[<a id="ref-RFC6379">RFC6379</a>] Law, L. and J. Solinas, "Suite B Cryptographic Suites
for IPsec", <a href="./rfc6379">RFC 6379</a>, October 2011.
[<a id="ref-FIPS180-3">FIPS180-3</a>] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-3, October 2008.
[<a id="ref-FIPS186-3">FIPS186-3</a>] National Institute of Standards and Technology,
"Digital Signature Standard (DSS)", FIPS PUB 186-3,
June 2009.
[<a id="ref-FIPS197">FIPS197</a>] National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001.
[<a id="ref-SP800-56A">SP800-56A</a>] National Institute of Standards and Technology,
"Recommendation for Pair-wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A, March 2007.
[<a id="ref-SP800-57">SP800-57</a>] National Institute of Standards and Technology,
"Recommendation for Key Management - Part 1", NIST
Special Publication 800-57, March 2007.
<span class="grey">Burgin & Peck Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6380">RFC 6380</a> Suite B IPsec October 2011</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-IKEV2IANA">IKEV2IANA</a>] "Internet Key Exchange Version 2 (IKEv2) Parameters",
<<a href="http://www.iana.org">http://www.iana.org</a>>.
[<a id="ref-SuiteB">SuiteB</a>] U.S. National Security Agency, "NSA Suite B
Cryptography", January 2009,
<<a href="http://www.nsa.gov/ia/programs/suiteb_cryptography/">http://www.nsa.gov/ia/programs/suiteb_cryptography/</a>>.
[<a id="ref-RFC5903">RFC5903</a>] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", <a href="./rfc5903">RFC 5903</a>, June
2010.
Authors' Addresses
Kelley W. Burgin
National Security Agency
EMail: kwburgi@tycho.ncsc.mil
Michael A. Peck
The MITRE Corporation
EMail: mpeck@mitre.org
Burgin & Peck Informational [Page 10]
</pre>
|
