-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-ipsecme-g-ikev2.xml
3946 lines (3509 loc) · 207 KB
/
draft-ietf-ipsecme-g-ikev2.xml
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
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" submissionType="IETF" docName="draft-ietf-ipsecme-g-ikev2-11" ipr="trust200902" updates="7296" obsoletes="6407">
<front>
<title abbrev="G-IKEv2">Group Key Management using IKEv2</title>
<author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>ELVIS-PLUS</organization>
<address>
<postal>
<street>PO Box 81</street>
<city>Moscow (Zelenograd)</city>
<code>124460</code>
<region></region>
<country>Russian Federation</country>
</postal>
<phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email>
</address>
</author>
<author fullname="Brian Weis" initials="B." surname="Weis">
<organization>Independent</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country>USA</country>
</postal>
<phone></phone>
<email>bew.stds@gmail.com</email>
</address>
</author>
<date />
<area>Security Area</area>
<abstract>
<t> This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol
for the purpose of a group key management. The protocol is in conformance with the
Multicast Security (MSEC) key management architecture, which contains
two components: member registration and group rekeying. Both components are
required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs)
with IPsec group security associations. The group members then
exchange IP multicast or other group traffic as IPsec packets.
</t>
<t> This document obsoletes RFC 6407. This documents also updates RFC 7296 by
renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)"
and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE".
</t>
</abstract>
</front>
<middle>
<section title="Introduction and Overview">
<t> This document presents an extension to IKEv2
<xref target="RFC7296"></xref> called G-IKEv2, which allows performing a group key
management. A group key management protocol provides IPsec keys and policy to a
set of IPsec devices which are authorized to communicate using a Group
Security Association (GSA) defined in <xref target="RFC3740"></xref>.
The data communications within the group (e.g., IP multicast packets)
are protected by a key pushed to the group members (GMs) by the Group
Controller/Key Server (GCKS). </t>
<t>G-IKEv2 conforms to the Multicast Group Security
Architecture <xref target="RFC3740"></xref>, Multicast Extensions to the
Security Architecture for the Internet Protocol <xref target="RFC5374"></xref>
and the Multicast Security (MSEC) Group Key Management Architecture <xref target="RFC4046"></xref>.
G-IKEv2 replaces GDOI <xref target="RFC6407"></xref>, which defines a
similar group key management protocol using IKEv1 <xref
target="RFC2409"></xref> (since deprecated by IKEv2). When G-IKEv2 is
used, group key management use cases can benefit from the simplicity,
increased robustness and cryptographic improvements of IKEv2 (see
Appendix A of <xref target="RFC7296"></xref>).</t>
<t>G-IKEv2 is composed of two phases: registration and rekeying. In the registration phase a GM
contacts a GCKS to register to a group and to receive the necessary policy and the keying material
to be able communicate with the other GMs in the group as well as with the GCKS.
The rekeying phase allows the GCKS to periodically renew the keying material for both GM-to-GM
communications as well as for communication between the GM and the GCKS.
</t>
<t>G-IKEv2 defines two ways to perform registration. When a GM first contacts a GCKS it uses the GSA_AUTH exchange
(<xref target="gsa_auth" />) to register to a group. This exchange follows the IKE_SA_INIT exchange
(similarly to the IKE_AUTH exchange in IKEv2) and results in establishing an IKE SA between the GM and the GCKS.
During this exchange the GCKS authenticates and authorizes the GM, then pushes policy and keys used by the group to the GM.
The other one is the GSA_REGISTRATION exchange (<xref target="gsa_registration" />),
which a GM can use within the already established IKE SA with the GCKS (e.g. for registering to another group).
</t>
<t> Refreshing the group keys can be performed either in an unicast mode via the
GSA_INBAND_REKEY exchange (<xref target="gsa_inband_rekey" />) performed over an specific IKE SA between a GM and a GCKS
or in an multicast mode with the GSA_REKEY pseudo exchange (<xref target="gsa_rekey" />), when new keys are being distributed to all GMs.
</t>
<!--
<t>With G-IKEv2 a GM needs to be registered to the group to be able to send or receive group traffic.
G-IKEv2 includes two "registration" exchanges. The first is the GSA_AUTH exchange (<xref target="gsa_auth" />),
which is used when a GM first contacts a GCKS and is creating an IKE SA between itself and the GCKS.
The GCKS authenticates and authorizes GMs, then pushes policy and keys used by the group to the GM.
The second is the GSA_REGISTRATION exchange (<xref target="gsa_registration" />),
which a GM can use within the already established IKE SA (e.g. for registering to another group).
</t>
<t>Group rekeys are accomplished using either the GSA_REKEY pseudo-exchange
(a single message distributed to all GMs, usually as
a multicast message), or as a GSA_INBAND_REKEY exchange delivered
individually to group members using their individual IKE SA).
</t>
-->
<t>Large and small groups may use different sets of these mechanisms.
When a large group of devices are communicating, the GCKS is likely to
use the GSA_REKEY message for efficiency. This is shown in <xref
target="large-groups"></xref>, where multicast communications indicated with double line.
(Note: For clarity, IKE_SA_INIT is omitted from <xref target="large-groups" /> and <xref target="small-groups" />).</t>
<figure anchor="large-groups" title="G-IKEv2 used in large groups">
<artwork align="center" name=""><![CDATA[
+--------+
+----IKEv2---->| GCKS |<----IKEv2----+
| +--------+ |
| || ^ |
| || | |
| || GSA_AUTH |
| || or |
| || GSA_REGISTRATION |
| || | |
GSA_AUTH || IKEv2 GSA_AUTH
or || | or
GSA_REGISTRATION GSA_REKEY | GSA_REGISTRATION
| || | |
| *==========**================* |
| || || | || |
v \/ \/ v \/ v
+-------+ +--------+ +-------+
| GM | ... | GM | ... | GM |
+-------+ +--------+ +-------+
|| || ||
*=====ESP/AH=====**=====ESP/AH====*
]]></artwork>
</figure>
<t>Alternatively, a small group may simply use the GSA_AUTH or GSA_REGISTRATION as
registration protocols, where the GCKS issues rekeys using the
GSA_INBAND_REKEY within the same IKE SA.
</t>
<figure anchor="small-groups" title="G-IKEv2 used in small groups">
<artwork align="center" name=""><![CDATA[
GSA_AUTH or GSA_REGISTRATION, GSA_INBAND_REKEY
+--------------------IKEv2----------------------+
| |
| GSA_AUTH or GSA_REGISTRATION, |
| GSA_INBAND_REKEY |
| +-----------IKEv2-------------+ |
| | | |
| |GSA_AUTH or GSA_REGISTRATION,| |
| | GSA_INBAND_REKEY | |
| | +--IKEv2-+ | |
v v v v v v
+---------+ +----+ +----+ +----+
| GCKS/GM | | GM | | GM | | GM |
+---------+ +----+ +----+ +----+
|| || || ||
*==ESP/AH==**=====ESP/AH====**===ESP/AH===*
]]></artwork>
</figure>
<t> A combination of these approaches is also possible. For example,
the GCKS may use more robust GSA_INBAND_REKEY to provide keys for some GMs
(for example, those acting as senders in the group) and GSA_REKEY for the rest.
Note also, that GCKS may also be a GM (as shown in <xref target="small-groups"></xref>).
</t>
<t>IKEv2 message semantics are preserved in that all communications
consists of message request-response pairs. The exception to this rule
is the GSA_REKEY pseudo-exchange, which is a single message delivering group
updates to the GMs.</t>
<section title="Requirements Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,
and only when, they appear in all capitals, as shown here.</t>
</section>
<section title="Terminology" anchor="terms">
<t> It is assumed that readers are familiar with the IPsec architecture <xref target="RFC4301" />,
and its extension for multicast <xref target="RFC5374" />. This document defines an extension to the IKEv2 protocol
<xref target="RFC7296" />, so it is assumed that readers have an understanding of this protocol.
This document uses a notation and conventions from <xref target="RFC7296" /> for describing G-IKEv2 payloads and exchanges.
</t>
<t>The following key terms are used throughout this document (mostly borrowed from <xref target="RFC3740" />,
<xref target="RFC5374" /> and <xref target="RFC6407" />).</t>
<dl anchor="definitions" newline="true">
<dt>Group</dt>
<dd>A set of IPsec devices that communicate to each other using multicast.</dd>
<dt>Group Member (GM)</dt>
<dd>An IPsec device that belongs to a group. A Group Member is
authorized to be a Group Sender and/or a Group Receiver.
</dd>
<dt>Group Receiver</dt>
<dd>A Group Member that is authorized to receive packets sent to a group by a Group Sender.
</dd>
<dt>Group Sender</dt>
<dd>A Group Member that is authorized to send packets to a group.
</dd>
<dt>Group Key Management (GKM) Protocol</dt>
<dd>A key management protocol used by a GCKS to distribute IPsec
Security Association policy and keying material. A GKM protocol
is needed because a group of IPsec devices require the same SAs. For
example, when an IPsec SA describes an IP multicast destination,
the sender and all receivers need to have the group SA.
</dd>
<dt>Group Controller/Key Server (GCKS)</dt>
<dd>A Group Key Management (GKM) protocol server that manages IPsec
state for a group. A GCKS authenticates and provides the IPsec SA
policy and keying material to GMs.
</dd>
<!-- <t hangText = "Group Key Management Subsystem" >
<vspace blankLines="0"/>
A subsystem in an IPsec device implementing a Group Key Management
protocol. The GKM subsystem provides IPsec SAs to the IPsec
subsystem on the IPsec device.
</t> -->
<!-- <t hangText = "Group Owner" >
<vspace blankLines="0"/>
An administrative entity that chooses the policy for a group.
</t> -->
<!-- <dt>Data-Security SA</dt>
<dd>The security policy distributed by a GDOI GCKS
describing traffic that is expected to be protected by group
members. This document described the distribution of IPsec AH
and ESP Data-Security SAs.
</dd>
<dt>Rekey SA</dt>
<dd>The security policy protecting Group Key Management Protocol.
</dd> -->
<dt>Data-Security SA</dt>
<dd>A multicast SA between each multicast sender and the group's receivers.
The Data-Security SA protects data between member senders and
member receivers. One or more SAs are required for the multicast transmission of
data-messages from the Group Sender to other group members.
This specification relies on ESP and AH as protocols for Data-Security SAs.
</dd>
<dt>Rekey SA</dt>
<dd>A single multicast SA between the GCKS and all of the group members.
This SA is used for multicast transmission of key management messages from the GCKS to all GMs.
</dd>
<dt>Group Security Association (GSA)</dt>
<dd>A collection of Data-Security SAs and Rekey SA
necessary for a Group Member to receive key updates.
A GSA describes the working policy for a group. Refer to <xref target="RFC4046" />
for additional information.
</dd>
<dt>Traffic Encryption Key (TEK)</dt>
<dd>The symmetric cipher key used in a Data-Security SA (e.g., IPsec ESP) to protect traffic.
</dd>
<dt>Key Encryption Key (KEK)</dt>
<dd>The symmetric cipher key used in a Rekey SA to protect distribution of new keys.
</dd>
<dt>Key Wrap Key (KWK)</dt>
<dd>The symmetric cipher key used to protect another key.
</dd>
<dt>Group Associated Policy (GAP)</dt>
<dd>Group-wide policy not related to a particular SA.
</dd>
<dt>Sender-ID</dt>
<dd>A unique identifier of a Group Sender in the context of an active GSA, used to form Initialization Vector (IV) in counter-based cipher modes.
</dd>
<dt>Logical Key Hierarchy (LKH)</dt>
<dd>A group management method defined in Section 5.4 of <xref target="RFC2627" />.
</dd>
</dl>
<!-- <list style="hanging" hangIndent="6" >
<t hangText = "Group" >
<vspace blankLines="0"/>
A set of devices that work together to protect group
communications.
</t>
<t hangText = "Group Member (GM)" >
<vspace blankLines="0"/>
An IPsec device that belongs to a group. A Group Member is
authorized to be a Group Sender and/or a Group Receiver.
</t>
<t hangText = "Group Receiver" >
<vspace blankLines="0"/>
A Group Member that is authorized to receive packets sent to a group by a Group Sender.
</t>
<t hangText = "Group Sender" >
<vspace blankLines="0"/>
A Group Member that is authorized to send packets to a group.
</t>
<t hangText = "Group Key Management (GKM) Protocol" >
<vspace blankLines="0"/>
A key management protocol used by a GCKS to distribute IPsec
Security Association policy and keying material. A GKM protocol
is used when a group of IPsec devices require the same SAs. For
example, when an IPsec SA describes an IP multicast destination,
the sender and all receivers need to have the group SA.
</t>
<t hangText = "Group Controller Key Server (GCKS)" >
<vspace blankLines="0"/>
A Group Key Management (GKM) protocol server that manages IPsec
state for a group. A GCKS authenticates and provides the IPsec SA
policy and keying material to GKM Group Members.
</t> -->
<!-- <t hangText = "Group Key Management Subsystem" >
<vspace blankLines="0"/>
A subsystem in an IPsec device implementing a Group Key Management
protocol. The GKM subsystem provides IPsec SAs to the IPsec
subsystem on the IPsec device.
</t> -->
<!-- <t hangText = "Group Owner" >
<vspace blankLines="0"/>
An administrative entity that chooses the policy for a group.
</t> -->
<!-- <t hangText = "Data-Security SA" >
<vspace blankLines="0"/>
The security policy distributed by a GDOI GCKS
describing traffic that is expected to be protected by group
members. This document described the distribution of IPsec AH
and ESP Data-Security SAs.
</t>
<t hangText = "Rekey SA" >
<vspace blankLines="0"/>
The security policy protecting Group Key Management Protocol.
</t>
<t hangText = "Group Security Association (GSA)" >
<vspace blankLines="0"/>
A collection of Data-Security Associations (SAs) and Rekey SAs
necessary for a Group Member to receive key updates.
A GSA describes the working policy for a group. Refer to <xref target="RFC4046" />
for additional information.
</t>
<t hangText = "Traffic Encryption Key (TEK)" >
<vspace blankLines="0"/>
The symmetric cipher key used in a Data-Security SA (e.g., IPsec ESP) to protect traffic.
</t>
<t hangText = "Key Encryption Key (KEK)" >
<vspace blankLines="0"/>
The symmetric cipher key used in a Rekey SA to protect distribution of new keys.
</t>
<t hangText = "Key Wrap Key (KWK)" >
<vspace blankLines="0"/>
The symmetric cipher key used to protect another key.
</t>
<t hangText = "Group Associated Policy (GAP)" >
<vspace blankLines="0"/>
Group-wide policy not related to a particular SA.
</t>
<t hangText = "Sender-ID" >
<vspace blankLines="0"/>
A unique identifier of a Group Sender in the context of an active GSA, used to form Initialization Vector (IV) in counter-based cipher modes.
</t>
<t hangText = "Logical Key Hierarchy (LKH)" >
<vspace blankLines="0"/>
A group management method defined in Section 5.4 of <xref target="RFC2627" />.
</t>
</list>
</t> -->
</section>
<!--
<section title="Acronyms and Abbreviations" anchor="abbrev">
<t>The following acronyms and abbreviations are used throughout this document.
</t>
</section>
-->
</section>
<section title="G-IKEv2 Protocol">
<section title="G-IKEv2 Integration into IKEv2 Protocol">
<t>G-IKEv2 is an extension to IKEv2 that <!-- uses its security mechanisms (peer authentication,
confidentiality, message integrity) to ensure that only authenticated and authorized
devices have access to the group policy and keys.
G-IKEv2 --> provides group authorization, secure policy and keys download from the GCKS to GMs.
</t>
<t>G-IKEv2 is compatible with most IKEv2 extensions defined so far. In particular,
it is assumed that, if necessary, the IKE_INTERMEDIATE exchanges <xref target="RFC9242" /> may be utilized
while establishing the registration SA. It is also believed that
future IKEv2 extensions will be possible to use with G-IKEv2, however, some IKEv2 extensions require
special handling when used with G-IKEv2. See <xref target="ike_ext" /> for more details.</t>
<t>It is assumed that readers are familiar with the IKEv2 protocol, so
this document skips many details that are described in <xref
target="RFC7296"></xref>.</t>
<section title="G-IKEv2 Transport and Port">
<t> As IKEv2 extension, G-IKEv2 <bcp14>SHOULD</bcp14> use the IKEv2 ports (500, 4500).
G-IKEv2 <bcp14>MAY</bcp14> also use TCP transport for registration (unicast) IKE SA,
as defined in <xref target="RFC9329" />.
G-IKEv2 <bcp14>MAY</bcp14> also use UDP port 848, the same as GDOI <xref
target="RFC6407"></xref>, because they serve a similar function.
The version number in the IKE header distinguishes the G-IKEv2
protocol from GDOI protocol <xref target="RFC6407"></xref>.
</t>
<t>Section 2.23 of <xref target="RFC7296" /> describes how IKEv2 supports paths with NATs.
G-IKEv2 registration SA doesn't create any unicast IPsec SAs, thus if
a NAT is present between the GM and the GCKS, there is no unicast
ESP traffic to encapsulate in UDP. However, the actions described
in this section regarding the IKE SA <bcp14>MUST</bcp14> be honored.
The behavior of GMs and GCKS <bcp14>MUST NOT</bcp14> depend on the port used to create the initial IKE SA.
For example, if the GM and the GCKS used UDP port 848 for the IKE_SA_INIT exchange, they
will operate the same as if they had used UDP port 500.
</t>
</section>
</section>
<section title="G-IKEv2 Payloads">
<t>In the following descriptions, the payloads contained in the G-IKEv2
messages are indicated by names as listed below.</t>
<table title="Payloads used in G-IKEv2">
<thead>
<tr>
<th>Notation</th><th>Payload</th><th>Defined in</th>
</tr>
</thead>
<tbody>
<tr>
<td>AUTH</td><td>Authentication</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>CERT</td><td>Certificate</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>CERTREQ</td><td>Certificate Request</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>D</td><td>Delete</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>GSA</td><td>Group Security Association</td><td><xref target="gsa_payload"/></td>
</tr>
<tr>
<td>HDR</td><td>IKEv2 Header</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>IDg</td><td>Identification - Group</td><td><xref target="idg_payload"/></td>
</tr>
<tr>
<td>IDi</td><td>Identification - Initiator</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>IDr</td><td>Identification - Responder</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>KD</td><td>Key Download</td><td><xref target="kd_payload"/></td>
</tr>
<tr>
<td>KE</td><td>Key Exchange</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>Ni, Nr</td><td>Nonce</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>N</td><td>Notify</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>SA</td><td>Security Association</td><td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>SAg</td><td>Security Association - GM Supported Transforms</td><td><xref target="sag_payload"/></td>
</tr>
<tr>
<td>SK</td><td>Encrypted</td><td><xref target="RFC7296"/></td>
</tr>
</tbody>
</table>
<t> Payloads defined as part of other IKEv2 extensions <bcp14>MAY</bcp14> also be included in
these messages. Payloads that may optionally appear in G-IKEv2 messages
will be shown in brackets, such as [CERTREQ].
</t>
<t>G-IKEv2 defines several new payloads not used in IKEv2:</t>
<t><list style="symbols">
<t>IDg (Group ID) -- The GM requests the GCKS for membership into
the group by sending its IDg payload.</t>
<t>SAg (Security Association -- GM Supported Transforms) -- the GM optionally sends
supported transforms, so that GCKS may select a policy appropriate for all members
of the group (which is not negotiated, unlike SA parameters in IKEv2).</t>
<t>GSA (Group Security Association) -- The GCKS sends the group
policy to the GM using this payload.</t>
<t>KD (Key Download) -- The GCKS sends the keys and the security parameters
to the GMs using this payload.</t>
</list></t>
<t> The details of the contents of each payload are described in <xref
target="header_payload"></xref>.
</t>
</section>
<section title="G-IKEv2 Member Registration and Secure Channel Establishment" anchor="registration">
<t>Registration consists of a minimum of two
exchanges, IKE_SA_INIT and GSA_AUTH; member registration may have a
few more messages exchanged if the EAP method, cookie challenge (for
DoS protection), negotiation of Diffie-Hellman group or IKEv2 extensions
based on <xref target="RFC9242" />
are used. Each exchange consists of request/response pairs. The first exchange
IKE_SA_INIT is defined in IKEv2 <xref target="RFC7296"></xref>. This
exchange negotiates cryptographic algorithms, exchanges nonces and
computes a shared key between the GM and the GCKS.
In addition to the cryptographic algorithms negotiated for use in IKEv2 SA,
a key wrap algorithm is also negotiated in this exchange.
This is achieved by augmenting each proposed Encryption Algorithm transform with a new
"Key Wrap Algorithm" attribute. See <xref target="wrapped_key" /> for details.
</t>
<t>The second exchange GSA_AUTH is similar to the IKEv2 IKE_AUTH exchange <xref target="RFC7296"></xref>.
It authenticates the previously exchanged messages, exchanges identities and certificates.
The GSA_AUTH messages are encrypted and integrity protected with keys established through the previous
exchanges, so the identities are hidden from eavesdroppers and all
fields in all the messages are authenticated. The GCKS authorizes
group members to be allowed into the group as part of the
GSA_AUTH exchange. Once the GCKS accepts a GM to join a
group it will provide the GM with the data-security keys (TEKs) and/or group key
encrypting key (KEK) as part of the GSA_AUTH response message. </t>
<section anchor="gsa_auth" title="GSA_AUTH exchange">
<t>After the GM and GCKS complete the IKE_SA_INIT exchange,
the GSA_AUTH exchange <bcp14>MUST</bcp14> complete before any other exchanges defined in this document
can be done. GSA_AUTH is used to authenticate the previous exchanges,
exchange identities and certificates. G-IKEv2 also uses this
exchange for group member registration and authorization.
</t>
<t> The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the
difference that its goal is to establish multicast Data-Security SAs
and optionally provide GM with the keys for Rekey SA. The set of payloads
in the GSA_AUTH exchange is slightly different, because policy is not
negotiated between the group member and the GCKS, but instead
provided by the GCKS for the GM. Note also, that GSA_AUTH
has its own exchange type, which is different from the IKE_AUTH exchange type.
</t>
<t>Note, that due to the similarities between IKE_AUTH and GSA_AUTH,
most IKEv2 extensions to the IKE_AUTH exchange
(like <xref target="RFC6467" />) can also be used with the GSA_AUTH exchange.
</t>
<figure title="GSA_AUTH Request" anchor="gsa_auth_request">
<preamble></preamble>
<artwork><![CDATA[
Initiator (GM) Responder (GCKS)
-------------------- ------------------
HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, IDg, [SAg,] [N(SENDER),] [N]} -->
]]></artwork>
<postamble></postamble>
</figure>
<t>A group member initiates a GSA_AUTH request to join a group indicated
by the IDg payload. The GM may include an SAg payload declaring which
Transforms it is willing to accept. A GM that intends to act as Group Sender
<bcp14>SHOULD</bcp14> include a Notify payload status type of SENDER,
which enables the GCKS to provide any additional policy necessary by
group senders.</t>
<figure title="GSA_AUTH Normal Response" anchor="gsa_auth_norm_response">
<preamble></preamble>
<artwork><![CDATA[
Initiator (GM) Responder (GCKS)
-------------------- ------------------
<-- HDR, SK{IDr, [CERT,]
AUTH, GSA, KD,]]><!-- XXXX <![CDATA[ [D,]]]> --><![CDATA[ [N]}
]]></artwork>
<postamble></postamble>
</figure>
<t> The GCKS responds with IDr, optional CERT, and AUTH payloads
with the same meaning as in IKE_AUTH. It also informs the group member
of the cryptographic policies of the group in the GSA payload and
the key material in the KD payload.
<!-- XXXX Do we need the following? It looks useless.
The GM which wants to join the group will not have any policy,
and in any case even if it has, the policy will be replaces while it joins. -->
<!-- The GCKS can also include a
Delete (D) payload instructing the group member to delete existing
SAs it might have as the result of a previous group member registration
Note, that since the GCKS generally doesn't know which
SAs the GM has, the SPI field in the Delete payload(s) SHOULD be set to zero
in this case. (See more discussion on the Delete payload in <xref
target="delete"></xref>.) -->
</t>
<t> In addition to the IKEv2 error handling, the GCKS can reject the
registration request when the IDg is invalid or authorization fails,
etc. In these cases, see <xref target="notify"></xref>, the GSA_AUTH
response will not include the GSA and KD, but will include a Notify
payload indicating errors. If a GM included an SAg
payload, and the GCKS chooses to evaluate it, and the GCKS detects that
the group member cannot support the security policy defined for the
group, then the GCKS <bcp14>SHOULD</bcp14> return a NO_PROPOSAL_CHOSEN.
Other types of error notifications can be INVALID_GROUP_ID, AUTHORIZATION_FAILED or REGISTRATION_FAILED.</t>
<figure title="GSA_AUTH Error Response" anchor="gsa_auth_err_response">
<preamble></preamble>
<artwork><![CDATA[
Initiator (GM) Responder (GCKS)
-------------------- ------------------
<-- HDR, SK{IDr, [CERT,] AUTH, N}
]]></artwork>
<postamble></postamble>
</figure>
<t>If the group member finds the policy sent by the GCKS is
unacceptable, the member <bcp14>SHOULD</bcp14> initiate GSA_REGISTRATION exchange
sending IDg and the Notify NO_PROPOSAL_CHOSEN (see <xref target="gsa_registration" />)).
</t>
</section>
<section anchor="gsa_registration" title="GSA_REGISTRATION Exchange">
<t>Once the IKE SA between the GM and the GCKS is established,
the GM can use it for other registration requests, if this is needed.
In this scenario the GM will use the
GSA_REGISTRATION exchange. Payloads in the exchange are generated
and processed as defined in <xref target="gsa_auth"></xref>.</t>
<figure title="GSA_REGISTRATION Normal Exchange" anchor="gsa_registration_exchange">
<preamble></preamble>
<artwork><![CDATA[
Initiator (GM) Responder (GCKS)
-------------------- ------------------
HDR, SK{IDg, [SAg,]
[N(SENDER),] [N]} -->
<-- HDR, SK{GSA, KD,]]><!-- XXXX <![CDATA[ [D,]]]> --><![CDATA[ [N]}
]]></artwork>
<postamble></postamble>
</figure>
<t>As with GSA_AUTH exchange, the GCKS can reject the
registration request when the IDg is invalid or authorization fails,
or GM cannot support the security policy defined for the
group (which can be concluded by GCKS by evaluation of SAg payload).
In this case the GCKS returns an appropriate error notification
as described in <xref target="gsa_auth" />.
</t>
<figure title="GSA_REGISTRATION Error Exchange" anchor="gsa_registration_err_exchange">
<preamble></preamble>
<artwork><![CDATA[
Initiator (GM) Responder (GCKS)
-------------------- ------------------
HDR, SK{IDg, [SAg,]
[N(SENDER),] [N]} -->
<-- HDR, SK{N}
]]></artwork>
<postamble></postamble>
</figure>
<t>This exchange can also be used if the group member finds the
policy sent by the GCKS is unacceptable<!-- or for some reason wants to leave
the group-->. The group member <bcp14>SHOULD</bcp14>
notify the GCKS by sending IDg and the Notify type
NO_PROPOSAL_CHOSEN<!-- or REGISTRATION_FAILED-->, as shown below.
The GCKS in this case <bcp14>MUST</bcp14> remove the GM from the group IDg.</t>
<figure title="GM Reporting Errors in GSA_REGISTRATION Exchange" anchor="gsa_registration_gm_error">
<preamble></preamble>
<artwork><![CDATA[
Initiator (GM) Responder (GCKS)
-------------------- ------------------
HDR, SK{IDg, N} -->
<-- HDR, SK{}
]]></artwork>
</figure>
</section>
<section title="GM Registration Operations">
<t>A GM requesting registration contacts the
GCKS using the IKE_SA_INIT exchange. This exchange is unchanged from IKE_SA_INIT
in the IKEv2 protocol. The IKE_SA_INIT exchange may optionally be followed
by one or more the IKE_INTERMEDIATE exchanges if the GM and the GCKS
negotiated use of IKEv2 extensions based on this exchange.
</t>
<t>Next the GM sends the GSA_AUTH request message with the IKEv2 payloads
from IKE_AUTH (without the SAi2, TSi and TSr payloads) along with
the Group ID informing the GCKS of the group the GM wishes to
join. An GM intending to emit data traffic <bcp14>SHOULD</bcp14> send a
SENDER Notify payload status. The SENDER notification not only signifies that it
is a sender, but provides the GM the ability to request
Sender-ID values, in case the Data-Security SA supports a counter
mode cipher. <xref target="counter-modes"></xref> includes guidance
on requesting Sender-ID values.</t>
<t>A GM may be limited in the Transforms IDs that it is
able or willing to use, and may find it useful to inform the GCKS
which Transform IDs it is willing to accept for different security protocols
by including the SAg payload into the request message.
Proposals for Rekey SA (with protocol GIKE_REKEY) and for Data-Security
(AH <xref target="RFC4302" /> and/or ESP <xref target="RFC4303" />) SAs
may be included into SAg. Each Proposal contains a list of Transforms that the GM is able
and willing to support for that protocol. Valid transform types depend on the
protocol (AH, ESP, GIKE_REKEY) and are defined in <xref target="allowed_transforms" />.
Other transform types <bcp14>SHOULD NOT</bcp14> be included.
The SPI length of each Proposal in an SAg is set to zero, and thus the SPI field is empty.
The GCKS <bcp14>MUST</bcp14> ignore SPI length and SPI fields in the SAg payload.
</t>
<t>Generally, a single Proposal for each protocol (GIKE_REKEY, AH/ESP)
will suffice, because the transforms are not negotiated, the GM
simply alerts the GCKS to restrictions it may have.
In particular, the restriction from Section 3.3 of <xref target="RFC7296" /> that
AEAD and non-AEAD transforms not be combined in a single proposal
doesn't hold when the SAg payload is being formed. However
if the GM has restrictions on combination of algorithms,
this can be expressed by sending several proposals.</t>
<t>Proposal Num field in Proposal substructure is treated specially in SAg payload:
it allows a GM to indicate that algorithms used in Rekey SA and in
Data-Security (AH and/or ESP) SAs are dependent.
In particular, Proposals for different protocols having the same value in
Proposal Num field are treated as a set, so that if GCKS uses transforms
from one of such Proposal for one protocol, then it <bcp14>MUST</bcp14> only use transforms from
one of the Proposals with the same value in Proposal Num field for other protocols.
For example, a GM may support algorithms X and Y for both Rekey and
Data-Security SAs, but with a restriction that if X is used in Rekey SA, then only X can be used
in Data-Security SAs, and the same for Y.
Use of the same value in the Proposal Num field of different
proposals indicates that the GM expects these proposals to be
used in conjunction with each other.
<!-- To indicate this the GM sends several Proposals marking those of them that must be used together
by putting the same value in their Proposal Num field. -->
In the simplest case when no dependency between transforms exists,
all Proposals in SAg payload will have the same value in Proposal Num field.
</t>
<t>Although the SAg payload is optional, it is <bcp14>RECOMMENDED</bcp14> for the GM to include
this payload into the GSA_AUTH request to allow the GCKS to select an appropriate policy.
</t>
<t>A GM MAY also indicate the support for IPcomp by inclusion one or more the IPCOMP_SUPPORTED
notifications along with the SAg payload. The Compression Parameter Index (CPI) in these notifications is set to zero
and <bcp14>MUST</bcp14> be ignored by the GCKS.
</t>
<t>Upon receiving the GSA_AUTH response, the GM parses the
response from the GCKS authenticating the exchange using the IKEv2
method, then processes the GSA and KD payloads.</t>
<t>The GSA payload contains the security policy and cryptographic
protocols used by the group. This policy describes the optional Rekey SA
(KEK), Data-Security SAs (TEK), and optional Group Associated policy
(GAP). If the policy in the GSA payload is not acceptable to the GM,
it <bcp14>SHOULD</bcp14> notify the GCKS by initiating a GSA_REGISTRATION exchange
with a NO_PROPOSAL_CHOSEN Notify payload (see <xref target="gsa_registration"></xref>).
Note, that this should normally not happen if the GM includes SAg payload
in the GSA_AUTH request and the GCKS takes it into account.
Finally the KD payload is parsed providing the keying material for the TEK and/or KEK.
The KD payload contains a list of key bags, where each key bag includes the
keying material for SAs distributed in the GSA payload. Keying
material is matched by comparing the SPIs in the key bags to SPIs
previously included in the GSA payloads. Once TEK keys and policy
are matched, the GM provides them to the data-security subsystem,
and it is ready to send or receive packets matching the TEK
policy.</t>
<t>The GSA KEK policy <bcp14>MUST</bcp14> include the attribute GSA_INITIAL_MESSAGE_ID with
a first Message ID the GM should expect to receive if it is non-zero.
The value of the attribute <bcp14>MUST</bcp14> be checked by a GM against any previously received Message ID for this group.
If it is less than the previously received number, it should be
considered stale and <bcp14>MUST</bcp14> be ignored. This could happen if two GSA_AUTH
exchanges happened in parallel, and the Message ID changed. This
attribute is used by the GM to prevent GSA_REKEY message replay
attacks. The first GSA_REKEY message that the GM receives from the
GCKS will have a Message ID greater or equal to the Message ID
received in the GSA_INITIAL_MESSAGE_ID attribute.</t>
<t>Once a GM successfully registers to the group it <bcp14>MUST</bcp14> replace
any information related to this group (policy, keys) that it might
have as a result of a previous registration with a new one.
</t>
<t>Once a GM has received GIKE_REKEY policy during a registration, the
IKE SA <bcp14>MAY</bcp14> be closed. By convention, the GCKS closes the IKE SA. The
GKCS <bcp14>MAY</bcp14> choose to keep the IKE SA open for inband rekey,
especially for small groups. If inband rekey is used, then the
initial IKE SA can be rekeyed with the standard IKEv2 mechanism
described in Section 1.3.2 of <xref target="RFC7296" />. If for some reason the
IKE SA is closed and no GIKE_REKEY policy is received during the
registration process, the GM <bcp14>MUST</bcp14> consider itself excluded from the
group. To continue participating in the group, the GM needs to
re-register.
</t>
</section>
<section title="GCKS Registration Operations">
<t>A G-IKEv2 GCKS passively listens for incoming requests from group
members. When the GCKS receives an IKE_SA_INIT request, it selects
an IKE proposal and generates a nonce and DH to include them in the
IKE_SA_INIT response.</t>
<t>Upon receiving the GSA_AUTH request, the GCKS authenticates the
group member via the GSA_AUTH exchange. The
GCKS then authorizes the group member according to group policy
before preparing to send the GSA_AUTH response. If the GCKS fails to
authorize the GM, it <bcp14>SHOULD</bcp14> respond with an AUTHORIZATION_FAILED
notify message. The GCKS <bcp14>SHOULD</bcp14> also respond with an INVALID_GROUP_ID notify message
if the requested group is unknown to the GCKS or with an REGISTRATION_FAILED
notify message if there is a problem with the requested group (for example
the capacity of the group is exceeded).</t>
<t>The GSA_AUTH response will include the group policy in the GSA
payload and keys in the KD payload. If the GCKS policy includes a
group rekey option, it <bcp14>MUST</bcp14> include the GSA_INITIAL_MESSAGE_ID attribute,
specifying the starting Message ID the GCKS will use when sending the GSA_REKEY message
to the group members if this Message ID is non-zero. This Message ID is used to prevent GSA_REKEY
message replay attacks and will be increased each time a GSA_REKEY message is sent
to the group. The GCKS data traffic policy is included in the GSA
TEK and keys are included in the KD TEK. The GAP <bcp14>MAY</bcp14> also be
included to provide the ATD and/or DTD (<xref target="gap_attr_atd_dtd"></xref>)
specifying activation and deactivation
delays for SAs generated from the TEKs. If the group member has
indicated that it is a sender of data traffic and one or more Data
Security SAs distributed in the GSA payload included a counter mode
of operation, the GCKS responds with one or more Sender-ID values (see <xref
target="counter-modes"></xref>).</t>
<t><xref target="RFC5374" /> defines two modes of operation for multicast
Data-Security SAs: transport mode and tunnel mode with address preservation.
In the latter case outer source and destination addresses are taken from
the inner IP packet.
</t>
<t>If the GCKS receives a GSA_REGISTRATION exchange with a request
to register a GM to a group, the GCKS will need to authorize the GM
with the new group (IDg) and respond with the corresponding group
policy and keys. If the GCKS fails to authorize the GM, it will
respond with the AUTHORIZATION_FAILED notification. The GCKS may also
respond with an INVALID_GROUP_ID or REGISTRATION_FAILED notify messages
for the reasons described above.</t>
<t>If a group member includes an SAg in its GSA_AUTH or
GSA_REGISTRATION request, the GCKS may evaluate it according to an
implementation specific policy.
<list style="symbols">
<t>The GCKS could evaluate the list of Transforms and compare it
to its current policy for the group. If the group member did not
include all of the ESP, AH or GIKE_REKEY Transforms that match the current group policy
or the capabilities of all other currently active GMs,
then the GCKS <bcp14>SHOULD</bcp14> return a NO_PROPOSAL_CHOSEN Notification.</t>
<t>The GCKS could store the list of Transforms, with the goal of
migrating the group policy to a different Transforms when all of
the group members indicate that they can support that
Transforms.</t>
<t>The GCKS could store the list of Transforms and adjust the
current group policy based on the capabilities of the devices as
long as they fall within the acceptable security policy of the
GCKS.</t>
</list>
Depending on its policy, the GCKS may have no further need for the
IKE SA (e.g., it does not plan to initiate an GSA_INBAND_REKEY
exchange). If the GM does not initiate another registration exchange
or Notify (e.g., NO_PROPOSAL_CHOSEN), and also does not close the
IKE SA and the GCKS is not intended to use the SA, then after a
short period of time the GCKS <bcp14>SHOULD</bcp14> close the IKE SA.</t>
</section>
</section>
<section title="Group Maintenance Channel">
<t>The GCKS is responsible for rekeying the secure group per the group
policy. Rekeying is an operation whereby the GCKS provides replacement
TEKs and KEK, deleting TEKs, and/or excluding group members. The GCKS
may initiate a rekey message if group membership and/or policy has
changed, or if the keys are about to expire. Two forms of group
maintenance channels are provided in G-IKEv2 to push new policy to
group members.</t>
<dl newline="true">
<dt>GSA_REKEY</dt>
<dd>The GSA_REKEY is a pseudo-exchange, consisting
of a one-way IKEv2 message sent by the GCKS, where the rekey policy is delivered
to group members using IP multicast as a transport. <!-- This is not
a real IKEv2 exchange, since no response messages are sent. --> This method is
valuable for large and dynamic groups, and where policy may change
frequently and a scalable rekey method is required. When the
GSA_REKEY is used, the IKE SA protecting the member
registration exchanges is usually terminated, and group members await
policy changes from the GCKS via the GSA_REKEY messages.</dd>
<dt>GSA_INBAND_REKEY</dt>
<dd>The GSA_INBAND_REKEY is a
normal IKEv2 exchange using the IKE SA that was setup to protecting the
member registration exchange. This exchange allows the GCKS to
rekey without using an independent GSA_REKEY pseudo-exchange. The
GSA_INBAND_REKEY exchange provides a reliable policy delivery and
is useful when G-IKEv2 is used with a small group of cooperating devices.</dd>
</dl>
<t>Depending on its policy the GCKS <bcp14>MAY</bcp14> combine these two methods.
For example, it may use the GSA_INBAND_REKEY to deliver key to the
GMs in the group acting as senders (as this would provide reliable keys delivery),
and the GSA_REKEY for the rest GMs.
</t>
<section anchor="gsa_rekey" title="GSA_REKEY">
<t>The GCKS initiates the G-IKEv2 Rekey by sending a protected message to the GMs,
usually using IP multicast. Since the Rekey messages do not require responses and they are sent
to multiple GMs, the windowing mechanism described in Section 2.3
of <xref target="RFC7296" /> <bcp14>MUST NOT</bcp14> be used for the Rekey messages.
The GCKS rekey message replaces the rekey GSA KEK or KEK array (e.g. in case of LKH),
and/or creates a new Data-Security GSA TEK. The GM_SENDER_ID
attribute in the Key Download payload (defined in <xref
target="mkd_attr_gm_sid"></xref>) <bcp14>MUST NOT</bcp14> be part of the Rekey
Exchange as this is sender specific information and the Rekey
Exchange is group specific. The GCKS initiates the GSA_REKEY
pseudo-exchange as following:</t>
<t><figure title="GSA_REKEY Pseudo-Exchange" anchor="gsa_rekey_exchange">
<preamble></preamble>
<artwork><![CDATA[
GMs (Receivers) GCKS (Sender)
----------------- ---------------
<-- HDR, SK{GSA, KD,]]><!-- XXXX <![CDATA[ [D,]]]> --><![CDATA[ [N] [AUTH]}
]]></artwork>
<postamble></postamble>
</figure></t>
<t>HDR is defined in <xref target="header"></xref>. The Message ID
in this message will start with the value the GCKS sent to the
group members in the attribute GSA_INITIAL_MESSAGE_ID or from
zero if this attribute wasn't sent. The Message ID will be incremented each time a new
GSA_REKEY message is sent to the group members.</t>
<t>The GSA payload contains the current policy for rekey and Data-Security SAs.
The GSA may contain a new Rekey SA and/or a new Data-Security SAs
<xref target="gsa_payload"></xref>.</t>
<t>The KD payload contains the keys for the policy included in the
GSA. If the Data-Security SA is being refreshed in this rekey
message, the IPsec keys are updated in the KD, and/or if the rekey
SA is being refreshed in this rekey message, the rekey Key or the
LKH KEK array (e.g. in case of LKH) is updated in the KD payload.</t>
<t>A Delete payload <bcp14>MAY</bcp14> be included to instruct the GM to delete
existing SAs. See <xref target="delete" /> for more detail.</t>
<t>The AUTH payload <bcp14>MUST</bcp14> be included to authenticate the GSA_REKEY
message if the authentication method is based on public key signatures
<!-- or a dedicated shared secret --> and <bcp14>MUST NOT</bcp14> be included if authentication is implicit.
In the latter case, the fact that a GM can decrypt the GSA_REKEY message and verify its ICV
proves that the sender of this message knows the current KEK,
thus authenticating the sender as a member of the group.
<!-- Shared secret and --> Note, that implicit authentication doesn't provide source origin authentication.
For this reason using implicit authentication for GSA_REKEY is <bcp14>NOT RECOMMENDED</bcp14>
unless source origin authentication is not required (for example, in a small group of
highly trusted GMs). See more about authentication methods in <xref target="auth_method" />.
</t>
<t> During group member registration, the GCKS
sends the authentication key in the KD payload, AUTH_KEY attribute,
which the group member uses to authenticate the key