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
|
<pre>Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 7619 ELVIS-PLUS
Updates: <a href="./rfc4301">4301</a> P. Wouters
Category: Standards Track Red Hat
ISSN: 2070-1721 August 2015
<span class="h1">The NULL Authentication Method</span>
<span class="h1">in the Internet Key Exchange Protocol Version 2 (IKEv2)</span>
Abstract
This document specifies the NULL Authentication method and the
ID_NULL Identification Payload ID Type for Internet Key Exchange
Protocol version 2 (IKEv2). This allows two IKE peers to establish
single-side authenticated or mutual unauthenticated IKE sessions for
those use cases where a peer is unwilling or unable to authenticate
or identify itself. This ensures IKEv2 can be used for Opportunistic
Security (also known as Opportunistic Encryption) to defend against
Pervasive Monitoring attacks without the need to sacrifice anonymity.
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/rfc7619">http://www.rfc-editor.org/info/rfc7619</a>.
<span class="grey">Smyslov & Wouters Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Using the NULL Authentication Method . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Authentication Payload . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Identification Payload . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. INITIAL_CONTACT Notification . . . . . . . . . . . . . . <a href="#page-5">5</a>
2.4. Interaction with the Peer Authorization Database (PAD) . 5
<a href="#section-2.5">2.5</a>. Traffic Selectors . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.1">3.1</a>. Audit Trail and Peer Identification . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Resource Management and Robustness . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. IKE Configuration Selection . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4">3.4</a>. Networking Topology Changes . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.2">5.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#appendix-A">Appendix A</a>. Update of PAD processing in <a href="./rfc4301">RFC 4301</a> . . . . . . . . <a href="#page-11">11</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="grey">Smyslov & Wouters Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Internet Key Exchange Protocol version 2 (IKEv2), specified in
[<a href="./rfc7296" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC7296</a>], provides a way for two parties to perform an authenticated
key exchange. While the authentication methods used by the peers can
be different, there is no method for one or both parties to remain
unauthenticated and anonymous. This document extends the
authentication methods to support unauthenticated and anonymous IKE
sessions.
In some situations, mutual authentication is undesirable,
superfluous, or impossible. The following three examples illustrate
these unauthenticated use cases:
o A user wants to establish an anonymous secure connection to a
server. In this situation, the user should be able to
authenticate the server without presenting or authenticating to
the server with their own identity. This case uses a single-sided
authentication of the responder.
o A sensor that periodically wakes up from a suspended state wants
to send a measurement (e.g., temperature) to a collecting server.
The sensor must be authenticated by the server to ensure
authenticity of the measurement, but the sensor does not need to
authenticate the server. This case uses a single-sided
authentication of the initiator.
o Two peers without any trust relationship wish to defend against
widespread pervasive monitoring attacks as described in [<a href="./rfc7258" title=""Pervasive Monitoring Is an Attack"">RFC7258</a>].
Without a trust relationship, the peers cannot authenticate each
other. Opportunistic Security [<a href="./rfc7435" title=""Opportunistic Security: Some Protection Most of the Time"">RFC7435</a>] states that
unauthenticated encrypted communication is preferred over
cleartext communication. The peers want to use IKE to setup an
unauthenticated encrypted connection that gives them protection
against pervasive monitoring attacks. An attacker that is able
and willing to send packets can still launch a man-in-the-middle
(MITM) attack to obtain a copy of the unencrypted communication.
This case uses a fully unauthenticated key exchange.
To meet these needs, this document introduces the NULL Authentication
method and the ID_NULL ID type. This allows an IKE peer to
explicitly indicate that it is unwilling or unable to certify its
identity.
<span class="grey">Smyslov & Wouters Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</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-2" href="#section-2">2</a>. Using the NULL Authentication Method</span>
In IKEv2, each peer independently selects the method to authenticate
itself to the other side. A peer may choose to refrain from
authentication by using the NULL Authentication method. If a host's
local policy requires that the identity of its peer be (non-null)
authenticated, and if that host receives an AUTH payload containing
the NULL Authentication method type, it MUST return an
AUTHENTICATION_FAILED notification. If an initiator uses the
Extensible Authentication Protocol (EAP), the responder MUST NOT use
the NULL Authentication method (in conformance with <a href="./rfc7296#section-2.16">Section 2.16 of
[RFC7296]</a>).
NULL authentication affects how the Authentication and the
Identification payloads are formed in the IKE_AUTH exchange.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Authentication Payload</span>
NULL authentication still requires a properly formed AUTH payload to
be present in the IKE_AUTH exchange messages, as the AUTH payload
cryptographically links the IKE_SA_INIT exchange messages with the
other messages sent over this IKE Security Association (SA).
When using NULL authentication, the content of the AUTH payload is
computed using the syntax of pre-shared secret authentication,
described in <a href="./rfc7296#section-2.15">Section 2.15 of [RFC7296]</a>. The value of SK_pi for the
initiator and SK_pr for the responder is used as the shared secret
for the content of the AUTH payload. Implementers should note this
means that authentication keys used by the two peers are different in
each direction. This is identical to how the contents of the two
last AUTH payloads are generated for the non-key-generating EAP
methods (see <a href="./rfc7296#section-2.16">Section 2.16 of [RFC7296]</a> for details).
The IKEv2 Authentication Method value for NULL Authentication is 13.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Identification Payload</span>
When a remote peer is not authenticated, any ID presented in the
Identification Data field of the ID payload cannot be validated. To
avoid the need of sending a bogus ID Type with placeholder data, this
specification defines a new ID Type, ID_NULL. The Identification
Data field of the ID payload for this ID Type MUST be empty.
<span class="grey">Smyslov & Wouters Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
If NULL authentication is in use and anonymity is a concern, then
ID_NULL SHOULD be used in the Identification payload. Some examples
of cases where a non-null identity type and value with NULL
authentication can be used are logging, troubleshooting, and in
scenarios where authentication takes place out of band after the IKE
SA is created (like in [<a href="#ref-AUTOVPN" title=""The AutoVPN Architecture"">AUTOVPN</a>]). The content of the Identification
payload MUST NOT be used for any trust and policy checking in
IKE_AUTH exchange when NULL authentication is employed (see
<a href="#section-2.4">Section 2.4</a> for details).
ID_NULL is primarily intended to be used with NULL authentication but
could be used in other situations where the content of the
Identification payload is not used. For example, ID_NULL could be
used when authentication is performed via raw public keys and the
identities are the keys themselves. These alternative uses of
ID_NULL should be described in their own respective documents.
The IKEv2 Identification Payload ID Type for ID_NULL is 13.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. INITIAL_CONTACT Notification</span>
The identity of a peer using NULL authentication cannot be used to
find existing IKE SAs created by the same peer, as the peer identity
is not authenticated. For that reason, the INITIAL_CONTACT
notifications MUST NOT be used to delete any other IKE SAs based on
the same peer identity without additional verification that the
existing IKE SAs with matching identity are actually stale.
The standard IKE Liveness Check procedure, described in <a href="./rfc7296#section-2.4">Section 2.4
of [RFC7296]</a>, can be used to detect stale IKE SAs created by peers
using NULL authentication. Inactive, unauthenticated IKE SAs should
be checked periodically. Additionally, the event of creating a new
unauthenticated IKE SA can be used to trigger an out-of-order check
on existing unauthenticated IKE SAs possibly limited to identical or
close-by IP addresses or to identical identities of the just created
IKE SA.
Implementations should weigh the resource consumption of sending
Liveness Checks against the memory usage of possible orphaned IKE
SAs. Implementations may choose to handle situations with thousands
of unauthenticated IKE SAs differently from situations with very few
such SAs.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Interaction with the Peer Authorization Database (PAD)</span>
<a href="./rfc4301#section-4.4.3">Section 4.4.3 of [RFC4301]</a> defines the Peer Authorization Database
(PAD), which provides the link between the Security Policy Database
(SPD) and IKEv2. The PAD contains an ordered list of records with
<span class="grey">Smyslov & Wouters Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
peers' identities along with corresponding authentication data and
Child SA authorization data. When the IKE SA is being established,
the PAD is consulted to determine how the peer should be
authenticated and what Child SAs it is authorized to create.
When using NULL authentication, the peer identity is not
authenticated and cannot be trusted. If ID_NULL is used with NULL
authentication, there is no ID at all. The processing of the PAD
described in <a href="./rfc4301#section-4.4.3">Section 4.4.3 of [RFC4301]</a> is updated for NULL
authentication as follows.
NULL authentication is added as one of the supported authentication
methods. This method does not have any authentication data. ID_NULL
is included into the list of allowed ID types. The matching rule for
ID_NULL consists only of whether this type is used, i.e., no actual
ID matching is done as ID_NULL contains no identity data.
When using the NULL Authentication method, those matching rules MUST
include matching of a new flag in the SPD entry specifying whether
unauthenticated users are allowed to use that entry. That is, each
SPD entry needs to be augmented to have a flag specifying whether it
can be used with NULL authentication or not, and only those rules
that explicitly have that flag turned on can be used with
unauthenticated connections.
The specific updates of text in <a href="./rfc4301#section-4.4.3">Section 4.4.3 of [RFC4301]</a> are listed
in <a href="#appendix-A">Appendix A</a>.
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Traffic Selectors</span>
Traffic Selectors and narrowing allow two IKE peers to mutually agree
on a traffic range for an IPsec SA. An unauthenticated peer must not
be allowed to use this mechanism to steal traffic that an IKE peer
intended to be for another host. This is especially problematic when
supporting anonymous IKE peers behind NAT, as such IKE peers build an
IPsec SA using their pre-NAT IP address that is different from the
source IP of their IKE packets. A rogue IKE peer could use malicious
Traffic Selectors to trick a remote host into giving it IP traffic
that the remote host never intended to be sent to remote IKE peers.
For example, if the remote host uses 192.0.2.1 as the DNS server, a
rogue IKE peer could set its Traffic Selector to 192.0.2.1 in an
attempt to receive the remote peer's DNS traffic. Implementations
SHOULD restrict and isolate all anonymous IKE peers from each other
and itself and only allow it access to itself and possibly its
intended network ranges.
<span class="grey">Smyslov & Wouters Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
One method to achieve this is to always assign internal IP addresses
to unauthenticated IKE clients, as described in <a href="./rfc7296#section-2.19">Section 2.19 of
[RFC7296]</a>. Implementations may also use other techniques such as
internal NAT and connection tracking.
Implementations MAY force unauthenticated IKE peers to single host-
to-host IPsec SAs. When using IPv6, this is not always possible, so
implementations MUST be able to assign a full /64 address block to
the peer as described in [<a href="./rfc5739" title=""IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5739</a>], even if it is not authenticated.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Security Considerations</span>
If authenticated IKE sessions are possible for a certain Traffic
Selector range between the peers, then unauthenticated IKE SHOULD NOT
be allowed for that Traffic Selector range. When mixing
authenticated and unauthenticated IKE with the same peer, policy
rules should ensure the highest level of security will be used to
protect the communication between the two peers. See [<a href="./rfc7435" title=""Opportunistic Security: Some Protection Most of the Time"">RFC7435</a>] for
details.
If both peers use NULL authentication, the entire key exchange
becomes unauthenticated. This makes the IKE session vulnerable to
active MITM attacks.
Using an ID Type other than ID_NULL with the NULL Authentication
method may compromise the client's anonymity in case of an active
MITM attack.
IKE implementations without NULL authentication have always performed
mutual authentication and were not designed for use with
unauthenticated IKE peers. Implementations might have made
assumptions that remote peers are identified. With NULL
authentication, these assumptions are no longer valid. Furthermore,
the host itself might have made trust assumptions or may not be aware
of the network topology changes that resulted from IPsec SAs from
unauthenticated IKE peers.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Audit Trail and Peer Identification</span>
With NULL authentication, an established IKE session is no longer
guaranteed to provide a verifiable (authenticated) entity known to
the system or network. Any logging of unproven ID payloads that were
not authenticated should be clearly marked and treated as "untrusted"
and possibly accompanied by logging the remote IP address of the IKE
session. Rate limiting of logging might be required to prevent
excessive resource consumption causing system damage.
<span class="grey">Smyslov & Wouters Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Resource Management and Robustness</span>
<a href="./rfc7296#section-2.6">Section 2.6 of [RFC7296]</a> provides guidance for mitigation of denial-
of-service (DoS) attacks by issuing COOKIES in response to resource
consumption of half-open IKE SAs. Furthermore, [<a href="#ref-DDOS-PROTECTION">DDOS-PROTECTION</a>]
offers additional countermeasures in an attempt to distinguish
attacking IKE packets from legitimate IKE peers.
These defense mechanisms do not take into account IKE systems that
allow unauthenticated IKE peers. An attacker using NULL
authentication is a fully legitimate IKE peer that is only
distinguished from authenticated IKE peers by having used NULL
authentication.
Implementers that implement NULL authentication should ensure their
implementation does not make any assumptions that depend on IKE peers
being "friendly", "trusted", or "identifiable". While
implementations should have been written to account for abusive
authenticated clients, any omission or error in handling abusive
clients may have gone unnoticed because abusive clients have been a
rare or nonexistent problem. When adding support for unauthenticated
IKE peers, these implementation omissions and errors will be found
and abused by attackers. For example, an unauthenticated IKE peer
could send an abusive amount of Liveness probes or Delete requests.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. IKE Configuration Selection</span>
Combining authenticated and unauthenticated IKE peers on a single
host can be dangerous, assuming the authenticated IKE peer gains more
or different access from unauthenticated peers (otherwise, why not
only allow unauthenticated peers). An unauthenticated IKE peer MUST
NOT be able to reach resources only meant for authenticated IKE peers
and MUST NOT be able to replace the Child SAs of an authenticated IKE
peer.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Networking Topology Changes</span>
When a host relies on packet filters or firewall software to protect
itself, establishing an IKE SA and installing an IPsec SA might
accidentally circumvent these packet filters and firewall
restrictions, as the Encapsulating Security Payload (ESP, protocol
50) or ESPinUDP (UDP port 4500) packets of the encrypted traffic do
not match the packet filters defined for unencrypted traffic. IKE
peers supporting unauthenticated IKE MUST pass all decrypted traffic
through the same packet filters and security mechanisms as incoming
plaintext traffic.
<span class="grey">Smyslov & Wouters Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
Per this document, IANA has added a new entry in the "IKEv2
Authentication Method" registry:
13 NULL Authentication
Per this document, IANA has added a new entry in the "IKEv2
Identification Payload ID Types" registry:
13 ID_NULL
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.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>,
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-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, DOI 10.17487/RFC4301,
December 2005, <<a href="http://www.rfc-editor.org/info/rfc4301">http://www.rfc-editor.org/info/rfc4301</a>>.
[<a id="ref-RFC5739">RFC5739</a>] Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", <a href="./rfc5739">RFC 5739</a>, DOI 10.17487/RFC5739, February 2010,
<<a href="http://www.rfc-editor.org/info/rfc5739">http://www.rfc-editor.org/info/rfc5739</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)", STD 79, <a href="./rfc7296">RFC 7296</a>, DOI 10.17487/RFC7296, 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-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-RFC7258">RFC7258</a>] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", <a href="https://www.rfc-editor.org/bcp/bcp188">BCP 188</a>, <a href="./rfc7258">RFC 7258</a>, DOI 10.17487/RFC7258, May
2014, <<a href="http://www.rfc-editor.org/info/rfc7258">http://www.rfc-editor.org/info/rfc7258</a>>.
[<a id="ref-RFC7435">RFC7435</a>] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", <a href="./rfc7435">RFC 7435</a>, DOI 10.17487/RFC7435,
December 2014, <<a href="http://www.rfc-editor.org/info/rfc7435">http://www.rfc-editor.org/info/rfc7435</a>>.
[<a id="ref-AUTOVPN">AUTOVPN</a>] Sheffer, Y. and Y. Nir, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22The+AutoVPN+Architecture%22'>"The AutoVPN Architecture"</a>, Work
in Progress, <a href="./draft-sheffer-autovpn-00">draft-sheffer-autovpn-00</a>, February 2014.
<span class="grey">Smyslov & Wouters Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
[<a id="ref-DDOS-PROTECTION">DDOS-PROTECTION</a>]
Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
(IKE) Implementations from Distributed Denial of Service
Attacks", Work in Progress, <a href="./draft-ietf-ipsecme-ddos-protection-02">draft-ietf-ipsecme-ddos-</a>
<a href="./draft-ietf-ipsecme-ddos-protection-02">protection-02</a>, July 2015.
<span class="grey">Smyslov & Wouters Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Update of PAD processing in <a href="./rfc4301">RFC 4301</a></span>
This appendix lists the specific updates of the text in <a href="./rfc4301#section-4.4.3">Section 4.4.3
of [RFC4301]</a> that should be followed when implementing NULL
authentication.
A new item is added to the list of supported ID types in
<a href="./rfc4301#section-4.4.3.1">Section 4.4.3.1 of [RFC4301]</a>
o NULL ID (matches ID type only)
and the following text is added at the end of the section:
Added text:
The NULL ID type is defined as having no data. For this name
type, the matching function is defined as comparing the ID type
only.
A new item is added to the list of authentication data types in
<a href="./rfc4301#section-4.4.3.2">Section 4.4.3.2 of [RFC4301]</a>:
- NULL authentication
and the next paragraph is updated as follows:
Old:
For authentication based on an X.509 certificate [...] For
authentication based on a pre-shared secret, the PAD contains the
pre-shared secret to be used by IKE.
New:
For authentication based on an X.509 certificate [...] For
authentication based on a pre-shared secret, the PAD contains the
pre-shared secret to be used by IKE. For NULL authentication the
PAD contains no data.
In addition, the following text is added at the end of
<a href="./rfc4301#section-4.4.3.4">Section 4.4.3.4 of [RFC4301]</a>:
Added text:
When using the NULL Authentication method, implementations MUST
make sure that they do not mix authenticated and unauthenticated
SPD rules, i.e., implementations need to keep them separately; for
example, by adding a flag in the SPD to tell whether NULL
authentication can be used or not for the entry. That is, each
SPD entry needs to be augmented to have a flag specifying whether
<span class="grey">Smyslov & Wouters Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7619">RFC 7619</a> NULL Auth in IKEv2 August 2015</span>
it can be used with NULL authentication or not, and only those
rules that explicitly have that flag set can be used with
unauthenticated connections.
Acknowledgments
The authors would like to thank Yaron Sheffer and Tero Kivinen for
their reviews, valuable comments, and contributed text.
Authors' Addresses
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd) 124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru
Paul Wouters
Red Hat
Email: pwouters@redhat.com
Smyslov & Wouters Standards Track [Page 12]
</pre>
|
