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
|
<pre>Network Working Group J. Kempf
Request for Comments: 5269 DoCoMo Labs USA
Category: Standards Track R. Koodli
Starent Networks
June 2008
<span class="h1">Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using</span>
<span class="h1">SEcure Neighbor Discovery (SEND)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Fast Mobile IPv6 requires that a Fast Binding Update is secured using
a security association shared between an Access Router and a Mobile
Node in order to avoid certain attacks. In this document, a method
for provisioning a shared key from the Access Router to the Mobile
Node is defined to protect this signaling. The Mobile Node generates
a public/private key pair using the same public key algorithm as for
SEND (<a href="./rfc3971">RFC 3971</a>). The Mobile Node sends the public key to the Access
Router. The Access Router encrypts a shared handover key using the
public key and sends it back to the Mobile Node. The Mobile Node
decrypts the shared handover key using the matching private key, and
the handover key is then available for generating an authenticator on
a Fast Binding Update. The Mobile Node and Access Router use the
Router Solicitation for Proxy Advertisement and Proxy Router
Advertisement from Fast Mobile IPv6 for the key exchange. The key
exchange messages are required to have SEND security; that is, the
source address is a Cryptographically Generated Address (CGA) and the
messages are signed using the CGA private key of the sending node.
This allows the Access Router, prior to providing the shared handover
key, to verify the authorization of the Mobile Node to claim the
address so that the previous care-of CGA in the Fast Binding Update
can act as the name of the key.
<span class="grey">Kempf & Koodli Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
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>. Overview of the Protocol ........................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Brief Review of SEND .......................................<a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Protocol Overview ..........................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Handover Key Provisioning and Use ...............................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Sending Router Solicitations for Proxy Advertisement .......<a href="#page-4">4</a>
3.2. Receiving Router Solicitations for Proxy
Advertisement and Sending Proxy Router Advertisements ......<a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Receiving Proxy Router Advertisements ......................<a href="#page-6">6</a>
<a href="#section-3.4">3.4</a>. Sending FBUs ...............................................<a href="#page-7">7</a>
<a href="#section-3.5">3.5</a>. Receiving FBUs .............................................<a href="#page-7">7</a>
<a href="#section-3.6">3.6</a>. Key Generation and Lifetime ................................<a href="#page-7">7</a>
<a href="#section-3.7">3.7</a>. Protocol Constants .........................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Message Formats .................................................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Handover Key Request Option ................................<a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Handover Key Reply Option .................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-12">12</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-12">12</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In Fast Mobile IPv6 (FMIPv6) [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>], a Fast Binding Update (FBU) is
sent from a Mobile Node (MN), undergoing IP handover, to the previous
Access Router (AR). The FBU causes a routing change so traffic sent
to the MN's previous Care-of Address on the previous AR's link is
tunneled to the new Care-of Address on the new AR's link. Only an MN
authorized to claim the address should be able to change the routing
for the previous Care-of Address. If such authorization is not
established, an attacker can redirect a victim MN's traffic at will.
In this document, a lightweight mechanism is defined by which a
shared handover key for securing FMIP can be provisioned on the MN by
the AR. The mechanism utilizes SEND [<a href="#ref-SEND" title=""SEcure Neighbor Discovery (SEND)"">SEND</a>] and an additional
public/private key pair, generated on the MN using the same public
key algorithm as SEND, to encrypt/decrypt a shared handover key sent
from the AR to the MN. The key provisioning occurs at some arbitrary
time prior to handover, thereby relieving any performance overhead on
the handover process. The message exchange between the MN and AR to
provision the handover key is required to be protected by SEND; that
is, the source address for the key provisioning messages must be a
CGA and the messages must be signed with the CGA private key. This
allows the AR to establish the MN's authorization to operate on the
<span class="grey">Kempf & Koodli Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
CGA. The AR uses the CGA to name the handover key. The SEND key
pair is, however, independent from the handover encryption/decryption
key pair and from the actual handover key. Once the shared handover
key has been established, when the MN undergoes IP handover, the MN
generates an authorization Message Authentication Code (MAC) on the
FBU. The previous care-of CGA included in the FBU is used by the AR
to find the right handover key for checking the authorization.
Handover keys are an instantiation of the purpose built key
architectural principle [<a href="#ref-PBK" title=""A Framework for Purpose-Built Keys (PBK)"">PBK</a>].
<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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
In addition, the following terminology is used:
CGA public key
Public key used to generate the CGA according to <a href="./rfc3972">RFC 3972</a>
[<a href="#ref-CGA" title=""Cryptographically Generated Addresses (CGA)"">CGA</a>].
CGA private key
Private key corresponding to the CGA public key.
Handover key encryption public key
Public key generated by the MN and sent to the current AR to
encrypt the shared handover key.
Handover key encryption private key
Private key corresponding to handover key encryption public
key, held by the MN.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview of the Protocol</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Brief Review of SEND</span>
SEND protects against a variety of threats to local link address
resolution (also known as Neighbor Discovery) and last hop router
(AR) discovery in IPv6 [<a href="./rfc3756" title=""IPv6 Neighbor Discovery (ND) Trust Models and Threats"">RFC3756</a>]. These threats are not exclusive to
wireless networks, but they generally are easier to mount on certain
wireless networks because the link between the access point and MN
can't be physically secured.
<span class="grey">Kempf & Koodli Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
SEND utilizes CGAs in order to secure Neighbor Discovery signaling
[<a href="#ref-CGA" title=""Cryptographically Generated Addresses (CGA)"">CGA</a>]. Briefly, a CGA is formed by hashing together the IPv6 subnet
prefix for a node's subnet, a random nonce, and an RSA public key,
called the CGA public key. The CGA private key is used to sign a
Neighbor Advertisement (NA) message sent to resolve the link-layer
address to the IPv6 address. The combination of the CGA and the
signature on the NA proves to a receiving node the sender's
authorization to claim the address. The node may opportunistically
generate one or several keys specifically for SEND, or it may use a
certified key that it distributes more widely.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Protocol Overview</span>
The protocol utilizes the SEND secured Router Solicitation for Proxy
Advertisement (RtSolPr)/Proxy Router Advertisement (PrRtAdv) [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>]
exchange between the MN and the AR to transport an encrypted, shared
handover key from the AR to the MN. First, the MN generates the
necessary key pair and associated CGA addresses so that the MN can
employ SEND. Then, the MN generates a public/private key pair for
encrypting/decrypting the shared handover key, using the same public
key algorithm as was used for SEND. The MN then sends an RtSolPr
message with a Handover Key Request Option containing the handover
key encryption public key. The source address of the RtSolPr message
is the MN's care-of CGA on the AR's link, the RtSolPr message is
signed with the MN's CGA key, and contains the CGA Parameters option,
in accordance with <a href="./rfc3971">RFC 3971</a> [<a href="#ref-SEND" title=""SEcure Neighbor Discovery (SEND)"">SEND</a>]. The AR verifies the message
using SEND, then utilizes the handover key encryption public key to
encrypt a shared handover key, which is included with the PrRtAdv in
the Handover Key Reply Option. The MN decrypts the shared handover
key and uses it to establish an authorization MAC when it sends an
FBU to the previous AR.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Handover Key Provisioning and Use</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Sending Router Solicitations for Proxy Advertisement</span>
At some time prior to handover, the MN MUST generate a handover key
encryption public/private key pair, using exactly the same public key
algorithm with exactly the same parameters (key size, etc.) as for
SEND [<a href="#ref-SEND" title=""SEcure Neighbor Discovery (SEND)"">SEND</a>]. The MN can reuse the key pair on different access
routers but MUST NOT use the key pair for any other encryption or for
signature operation. In order to prevent cryptanalysis, the key pair
SHOULD be discarded after either a duration of HKEPK-LIFETIME or
HKEPK-HANDOVERS number of handovers, whichever occurs first. See
<a href="#section-3.7">Section 3.7</a> for definitions of protocol constants.
<span class="grey">Kempf & Koodli Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
The MN MUST send a Router Solicitation for Proxy Advertisement
(RtSolPr) containing a Handover Key Request Option with the handover
encryption public key. A CGA for the MN MUST be the source address
on the packet, and the MN MUST include the SEND CGA Option and SEND
Signature Option with the packet, as specified in [<a href="#ref-SEND" title=""SEcure Neighbor Discovery (SEND)"">SEND</a>]. The SEND
signature covers all fields in the RtSolPr, including the 128-bit
source and destination addresses and ICMP checksum as described in
<a href="./rfc3971">RFC 3971</a>, except for the Signature Option itself. The MN also sets
the handover authentication Algorithm Type (AT) extension field in
the Handover Key Request Option to the MN's preferred FBU
authentication algorithm. The SEND Nonce MUST also be included for
anti-replay protection.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Receiving Router Solicitations for Proxy Advertisement and Sending</span>
<span class="h3"> Proxy Router Advertisements</span>
When an FMIPv6 capable AR with SEND receives an RtSolPr from an MN
protected with SEND and including a Handover Key Request Option, the
AR MUST first validate the RtSolPr using SEND as described in <a href="./rfc3971">RFC</a>
<a href="./rfc3971">3971</a>. If the RtSolPr can not be validated, the AR MUST NOT include a
Handover Key Reply Option in the reply. The AR also MUST NOT change
any existing key record for the address, since the message may be an
attempt by an attacker to disrupt communications for a legitimate MN.
The AR SHOULD respond to the RtSolPr but MUST NOT perform handover
key provisioning.
If the RtSolPr can be validated, the AR MUST then determine whether
the CGA is already associated with a shared handover key. If the CGA
is associated with an existing handover key, the AR MUST return the
existing handover key to the MN. If the CGA does not have a shared
handover key, the AR MUST construct a shared handover key as
described in <a href="#section-3.6">Section 3.6</a>. The AR MUST encrypt the handover key with
the handover key encryption public key included in the Handover Key
Request Option. The AR MUST insert the encrypted handover key into a
Handover Key Reply Option and MUST attach the Handover Key Reply
Option to the PrRtAdv. The lifetime of the key, HK-LIFETIME, MUST
also be included in the Handover Key Reply Option. The AR SHOULD set
the AT field of the Handover Key Option to the MN's preferred
algorithm type indicated in the AT field of the Handover Key Request
Option, if it is supported; otherwise, the AR MUST select an
authentication algorithm that is of equivalent strength or stronger,
and set the field to that. The AR MUST also include the SEND nonce
from the RtSolPr for anti-replay protection. The AR MUST have a
certificate suitable for a SEND-capable router, support SEND
certificate discovery, and include a SEND CGA Option and a SEND
Signature Option in the PrRtAdv messages it sends. Similarly, the
mobile nodes MUST be configured with one or more SEND trust anchors
so that they can verify these messages. The SEND signature covers
<span class="grey">Kempf & Koodli Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
all fields in the PrRtAdv, including the 128-bit source and
destination addresses and ICMP checksum as described in <a href="./rfc3971">RFC 3971</a>,
except for the Signature Option itself. The PrRtAdv is then unicast
back to the MN at the MN's care-of CGA that was the source address on
the RtSolPr. The handover key MUST be stored by the AR for future
use, indexed by the CGA, and the authentication algorithm type (i.e.,
the resolution of the AT field processing) and HK-LIFETIME MUST be
recorded with the key.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Receiving Proxy Router Advertisements</span>
Upon receipt of one or more PrRtAdvs secured with SEND and having the
Handover Key Reply Option, the MN MUST first validate the PrRtAdvs as
described in <a href="./rfc3971">RFC 3971</a>. Normally, the MN will have obtained the
router's certification path to validate an RA prior to sending the
PrRtSol and the MN MUST check to ensure that the key used to sign the
PrRtAdv is the router's certified public key. If the MN does not
have the router's certification path cached, it MUST use the SEND
CPS/CPA messages to obtain the certification path to validate the
key. If a certified key from the router was not used to sign the
message, the message MUST be dropped.
From the messages that validate, the MN SHOULD choose one with an AT
flag in the Handover Key Reply Option indicating an authentication
algorithm that the MN supports. From that message, the MN MUST
determine which handover key encryption public key to use in the
event the MN has more than one. The MN finds the right public key to
use by matching the SEND nonce from the RtSolPr. If no such match
occurs, the MN MUST drop the PrRtAdv. The MN MUST use the matching
private key to decrypt the handover key using its handover key
encryption private key, and store the handover key for later use,
named with the AR's CGA, along with the algorithm type and
HK-LIFETIME. The MN MUST use the returned algorithm type indicated
in the PrRtAdv. The MN MUST index the handover keys with the AR's
IPv6 address, to which the MN later sends the FBU, and the MN's CGA
to which the handover key applies. This allows the MN to select the
proper key when communicating with a previous AR. Prior to
HK-LIFETIME expiring, the MN MUST request a new key from the AR if
FMIPv6 service is still required from the router.
If more than one router responds to the RtSolPr, the MN MAY keep
track of all such keys. If none of the PrRtAdvs contains an
algorithm type indicator corresponding to an algorithm the MN
supports, the MN MAY re-send the RtSolPr requesting a different
algorithm, but to prevent bidding down attacks from compromised
routers, the MN SHOULD NOT request an algorithm that is weaker than
its original request.
<span class="grey">Kempf & Koodli Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Sending FBUs</span>
When the MN needs to signal the Previous AR (PAR) using an FMIPv6
FBU, the MN MUST utilize the handover key and the corresponding
authentication algorithm to generate an authenticator for the
message. The MN MUST select the appropriate key for the PAR using
the PAR's CGA and the MN's previous care-of CGA on the PAR's link.
As defined by the FMIPv6 [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>], the MN MUST generate the
authentication MAC using the handover key and the appropriate
algorithm and MUST include the MAC in the FBU message. As specified
by FMIPv6, the MN MUST include the old care-of CGA in a Home Address
Option. The FMIPv6 document provides more detail about the
construction of the authenticator on the FBU.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Receiving FBUs</span>
When the PAR receives an FBU message containing an authenticator, the
PAR MUST find the corresponding handover key using the MN's care-of
CGA in the Home Address Option as the index. If a handover key is
found, the PAR MUST utilize the handover key and the appropriate
algorithm to verify the authenticator. If the handover key is not
found, the PAR MUST NOT change forwarding for the care-of CGA. The
FMIPv6 document [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>] provides more detail on how the AR processes
an FBU containing an authenticator.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Key Generation and Lifetime</span>
The AR MUST randomly generate a key having sufficient strength to
match the authentication algorithm. Some authentication algorithms
specify a required key size. The AR MUST generate a unique key for
each CGA public key, and SHOULD take care that the key generation is
uncorrelated between handover keys, and between handover keys and CGA
keys. The actual algorithm used to generate the key is not important
for interoperability since only the AR generates the key; the MN
simply uses it.
A PAR SHOULD NOT discard the handover key immediately after use if it
is still valid. It is possible that the MN may undergo rapid
movement to another AR prior to the completion of Mobile IPv6 binding
update on the PAR, and the MN MAY as a consequence initialize
another, subsequent handover optimization to move traffic from the
PAR to another new AR. The default time for keeping the key valid
corresponds to the default time during which forwarding from the PAR
to the new AR is performed for FMIP. The FMIPv6 document [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>]
provides more detail about the FMIP forwarding time default.
If the MN returns to a PAR prior to the expiration of the handover
key, the PAR MAY send and the MN MAY receive the same handover key as
<span class="grey">Kempf & Koodli Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
was previously returned, if the MN generates the same CGA for its
Care-of Address. However, the MN MUST NOT assume that it can
continue to use the old key without actually receiving the handover
key again from the PAR. The MN SHOULD discard the handover key after
MIPv6 binding update is complete on the new AR. The PAR MUST discard
the key after FMIPv6 forwarding for the previous Care-of Address
times out or when HK-LIFETIME expires.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Protocol Constants</span>
The following are protocol constants with suggested defaults:
HKEPK-LIFETIME: The maximum lifetime for the handover key
encryption public key. Default is 12 hours.
HKEPK-HANDOVERS: The maximum number of handovers for which the
handover key encryption public key should be
reused. Default is 10.
HK-LIFETIME: The maximum lifetime for the handover key. Default
is 12 hours (43200 seconds).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Message Formats</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Handover Key Request Option</span>
The Handover Key Request Option is a standard IPv6 Neighbor Discovery
[<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] option in TLV format. The Handover Key Request Option is
included in the RtSolPr message along with the SEND CGA Option, RSA
Signature Option, and Nonce Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Handover Key Encryption Public Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Kempf & Koodli Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
Fields:
Type: 27
Length: The length of the option in units of 8 octets,
including the Type and Length fields. The value 0
is invalid. The receiver MUST discard a message
that contains this value.
Pad Length: The number of padding octets beyond the end of the
Handover Key Encryption Public Key field but within
the length specified by the Length field. Padding
octets MUST be set to zero by senders and ignored
by receivers.
AT: A 4-bit algorithm type field describing the
algorithm used by FMIPv6 to calculate the
authenticator. See [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>] for details.
Resrvd.: A 4-bit field reserved for future use. The value
MUST be initialized to zero by the sender and MUST
be ignored by the receiver.
Handover Key Encryption Public Key:
The handover key encryption public key. The key
MUST be formatted according to the same
specification as the CGA key in the CGA Parameters
Option [<a href="#ref-CGA" title=""Cryptographically Generated Addresses (CGA)"">CGA</a>] of the message, and MUST have the same
parameters as the CGA key.
Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as
specified in the Pad Length field.
<span class="grey">Kempf & Koodli Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Handover Key Reply Option</span>
The Handover Key Reply Option is a standard IPv6 Neighbor Discovery
[<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] option in TLV format. The Handover Key Reply Option is
included in the PrRtAdv message along with the SEND CGA Option, RSA
Signature Option, and Nonce Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | AT |Resrvd.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. .
. Encrypted Handover Key .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: 28
Length: The length of the option in units of 8 octets,
including the Type and Length fields. The value 0
is invalid. The receiver MUST discard a message
that contains this value.
Pad Length: The number of padding octets beyond the end of the
Encrypted Handover Key field but within the length
specified by the Length field. Padding octets MUST
be set to zero by senders and ignored by receivers.
AT: A 4-bit algorithm type field describing the
algorithm used by FMIPv6 to calculate the
authenticator. See [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>] for details.
<span class="grey">Kempf & Koodli Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
Resrvd.: A 4-bit field reserved for future use. The value
MUST be initialized to zero by the sender and MUST
be ignored by the receiver.
Key Lifetime: Lifetime of the handover key, HK-LIFETIME, in
seconds.
Encrypted Handover Key:
The shared handover key, encrypted with the MN's
handover key encryption public key, using the
RSAES-PKCS1-v1_5 format [<a href="./rfc3447" title=""Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1"">RFC3447</a>].
Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as
specified in the Pad Length field.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document describes a shared key provisioning protocol for the
FMIPv6 handover optimization protocol. The key provisioning protocol
utilizes a public key generated with the same public key algorithm as
SEND to bootstrap a shared key for authorizing changes due to
handover associated with the MN's former address on the PAR. General
security considerations involving CGAs apply to the protocol
described in this document, see [<a href="#ref-CGA" title=""Cryptographically Generated Addresses (CGA)"">CGA</a>] for a discussion of security
considerations around CGAs. This protocol is subject to the same
risks from replay attacks and denial-of-service (DoS) attacks using
the RtSolPr as the SEND protocol [<a href="#ref-SEND" title=""SEcure Neighbor Discovery (SEND)"">SEND</a>] for RS. The measures
recommended in <a href="./rfc3971">RFC 3971</a> for mitigating replay attacks and DoS attacks
apply here as well. An additional consideration involves when to
generate the handover key on the AR. To avoid state depletion
attacks, the handover key SHOULD NOT be generated prior to SEND
processing that verifies the originator of RtSolPr. State depletion
attacks can be addressed by techniques, such as rate limiting
RtSolPr, restricting the amount of state reserved for unresolved
solicitations, and clever cache management. These techniques are the
same as used in implementing Neighbor Discovery.
For other FMIPv6 security considerations, please see the FMIPv6
document [<a href="#ref-FMIP" title=""Mobile IPv6 Fast Handovers"">FMIP</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
IANA has assigned IPv6 Neighbor Discovery option type codes for the
two new IPv6 Neighbor Discovery options, the Handover Key Request
Option (27) and Handover Key Reply Option (28), defined in this
document.
<span class="grey">Kempf & Koodli Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-FMIP">FMIP</a>] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", <a href="./rfc5268">RFC 5268</a>,
June 2008.
[<a id="ref-SEND">SEND</a>] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", <a href="./rfc3971">RFC 3971</a>, March 2005.
[<a id="ref-CGA">CGA</a>] Aura, T., "Cryptographically Generated Addresses (CGA)",
<a href="./rfc3972">RFC 3972</a>, March 2005.
[<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-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
September 2007.
[<a id="ref-RFC3447">RFC3447</a>] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", <a href="./rfc3447">RFC 3447</a>, February 2003.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC3756">RFC3756</a>] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", <a href="./rfc3756">RFC</a>
<a href="./rfc3756">3756</a>, May 2004.
[<a id="ref-PBK">PBK</a>] Bradner, S., Mankin, A., and Schiller, J., "A Framework for
Purpose-Built Keys (PBK)", Work in Progress, June 2003.
Progress.
<span class="grey">Kempf & Koodli Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
Authors' Addresses
James Kempf
DoCoMo Labs USA
3240 Hillview Avenue
Palo Alto, CA 94303
USA
Phone: +1 650 496 4711
EMail: kempf@docomolabs-usa.com
Rajeev Koodli
Starent Networks
30 International Place
Tewksbury, MA 01876
USA
Phone: +1 408 735 7679
EMail: rkoodli@starentnetworks.com
<span class="grey">Kempf & Koodli Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5269">RFC 5269</a> FMIP Security June 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Kempf & Koodli Standards Track [Page 14]
</pre>
|
