1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
|
<pre>Internet Engineering Task Force (IETF) V. Cakulev
Request for Comments: 6738 Alcatel Lucent
Category: Standards Track A. Lior
ISSN: 2070-1721 Bridgewater Systems
S. Mizikovsky
Alcatel Lucent
October 2012
<span class="h1">Diameter IKEv2 SK: Using Shared Keys to Support Interaction between</span>
<span class="h1">IKEv2 Servers and Diameter Servers</span>
Abstract
The Internet Key Exchange Protocol version 2 (IKEv2) is a component
of the IPsec architecture and is used to perform mutual
authentication as well as to establish and to maintain IPsec Security
Associations (SAs) between the respective parties. IKEv2 supports
several different authentication mechanisms, such as the Extensible
Authentication Protocol (EAP), certificates, and Shared Key (SK).
Diameter interworking for Mobile IPv6 between the Home Agent (HA), as
a Diameter client, and the Diameter server has been specified.
However, that specification focused on the usage of EAP and did not
include support for SK-based authentication available with IKEv2.
This document specifies the IKEv2-server-to-Diameter-server
communication when the IKEv2 peer authenticates using IKEv2 with SK.
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/rfc6738">http://www.rfc-editor.org/info/rfc6738</a>.
<span class="grey">Cakulev, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
Copyright Notice
Copyright (c) 2012 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-2">2</a>. Requirements Notation ...........................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Abbreviations ..............................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Application Identifier ..........................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Protocol Description ............................................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Support for IKEv2 and Shared Keys ..........................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Session Management .........................................<a href="#page-7">7</a>
<a href="#section-4.2.1">4.2.1</a>. Session-Termination-Request/Answer ..................<a href="#page-7">7</a>
<a href="#section-4.2.2">4.2.2</a>. Abort-Session-Request/Answer ........................<a href="#page-7">7</a>
<a href="#section-5">5</a>. Command Codes for Diameter IKEv2 with SK ........................<a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. IKEv2-SK-Request (IKESKR) Command ..........................<a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. IKEv2-SK-Answer (IKESKA) Command ...........................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Attribute-Value Pair Definitions ...............................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. IKEv2-Nonces ..............................................<a href="#page-10">10</a>
<a href="#section-6.1.1">6.1.1</a>. Ni .................................................<a href="#page-10">10</a>
<a href="#section-6.1.2">6.1.2</a>. Nr .................................................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. IKEv2-Identity ............................................<a href="#page-10">10</a>
<a href="#section-6.2.1">6.2.1</a>. Initiator-Identity .................................<a href="#page-10">10</a>
<a href="#section-6.2.2">6.2.2</a>. Responder-Identity .................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. AVP Occurrence Tables ..........................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. AVP Flag Rules .................................................<a href="#page-13">13</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-14">14</a>
<a href="#section-9.1">9.1</a>. Command Codes .............................................<a href="#page-14">14</a>
<a href="#section-9.2">9.2</a>. AVP Codes .................................................<a href="#page-14">14</a>
<a href="#section-9.3">9.3</a>. AVP Values ................................................<a href="#page-14">14</a>
<a href="#section-9.4">9.4</a>. Application Identifier ....................................<a href="#page-14">14</a>
<a href="#section-10">10</a>. Security Considerations .......................................<a href="#page-15">15</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-16">16</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-16">16</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-16">16</a>
<span class="grey">Cakulev, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Internet Key Exchange Protocol version 2 (IKEv2) [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>] is
used to mutually authenticate two parities and to establish a
Security Association (SA) that can be used to efficiently secure the
communication between the IKEv2 peer and server, for example, using
Encapsulating Security Payload (ESP) [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] and/or Authentication
Header (AH) [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>]. The IKEv2 protocol allows several different
mechanisms for authenticating an IKEv2 peer to be used, such as the
Extensible Authentication Protocol (EAP), certificates, and SK.
From a service provider perspective, it is important to ensure that a
user is authorized to use the services. Therefore, the IKEv2 server
must verify that the IKEv2 peer is authorized for the requested
services, possibly with the assistance of the operator's Diameter
servers. [<a href="./rfc5778" title=""Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction"">RFC5778</a>] defines the home agent as a Diameter-client-to-
Diameter-server communication when the mobile node authenticates
using the IKEv2 protocol with the Extensible Authentication Protocol
(EAP) [<a href="./rfc3748" title=""Extensible Authentication Protocol (EAP)"">RFC3748</a>] or using the Mobile IPv6 Authentication Protocol
[<a href="./rfc4285" title=""Authentication Protocol for Mobile IPv6"">RFC4285</a>]. This document specifies the IKEv2-server-to-Diameter-
server communication when the IKEv2 peer authenticates using IKEv2
with SK.
Figure 1 depicts the reference architecture for this document.
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | IKEv2 Server<->HAAA Server
Support | Interaction
Protocol | (this document)
v
+---------+ +---------------+
| IKEv2 | Front-End Protocol |IKEv2 Server/ |
| Peer |<-------------------->|Diameter Client|
+---------+ IKEv2 +---------------+
Figure 1: Architecture Overview
An example use case for this architecture is Mobile IPv6 deployment
in which the Mobile IPv6 signaling between the Mobile Node and the
Home Agent is protected using IPsec. The Mobile node acts as the
IKEv2 peer and the Home Agent acts as an IKEv2 server. In this use
case, IKEv2 with SK-based initiator authentication is used for the
setup of the IPsec SAs. The HA obtains the SK using the Diameter
application specified in this document.
<span class="grey">Cakulev, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
This document assumes that the SK provided to the IKEv2 peer as well
as the SK delivered to the IKEv2 server by the Diameter server are
established or derived using the same rules. Furthermore, it assumes
that these rules are agreed to by the external protocol on a peer
side providing the key to the IKEv2 peer, and on the Diameter server
side providing the key to the IKEv2 server. This document allows for
the SK to be obtained for a specific IKEv2 session and exchanged
between IKEv2 server and the Home Authentication, Authorization, and
Accounting (HAAA) server. The protocol provides IKEv2 attributes to
allow the HAAA to compute the SK specific to the session if desired
(see <a href="#section-10">Section 10</a>). This is accomplished through the use of a new
Diameter application specifically designed for performing IKEv2
authorization decisions. This document focuses on the IKEv2 server,
as a Diameter client, communicating to the Diameter server, and it
specifies the Diameter application needed for this communication.
Other protocols leveraging this Diameter application MAY specify
their own SK derivation scheme. For example see [<a href="#ref-X.S0047" title=""Mobile IPv6 Enhancements"">X.S0047</a>] and
[<a href="#ref-X.S0058" title=""WiMAX-HRPD Interworking: Core Network Aspects"">X.S0058</a>]. This document specifies the default procedure for
derivation of the SK used in IKEv2 authentication when protocols
leveraging this Diameter application do not specify their own
derivation procedure. Selection of either default or other SK
derivation procedure is done by the external protocol between the
Peer and the Diameter Server, and is outside the scope of this
document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Notation</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="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Abbreviations</span>
AH Authentication Header
AVP Attribute-Value Pair
EAP Extensible Authentication Protocol
ESP Encapsulating Security Payload
HAAA Home Authentication, Authorization, and Accounting
IKEv2 Internet Key Exchange Protocol version 2
NAI Network Access Identifier
PSK Pre-Shared Key
<span class="grey">Cakulev, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
SA Security Association
SK Shared Key
SPI Security Parameter Index
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Application Identifier</span>
This specification defines a new Diameter application and its
respective Application Identifier:
Diameter IKE SK (IKESK) 11
The IKESK Application Identifier is used when the IKEv2 peer is to be
authenticated and authorized using IKEv2 with SK-based
authentication.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Description</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Support for IKEv2 and Shared Keys</span>
When IKEv2 is used with SK-based initiator authentication, the
Diameter commands IKEv2-SK-Request/Answer defined in this document
are used between the IKEv2 server and a Home AAA (HAAA) server to
authorize the IKEv2 peer for the services. Upon receiving the
IKE_AUTH message from the IKEv2 peer, the IKEv2 server uses the
information received in IDi [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>] to identify the IKEv2 peer and
the SPI, if available, to determine the correct SK for this IKEv2
peer. If no SK associated with this IKEv2 peer is found, the IKEv2
server MUST send an Authorize-Only (Auth-Request-Type set to
"Authorize-Only") Diameter IKEv2-SK-Request message to the HAAA to
obtain the SK. If the IDi payload extracted from the IKE_AUTH
message contains an identity that is meaningful for the Diameter
infrastructure, such as a Network Access Identifier (NAI), it SHALL
be used by the IKEv2 server to populate the User-Name AVP in the
Diameter message. Otherwise, it is out of scope of this document how
the IKEv2 server maps the value received in the IDi payload to the
User-Name AVP and whether or not the User-Name AVP is included in the
IKEv2-SK-Request message. In the same Diameter message, the IKEv2
server SHALL also include the IKEv2-Nonces AVP with the initiator and
responder nonces (Ni and Nr) exchanged during initial IKEv2 exchange.
Finally, the IKEv2 server SHALL include the IKEv2-Identity AVP in the
IKEv2-SK-Request message. The Initiator-Identity AVP SHALL be
populated with the IDi field extracted from the IKE_AUTH message. If
the IDr payload was included in the IKE_AUTH message received from
the IKEv2 peer, the IKEv2 server SHALL also include a Responder-
Identity AVP populated with the received IDr.
<span class="grey">Cakulev, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
The IKEv2 server sends the IKEv2-SK-Request message to the IKEv2
peer's HAAA. The Diameter message is routed to the correct HAAA per
[<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>].
Upon receiving a Diameter IKEv2-SK-Request message from the IKEv2
server, the HAAA SHALL use the User-Name AVP (if present) and/or
Initiator-Identity AVP to retrieve the associated keying material.
When the default SK-generation procedure specified in this document
is used, the peer side that provides the SK to the IKEv2 peer, as
well as the Diameter server, SHALL use the same SK derivation that
follows the methodology similar to that specified in <a href="./rfc5295#section-3.1">Section 3.1 of
[RFC5295]</a>, specifically:
SK = KDF(PSK, key label | "\0" | Ni | Nr | IDi | length)
Where:
o KDF is the default key derivation function based on HMAC-SHA-256
as specified in <a href="./rfc5295#section-3.1.2">Section 3.1.2 of [RFC5295]</a>.
o Pre-Shared Key (PSK) is the key available to the protocol
leveraging this Diameter application, e.g., the long-term shared
secret, or the Extended Master Session Key (EMSK) as the result of
prior EAP authentication, etc. Selection of this value is left up
to the protocol leveraging this Diameter application.
o Key label is set to 'sk4ikev2@ietf.org'.
o | denotes concatenation
o "\0" is a NULL octet (0x00 in hex)
o Length is a 2-octet unsigned integer in network byte order of the
output key length, in octets.
When applications using this protocol define their own SK-generation
algorithm, it is strongly RECOMMENDED that the nonces Ni and Nr be
used in the computation. It is also RECOMMENDED that IDi be used.
IDr SHOULD NOT be used in the SK generation algorithm. Applications
that want to use IDr in the computation should take into
consideration that the IDr asserted by the IKEv2 peer may not be the
same as the IDr returned by the IKEv2 responder. This mismatch will
result in different SKs being generated. The HAAA returns the SK to
the IKEv2 server using the Key AVP as specified in [<a href="./rfc6734" title=""Diameter Attribute- Value Pairs for Cryptographic Key Transport"">RFC6734</a>].
<span class="grey">Cakulev, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
Once the IKEv2 server receives the SK from the HAAA, the IKEv2 server
verifies the IKE_AUTH message received from the IKEv2 peer. If the
verification of AUTH is successful, the IKEv2 server sends the IKE
message back to the IKEv2 peer.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Session Management</span>
The HAAA may maintain Diameter session state or may be stateless.
This is indicated by the presence or absence of the Auth-Session-
State AVP included in the answer message. The IKEv2 server MUST
support the Authorization Session State Machine defined in [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>].
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Session-Termination-Request/Answer</span>
In the case where the HAAA is maintaining session state, when the
IKEv2 server terminates the SA, it SHALL send a Session-Termination-
Request (STR) message [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>] to inform the HAAA that the
authorized session has been terminated.
The Session-Termination-Answer (STA) message [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>] is sent by the
HAAA to acknowledge the notification that the session has been
terminated.
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Abort-Session-Request/Answer</span>
The Abort-Session-Request (ASR) message [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>] is sent by the HAAA
to the IKEv2 server to terminate the authorized session. When the
IKEv2 server receives the ASR message, it MUST delete the
corresponding IKE_SA and all CHILD_SAs set up through it.
The Abort-Session-Answer (ASA) message [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>] is sent by the IKEv2
server in response to an ASR message.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Command Codes for Diameter IKEv2 with SK</span>
This section defines new Command Code values that MUST be supported
by all Diameter implementations conforming to this specification.
+------------------+---------+------+-----------------+-------------+
| Command Name | Abbrev. | Code | Section | Application |
| | | | Reference | |
+------------------+---------+------+-----------------+-------------+
| IKEv2-SK-Request | IKESKR | 329 | <a href="#section-5.1">Section 5.1</a> | IKESK |
| | | | | |
| IKEv2-SK-Answer | IKESKA | 329 | <a href="#section-5.2">Section 5.2</a> | IKESK |
+------------------+---------+------+-----------------+-------------+
Table 1: Command Codes
<span class="grey">Cakulev, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. IKEv2-SK-Request (IKESKR) Command</span>
The IKEv2-SK-Request message, indicated with the Command Code set to
329 and the 'R' bit set in the Command Flags field, is sent from the
IKEv2 server to the HAAA to initiate IKEv2 with SK authorization. In
this case, the Application-Id field of the Diameter header MUST be
set to the Diameter IKE SK Application-Id (11).
Message format
<IKEv2-SK-Request> ::= < Diameter Header: 329, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ Origin-State-Id ]
[ User-Name ]
[ Key-SPI ]
{ IKEv2-Identity }
[ Auth-Session-State ]
{ IKEv2-Nonces }
* [ Proxy-Info ]
* [ Route-Record ]
...
* [ AVP ]
The IKEv2-SK-Request message MUST include an IKEv2-Nonces AVP
containing the Ni and Nr nonces swapped during initial IKEv2
exchange. The IKEv2-SK-Request message MAY contain a Key-SPI AVP
(Key-SPI AVP is specified in [<a href="./rfc6734" title=""Diameter Attribute- Value Pairs for Cryptographic Key Transport"">RFC6734</a>]). If included, it contains
the SPI that HAAA SHALL use, in addition to the other parameters
(e.g., Initiator-Identity), to identify the appropriate SK. The
IKEv2-SK-Request message MUST include IKEv2-Identity AVP. The
Initiator-Identity AVP SHALL contain IDi as received in IKE_AUTH
message. The Responder-Identity AVP SHALL be included in the IKEv2-
SK-Request message, if IDr payload was included in the IKE_AUTH
message received from the IKEv2 peer. If included, the Responder-
Identity AVP contains the received IDr.
<span class="grey">Cakulev, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. IKEv2-SK-Answer (IKESKA) Command</span>
The IKEv2-SK-Answer (IKESKA) message, indicated by the Command Code
field set to 329 and the 'R' bit cleared in the Command Flags field,
is sent by the HAAA to the IKEv2 server in response to the IKESKR
command. In this case, the Application-Id field of the Diameter
header MUST be set to the Diameter IKE SK Application-Id (11).
Message format
<IKEv2-SK-Answer> ::= < Diameter Header: 329, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Key ]
[ Responder-Identity ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
...
* [ AVP ]
If the authorization procedure is successful, then the IKEv2-SK-
Answer message SHALL include the Key AVP as specified in [<a href="./rfc6734" title=""Diameter Attribute- Value Pairs for Cryptographic Key Transport"">RFC6734</a>].
The value of the Key-Type AVP SHALL be set to IKEv2 SK (3). The
Keying-Material AVP SHALL contain the SK. If the Key-SPI AVP is
received in IKEv2-SK-Request, the Key-SPI AVP SHALL be included in
the Key AVP. The Key-Lifetime AVP may be included; if so, then the
associated key SHALL NOT be used by the receiver of the answer if the
lifetime has expired. Finally, the Responder-Identity AVP may be
included.
<span class="grey">Cakulev, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Attribute-Value Pair Definitions</span>
This section defines new AVPs for IKEv2 with SK.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. IKEv2-Nonces</span>
The IKEv2-Nonces AVP (Code 587) is of type Grouped and contains the
nonces exchanged between the IKEv2 peer and the IKEv2 server during
IKEv2 initial exchange. The nonces are used for SK generation.
IKEv2-Nonces ::= < AVP Header: 587 >
{Ni}
{Nr}
*[AVP]
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Ni</span>
The Ni AVP (AVP Code 588) is of type OctetString and contains the
IKEv2 initiator nonce as contained in Nonce Data field.
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Nr</span>
The Nr AVP (AVP Code 589) is of type OctetString and contains the
IKEv2 responder nonce as contained in Nonce Data field.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. IKEv2-Identity</span>
The IKEv2-Identity AVP (Code 590) is of type Grouped and contains the
Initiator and possibly Responder identities as included in IKE_AUTH
message sent from the IKEv2 peer to the IKEv2 server.
IKEv2-Identity ::= < AVP Header: 590 >
{Initiator-Identity}
[Responder-Identity]
*[AVP]
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Initiator-Identity</span>
The Initiator-Identity AVP (AVP Code 591) is of type Grouped and
contains the identity type and identification data of the IDi payload
of the IKE_AUTH message.
Initiator-Identity ::= < AVP Header: 591 >
{ID-Type}
{Identification-Data}
*[AVP]
<span class="grey">Cakulev, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h5"><a class="selflink" id="section-6.2.1.1" href="#section-6.2.1.1">6.2.1.1</a>. ID-Type</span>
The ID-Type AVP (AVP Code 592) is of type Enumerated and contains the
ID type value of IDi payload of the IKE_AUTH message.
<span class="h5"><a class="selflink" id="section-6.2.1.2" href="#section-6.2.1.2">6.2.1.2</a>. Identification-Data</span>
The Identification-Data AVP (AVP Code 593) is of type OctetString and
contains the Identification Data field of IDi payload of the IKE_AUTH
message.
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Responder-Identity</span>
The Responder-Identity AVP (AVP Code 594) is of type Grouped and
contains the identity type and identification data of the IDr payload
of the IKE_AUTH message.
Responder-Identity ::= < AVP Header: 594 >
{ID-Type}
{Identification-Data}
*[AVP]
<span class="h5"><a class="selflink" id="section-6.2.2.1" href="#section-6.2.2.1">6.2.2.1</a>. ID-Type</span>
The ID-Type AVP (AVP Code 592) is of type Enumerated and contains the
ID type value of IDr payload of the IKE_AUTH message.
<span class="h5"><a class="selflink" id="section-6.2.2.2" href="#section-6.2.2.2">6.2.2.2</a>. Identification-Data</span>
The Identification-Data AVP (AVP Code 593) is of type OctetString and
contains the Identification Data field of IDr payload of the IKE_AUTH
message.
<span class="grey">Cakulev, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. AVP Occurrence Tables</span>
The following tables present the AVPs defined or used in this
document and their occurrences in Diameter messages. Note that AVPs
that can only be present within a Grouped AVP are not represented in
this table.
The table uses the following symbols:
0: The AVP MUST NOT be present in the message.
0+: Zero or more instances of the AVP MAY be present in the
message.
0-1: Zero or one instance of the AVP MAY be present in the
message.
1: One instance of the AVP MUST be present in the message.
+-------------------+
| Command Code |
|---------+---------+
AVP Name | IKESKR | IKESKA |
-------------------------------|---------+---------+
Key | 0 | 0-1 |
Key-SPI | 0-1 | 0 |
IKEv2-Nonces | 1 | 0 |
IKEv2-Identity | 1 | 0 |
Responder-Identity | 0 | 0-1 |
+---------+---------+
IKESKR and IKESKA Commands AVP Table
<span class="grey">Cakulev, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. AVP Flag Rules</span>
The following table describes the Diameter AVPs, their AVP Code
values, types, and possible flag values. The Diameter base protocol
[<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>] specifies the AVP Flag rules for AVPs in <a href="#section-4.5">Section 4.5</a>.
+---------+
|AVP Flag |
| Rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------+----+----+
|Key 581 Note 1 Grouped | M | V |
+---------------------------------------------+----+----+
|Keying-Material 583 Note 1 OctetString| M | V |
+---------------------------------------------+----+----+
|Key-Lifetime 584 Note 1 Integer64 | M | V |
+---------------------------------------------+----+----+
|Key-SPI 585 Note 1 Unsigned32 | M | V |
+---------------------------------------------+----+----+
|Key-Type 582 Note 1 Enumerated | M | V |
+---------------------------------------------+----+----+
|IKEv2-Nonces 587 6.1 Grouped | M | V |
+---------------------------------------------+----+----+
|Ni 588 6.1.1 OctetString| M | V |
+---------------------------------------------+----+----+
|Nr 589 6.1.2 OctetString| M | V |
+---------------------------------------------+----+----+
|IKEv2-Identity 590 6.2 Grouped | M | V |
+---------------------------------------------+----+----+
|Initiator-Identity 591 6.2.1 Grouped | M | V |
+---------------------------------------------+----+----+
|ID-Type 592 6.2.1.1 Enumerated | M | V |
+---------------------------------------------+----+----+
|Identification-Data 593 6.2.1.2 OctetString| M | V |
+---------------------------------------------+----+----+
|Responder-Identity 594 6.2.2 Grouped | M | V |
+---------------------------------------------+----+----+
AVP Flag Rules Table
Note 1: The Key, Keying-Material, Key-Lifetime, Key-SPI, and Key-Type
AVPs are defined in [<a href="./rfc6734" title=""Diameter Attribute- Value Pairs for Cryptographic Key Transport"">RFC6734</a>].
<span class="grey">Cakulev, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Command Codes</span>
IANA has allocated a Command Code value for the following new command
from the Command Code namespace defined in [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>].
Command Code | Value
---------------------------------+------
IKEv2-SK-Request/Answer | 329
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. AVP Codes</span>
This specification requires IANA to register the following new AVPs
from the AVP Code namespace defined in [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>].
o IKEv2-Nonces - 587
o Ni - 588
o Nr - 589
o IKEv2-Identity - 590
o Initiator-Identity - 591
o ID-Type - 592
o Identification-Data - 593
o Responder-Identity - 594
The AVPs are defined in <a href="#section-6">Section 6</a>.
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. AVP Values</span>
IANA is requested to create a new value for the Key-Type AVP. The
new value 3 signifies that IKEv2 SK is being sent.
<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>. Application Identifier</span>
This specification requires IANA to allocate one new value "Diameter
IKE SK" from the Application Identifier namespace defined in
[<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>].
Application Identifier | Value
-------------------------------+------
Diameter IKE SK (IKESK) | 11
<span class="grey">Cakulev, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Security Considerations</span>
The security considerations of the Diameter base protocol [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>]
are applicable to this document (e.g., it is expected that Diameter
protocol is used with security mechanism and that Diameter messages
are secured).
In addition, the assumption is that the IKEv2 server and the Diameter
server, where the SK is generated, are in a trusted relationship.
Hence, the assumption is that there is an appropriate security
mechanism to protect the communication between these servers. For
example, the IKEv2 server and the Diameter server would be deployed
in the same secure network or would utilize transport-layer security
as specified in [<a href="./rfc6733" title=""Diameter Base Protocol"">RFC6733</a>].
The Diameter messages between the IKEv2 server and the HAAA may be
transported via one or more AAA brokers or Diameter agents. In this
case, the IKEv2 server to the Diameter server AAA communication is
hop-by-hop protected; hence, it relies on the security properties of
the intermediating AAA inter-connection networks, AAA brokers, and
Diameter agents. Furthermore, any agents that process IKEv2-SK-
Answer messages can see the contents of the Key AVP.
To mitigate the threat of exposing a long-lived PSK, this
specification expects that the HAAA derive and return the associated
SK to the IKEv2 server. Given that SK derivation is security-
critical, for the SK derivation, this specification recommends the
use of short-lived secrets, possibly based on a previous network
access authentication, if such secrets are available. To ensure key
freshness and to limit the key scope, this specification strongly
recommends the use of nonces included in the IKEv2-SK-Request. The
specifics of key derivation depend on the security characteristics of
the system that is leveraging this specification (for example, see
[<a href="#ref-X.S0047" title=""Mobile IPv6 Enhancements"">X.S0047</a>] and [<a href="#ref-X.S0058" title=""WiMAX-HRPD Interworking: Core Network Aspects"">X.S0058</a>]); therefore, this specification does not
define how the Diameter server derives required keys for these
systems. For systems and protocols that leverage this Diameter
application but do not specify the key derivation procedure, this
document specifies the default key derivation procedure that
preserves expected security characteristics.
<span class="grey">Cakulev, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.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-RFC4302">RFC4302</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>,
December 2005.
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC5295">RFC5295</a>] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", <a href="./rfc5295">RFC 5295</a>,
August 2008.
[<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 5996</a>, September 2010.
[<a id="ref-RFC6733">RFC6733</a>] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", <a href="./rfc6733">RFC 6733</a>, October 2012.
[<a id="ref-RFC6734">RFC6734</a>] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-
Value Pairs for Cryptographic Key Transport", <a href="./rfc6734">RFC 6734</a>,
October 2012.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC3748">RFC3748</a>] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
<a href="./rfc3748">RFC 3748</a>, June 2004.
[<a id="ref-RFC4285">RFC4285</a>] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
<a href="./rfc4285">RFC 4285</a>, January 2006.
[<a id="ref-RFC5778">RFC5778</a>] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
Agent to Diameter Server Interaction", <a href="./rfc5778">RFC 5778</a>,
February 2010.
[<a id="ref-X.S0047">X.S0047</a>] 3GPP2: X.S0047, "Mobile IPv6 Enhancements", February 2009.
[<a id="ref-X.S0058">X.S0058</a>] 3GPP2: X.S0058, "WiMAX-HRPD Interworking: Core Network
Aspects", June 2010.
<span class="grey">Cakulev, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6738">RFC 6738</a> Diameter IKEv2 SK October 2012</span>
Authors' Addresses
Violeta Cakulev
Alcatel Lucent
600 Mountain Ave.
3D-517
Murray Hill, NJ 07974
US
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Avi Lior
Bridgewater Systems
303 Terry Fox Drive
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 613-591-6655
EMail: avi.ietf@lior.org
Semyon Mizikovsky
Alcatel Lucent
600 Mountain Ave.
3C-506
Murray Hill, NJ 07974
US
Phone: +1 908 582 0729
EMail: Simon.Mizikovsky@alcatel-lucent.com
Cakulev, et al. Standards Track [Page 17]
</pre>
|
