-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-cullen-radextra-status-realm-00.xml
1054 lines (1011 loc) · 41.1 KB
/
draft-cullen-radextra-status-realm-00.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"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1321 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2865 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY rfc2866 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2866.xml'>
<!ENTITY rfc2869 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2869.xml'>
<!ENTITY rfc3579 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY rfc4270 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4270.xml'>
<!ENTITY rfc4668 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4668.xml'>
<!ENTITY rfc4669 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4669.xml'>
<!ENTITY rfc4670 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4670.xml'>
<!ENTITY rfc4671 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4671.xml'>
<!ENTITY rfc5997 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5997.xml'>
<!ENTITY rfc7991 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7991.xml'>
<!ENTITY rfc8044 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8044.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" consensus="true" ipr="trust200902" docName="draft-cullen-radextra-status-realm-00">
<front>
<title abbrev="Status-Realm and Loop Detection for RADIUS">
Status-Realm and Loop Detection for the Remote Authentication
Dial-In User Service (RADIUS)
</title>
<author initials="M." surname="Cullen" fullname="Margaret Cullen">
<organization>Painless Security</organization>
<address>
<phone>+1 (781)405-7464</phone>
<email>margaret@painless-security.com</email>
</address>
</author>
<author initials="A." surname="DeKok" fullname="Alan DeKok">
<organization>FreeRADIUS</organization>
<address>
<email>aland@freeradius.org</email>
</address>
</author>
<author initials="M." surname="Donnelly" fullname="Mark Donnelly">
<organization>Painless Security</organization>
<address>
<phone>+1 (857)928-5967</phone>
<email>mark@painless-security.com</email>
</address>
</author>
<author initials="J." surname="Howlett" fullname="Josh Howlett">
<organization>Federated Solutions</organization>
<address>
<phone>+44 (0)7510 666 950</phone>
<email>josh@federated-solutions.com>
</address>
</author>
<date day="23" month="October" year="2022"/>
<area>SEC</area>
<workgroup>radextra BOF</workgroup>
<abstract>
<t>
This document describes extension to the Remote Authentication
Dial-In User Service (RADIUS) protocol to allow participants
in a multi-hop RADIUS proxy fabric to check the status of a
remote RADIUS authentication realm, gain visibility into the
path that a RADIUS request will take across the RADIUS proxy
fabric, and mitigate or prevent RADIUS proxy loops.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document describes an extension to the Remote
Authentication Dial-In User Service (RADIUS) protocol <xref
target="RFC2865"/>, to allow participants in a multi-hop
RADIUS proxy fabric to check the status of a remote RADIUS
authentication realm, gain visibility into the path that a
RADIUS request will take across the RADIUS proxy fabric, and
mitigate or prevent RADIUS proxy forwarding loops.
</t>
<t>
This document defines two new RADIUS Packet Type Codes:
<ul>
<li>
Status-Realm-Request (TBD)
</li>
<li>
Status-Realm-Response (TBD)
</li>
</ul>
</t>
<t>
This document also defines the following RADIUS Attributes:
<ul>
<li>Status-Realm-Response-Code (TBD)</li>
<li>Max-Hop-Count (TBD)</li>
<li>Server-Identifier (TBD)</li>
</ul>
</t>
</t>
</section>
<section title="Requirements Notation">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology">
<t>
The following terms are used throughout this document. Their
definitions are included here for consistency and clarity.
</t>
<t>
<list style="hanging">
<t hangText="RADIUS Request">
A RADIUS Request is the first message in a RADIUS message
exchange. RADIUS request message types include:
Access-Request, Accounting-Request, and Status-Server.
This document defines a new RADIUS Request message type:
Status-Realm-Request.
</t>
<t hangText="RADIUS Response">
A RADIUS Response is any RADIUS message sent in reply
to a RADIUS Request. RADIUS reponse message types
include: Access-Accept, Access-Challenge, Access-Reject,
Accounting-Response. This document defines a new RADIUS
Response message type: Status-Realm-Response.
</t>
<t hangText="RADIUS Instance">
A single device or software module that implements the
RADIUS protocol.
</t>
<t hangText="RADIUS RADIUS Client">
A RADIUS Client is a RADIUS Instance that sends RADIUS
Request messages and recevies RADIUS Reponse messages in
reply.
</t>
<t hangText="RADIUS Server">
A RADIUS Server is a RADIUS Instance that receives RADIUS
Requests and sends RADIUS Response messages in reply.
</t>
<t hangText="Authentication Request">
An Authentication Request is sent to authenticate a
particular user within a particular realm. The user and
realm information are typically included in a User-Name
Attribute <xref target="RFC2865"/> within the
Authentication Request.
</t>
<t hangText="Authentication Server">
An Authentication Server is a RADIUS Server that receives
Access-Requests for a given RADIUS Realm, and sends
Access-Access, Access-Challenge or Access-Reject messages
in response. A single Authentication Server may serve
more than one Authentication Realm.
</t>
<t hangText="Authentication Realm">
An Authentication Realm consists of a group of users
within a single organization that can be authenticated
using RADIUS. A single Authentication Realm MAY be served
by more than one Authentication Server.
</t>
<t hangText="Target Realm">
The Target Realm of a RADIUS Request is the RADIUS Realm
toward which the Request is directed. The Target Realm is
typically contained within the "User-Name" attribute of a
Request.
</t>
<t hangText="RADIUS Proxy">
A RADIUS Proxy receives RADIUS Requests and forwards then
towards the Target Realm included in the RADIUS Request
message. It also receives the corresponding RADIUS Respone
message and fowards them back towards the RADIUS Client
that originated the request. In this context forwarding a
RADIUS Requst consists of generating a new RADIUS Request
containing information from the original Request, and
sending it to the configured next-hop RADIUS server for
the Target Realm. Forwarding a RADIUS Response consists
of sending it to the RADIUS Server from which the
corresponding Request was received.
</t>
<t hangText="RADIUS Proxy Fabric">
A multi-hop group of inter-connected RADIUS Servers that
Proxy requests among themselves towards a set of Target Realms.
</t>
<t hangText="RADIUS Proxy Path">
The RADIUS Server Path is a the set of RADIUS Servers that
a RADIUS Request traverses from the first RADIUS Server
that is contacted by the RADIUS Client to the final RADIUS
Server that responds to the Request.
</t>
<t hangText="Proxy Loop">
A Proxy Loop may occur when two or more RADIUS Proxies are
configured such that a RADIUS Request follow a circular
path through the Proxy Fabric, never reaching the Target
Realm. This is a pathological and potentially damaging
misconfiguration.
</t>
<t hangText="First-Hop RADIUS Server">
The First-Hop RADIUS Server is the first RADIUS Server
within a Proxy Fabric to recieve a RADIUS Request. In
some cases, the First-Hop RADIUS Server may receive the
request from a separate RADIUS Client. In other case, the
First-Hop RADIUS Server and the RADIUS Client may be
running in a single RADIUS Instance.
</t>
<t hangText="Last-Hop RADIUS Proxy">
The Last-Hop RADIUS Proxy is the last RADIUS Proxy to
forward a RADIUS Request before it reaches the
Authentication Server. Depending on its configuraiton,
the Last-Hop Proxy may or may not know that is the
Last-Hop Proxy for a given RADIUS Request.
</t>
<t>
</list>
</t>
<t>
Note: It is possible for a single RADIUS instance to server in
multiple roles. For example, it is common for a RADIUS Server
to act as an Authentication Server for some Realms, while
acting as a Proxy for other Realms. A RADIUS Proxy will, by
its nature, act as a RADIUS Server for some RADIUS messages
while acting as a RADIUS Client for others. The requirements
in this document apply to all RADIUS instances whenever they
are acting in the role to which the requirement applies.
</t>
</section>
<section title="Overview">
<t>
This document defines two functional extensions to RADIUS:
Querying the status of a remote RADIUS Realm (Status-Realm),
and mitigating, detecting and preventing loops in a RADIUS
Proxy forwarding loops (Proxy Loop Prevention). This section
contains a short overview of each function. Detailed
definitions and requirements are covered in later sections of
this document.
</t>
<section title="Status-Realm Overview">
<t>
Status-Realm-Request messages are sent by RADIUS Clients to
to query the reachability and status of a particular Target
Realm. In some cases, the Status-Realm RADIUS Client may be
able to reach an Authentication Server for the Target Realm
directly. In other cases, the RADIUS Client will send the
initial Status-Realm request to a RADIUS Proxy, which
will forward the Status-Realm-Request toward the indicated
realm.
</t>
<t>
Status-Realm-Requests may be sent to the RADIUS
authentication port or the RADIUS accounting port of the
first-hop RADIUS server. RADIUS proxies should forward
Status-Realm-Requests received on the authentication port to
the authentication port of the next-hop RADIUS server.
Status-Realm-Requests received on the accounting port
should, similarly, be forwarded to the accounting port of
the next-hop server.
</t>
<t>
When a Status-Realm-Request packet is received by an
Authentication Server for the Target Realm, the
Authentication Server MUST respond with a
Status-Realm-Response packet.
</t>
<t>
If an intermediate RADIUS Proxy is unable to forward a
Status-Realm-Request packet towards the Target Realm, either
because it has no information about how to reach the Target
Realm, or because there are no reachable Authentication
Servers for the Target Realm, the RADIUS Proxy MUST return a
Status-Realm-Response packet containing a
Status-Realm-Response-Code attribute.
</t>
<t>
Status-Realm packets allow the sender to determine the
reachability and status of a Authentication Realm, without
requiring a direct RADIUS connection to a RADIUS Server for
the Target realm, and without requiring credentials for an
authorized user within that realm. This can be useful for
debugging RADIUS authentication issues, identifying routing
issues within a RADIUS proxy fabric, or monitoring realm
availability.
</t>
<t>
Using the Max-Hop-Count attribute defined in this document,
RADIUS Clients can also implement "traceroute-like"
functionality, discovering a series of proxies on route to a
target realm.
</t>
</section>
<section title="RADIUS Loop Prevention Overview">
<t>
RADIUS Proxies are configured to know which next-hop RADIUS
Server to use for a given Target Realm. There is no dynamic
routing protocol or tree-spanning protocol in use, so Proxy
Loops are a common occurence due to misconfiguration. These
loops can be controlled or prevented using
implementation-specific or operator-specific mechanisms, but
it would be useful to have well-defined, common mechanism.
</t>
<t>
The Max-Hop-Count attribute described in this document can
be used to mitigate the damage caused by Proxy Loops. The
Max-Hop-Count attribure is set to a small integer by the
RADIUS Client or First-Hop RADIUS Server. The value is
deprecated each time a RADIUS message is proxied. When the
Max-Hop-Count reaches zero, the request is discarded, ending
the loop.
</t>
<t>
This document also defines a more effective method of
detecting and preventing Proxy Forwarding Loops: RADIUS Loop
Prevention. This document defines a RADIUS
Server-Identifier attribute that is used to uniquely
identify a RADIUS Server. When a RADIUS Proxy receives a
RADIUS Request packet, it checks to see if the Request
contains a Server-Identifier attribute indicating that it
has already processed this packet. If so, it discards the
packet. If not, it adds its own Server Identifier to the
packet before forwarding it.
</t>
<section title="Packet Formats">
<t>
This section describes the RADIUS packet formats for
Status-Realm-Request and Status-Realm-Response packets.
Status-Realm-Requests are sent in the same format, whether
they are sent to the authentication port or the accounting
port.
</t>
<section title="Status-Realm-Request Packet">
<t>
Status-Realm-Request packets reuse the RADIUS packet format,
with the fields and values for those fields as defined in
<xref target="RFC2865"/>, Section 3.
</t>
<t>
A Status-Realm-Request packet MUST include a
Message-Authenticator attribute, as defined in <xref
target="RFC2869"/>, section 5.14. The Message-Authenticator
provides per-packet authentication and integrity protection.
The Authenticator field of a Status-Realm-Request packet
MUST be generated using the same method as that used for the
Request Authenticator field of Access-Request packets.
</t>
<t>
A Status-Realm-Request packets MUST include a User-Name
Attribute, containing the Target Realm for the Request. The
'user' portion of the User-Name SHOULD be ignored, if
present.
</t>
<t>
A Status-Realm-Request message MUST also include a
Max-Hop-Count attribute, as defined above.
</t>
<t>
Status-Realm-Requests MAY include NAS-Identifier, and one of
(NAS-IP-Address or NAS-IPv6-Address). These attributes are
not necessary for the operation of Status-Realm, but may be
useful information to a server that receives those packets.
</t>
<t>
Status-Realm-Request packets MUST NOT contain authentication
credentials (such as User-Password, CHAP-Password,
EAP-Message) or User or NAS accounting attributes (such as
Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets).
</t>
</section>
<section title="Status-Realm-Response Packet">
<t>
Status-Realm-Response packets reuse the RADIUS packet
format, with the fields and values for those fields as
defined in <xref target="RFC2865"/>, Section 3.
</t>
<t>
The Response Authenticator field of a
Status-Realm-Response packet MUST be generated using the
same method used for calculating the Response Authenticator
of an Access-Accept or an Access-Reject sent in response to
an Access-Request, with the Status-Realm-Request Request
Authenticator taking the place of the Access-Request Request
Authenticator.
</t>
<t>
The Status-Realm-Response packet MUST contain a
Status-Realm-Response-Code attribute, as defined below,
indicating the results of the Status-Realm request.
</t>
<t>
The Status-Realm-Response packet MAY contain the following
attributes: Reply-Message, Message-Authenticator,
Max-Hop-Count.
</t>
<t>
Note that when a server responds to a Status-Realm-Request
packet, it MUST NOT send more than one Status-Realm-Response
packet.
</t>
</section>
</section>
<section title="Max-Hop-Count Attribute">
<t>
This section defines a new RADIUS attribute, Max-Hop-Count
(TBD). The value of the Max-Hop-Count attribute is an
integer, as defined in <xref target="RFC8044"/>, Section 3.1.
Valid values are small positive integers, 0 to 255.
</t>
<t>
This attribute is used to limit the number of RADIUS servers
that will proxy a packet before it reaches its final
destination. When a RADIUS server that implements the
Max-Hop-Count Attribute determines that it wants to proxy a
RADIUS Request to another RADIUS Server, it will check the
Max-Hop-Count attribute. If the Max-Hop-Count attribute is
present and the value is zero, the Request MUST NOT be
forwarded and an error response SHOULD be returned, as
appropriate to the request type. If the Max-Hop-Count is
greater than zero, the proxy server MUST decrement the hop
count by 1 before forwarding the request.
</t>
<t>
In the context of Status-Realm-Requests, this attribute can be
used to implement "traceroute-like" functionality. By sending
a series of Status-Realm-Requests with incremented values of
Max-Hop-Count, starting with a Max-Hop-Count value of O, the
RADIUS Client will receive a series of Status-Realm-Responses
from the RADIUS Proxies on the Proxy Path to a given Target
Realm.
</t>
<t>
When used on other types of RADIUS Request messages, this
option can mitigate the damage caused by RADIUS proxy loops. It
is therefore possible that a RADIUS Client or a RADIUS proxy
server will support the Max-Hop-Count attribute, even if they
do not support Status-Realm. When used to limit RADIUS proxy
loops, it is RECOMENDED that the value of the Max-Hop-Count
attribute be set to 32, by default.
</t>
<t>
If this attribute is not present on a RADIUS Request received
from a RADIUS Client, the First-Hop RADIUS Server MAY add this
option, setting it to the default value of 64, or to a
valid, configured value.
</t>
</section>
<section title="Status-Realm-Response-Code Attribute">
<t>
This section defines a new RADIUS attribute,
Status-Realm-Response-Code (TBD). This is of type tlv, as
defined in <zref target="RFC8044"/>, section 3.13. It
contains 3 sub-attributes:
</t>
<t>
<ul>
<li> Response-Code (Type = 1)
<li> Hop-Count (Type = 2)
<li> Responding-Server (Type = 3)
</ul>
</t>
<t>
Response-Code is of type 'integer', as defined in <xref
target="RFC8044"/>, Section 3.1. Exactly one Response-Code
sub-attribute MUST be included in in every
Status-Realm-Response-Code attribute. It will contain one of
the following values:
</t>
<t>
<artwork>
0 The target realm is available
1 No proxy route to the target realm
2 No available servers for the target realm
3 The target realm is missing or invalid
4 Max-Hop-Count exceeded
5-255 Unspecified error, the is unreachable
257 Administratively prohibited, target realm status
unknown
258 Internal error, target realm status unknown
259 Bad Status-Realm-Request, missing or invalid
Target Realm
260 Bad Status-Realm-Request, missing or invalid
Max-Hop-Count, Target Realm status unknown
259-511 Unspecified error, Target Realm status unknown
512+ Reserved
</artwork>
</t>
<t>
Hop-Count is of type 'integer'. If the corresponding
Status-Realm-Request message contained a Max-Hop-Count
attribute, a Hop-Count sub-attribute MUST be included in the
Status-Realm-Response message, with the value matching the
value of Max-Hop-Count when the Request was recevied. If no
Max-Hop-Count attribute was included in the corresponding
Request, this sub-attribute SHOULD be omitted.
</t>
<t>
Responding-Server is of type 'tlv', as defined in <xref
target="RFC8044"/>, Section 3.13. This sub-attribute MUST be
returned in every Status-Realm-Response attribute. The value
field of this sub-attribute contains a Server-Information Attribute
for the responding server, as described below.
</t>
</section>
<section title="Server-Information Attribute">
<t>
The Server-Information attribute is used to identify a
specific RADIUS Server. It MAY be added to any RADIUS Request
message to indicate that a particular RADIUS Server has
processed the Request. If present in a RADIUS Request, it
should be copied into the corresponding RADIUS Response.
RADIUS Servers SHOULD NOT add Server-Information attributes to
Response messages when processing Responses.
</t>
<t>
This attribute is also included as a sub-attribute within the
Status-Realm-Response-Code attribute, defined above, to
indicate which RADIUS Server has sent the
Status-Realm-Response message.
</t>
<t>
This attribute is of type 'tlv', as defined in <xref
target="RFC8044"/>, Section 3.13. The value of this attribute consists of a set of
sub-attributes, all of type 'tlv'. Each sub-attribute
contains an identifier for a RADIUS proxy. The
Proxy-Identifier MUST have at least one sub-attribute and MAY
have more than one sub-attribute. If multiple sub-attributes
are present, a RADIUS proxy MUST match all of the
sub-attributes in order to match the identifier.
</t>
<t>
The following sub-attributes may be included in the value
field of a Proxy-Information Attribute. The Type code for
each sub-attribute is included in parenthesis.
<ul>
<li>Server-Name (Type = 1)</li>
<li>Server-Identifier (Type = 2)</li>
<li>Hop-Count (Type = 3)</li>
</ul>
</t>
<t>
The Server-Operator is of type 'string'. It is the analogue of the Operator-Name, as defined in <xref
target="RFC5580"/>.
</t>
<t>
The Server-Identifier in an analogue of the NAS-Identifier
defined in <xref target="RFC2865"/>. It indicates the name of
this particular proxy server. This field is used to identify
which server processed the Request, among those operated by
the organization indicated in the Server-Operator
sub-attribute.
</t>
</section>
<section title="Status-Realm Implementation Requirements">
<t>
This section describes implementation details and requirements
for RADIUS Clients and servers that support Status-Realm.
</t>
<section title="RADIUS Client Requirements">
<t>
When Status-Realm-Request packets are sent from a RADIUS Client,
they MUST NOT be retransmitted. Instead, the Identity field
MUST be changed every time a packet is transmitted. The old
packet should be discarded, and a new Status-Realm-Request
packet should be generated and sent, with new Identity and
Authenticator fields.
</t>
<t>
RADIUS Clients MUST include the Message-Authenticator attribute in
all Status-Realm-Request packets. Failure to do so would
mean that the packets could be trivially spoofed, leading to
potential denial-of-service (DoS) attacks.
</t>
<t>
The RADIUS Client MUST include a User-Name attribute in the
request. The "user" portion of the username SHOULD be
omitted. The "realm" portion of the username is the
target realm for the Status-Realm request.
</t>
<t>
RADIUS Clients that support Status-Realm-Requests SHOULD allow a
user or administrator to set or configure the Count value of
the Max-Hop-Count Attribute described above. If a different
value is not indicated, the RADIUS Client SHOULD include a
Max-Hop-Count attribute with a Count value of 32 in the
Status-Realm-Request packet to prevent the possibility that
Status-Realm-Requests will loop indefinitely.
</t>
<t>
The RADIUS Client MAY increment packet counters as a result of
sending a Status-Realm-Resquest or receiving a
Status-Realm-Response. The RADIUS Client MUST NOT perform any
other action that is normally performed when it receives a
Response packet, such as permitting a user to have login
access to a port.
</t>
<t>
RADIUS Clients MAY send Status-Realm-Request packets to the RADIUS
destination ports from the same source port(s) used to send
other Request packets. Other RADIUS Clients MAY choose to send
Status-Realm-Request packets from a unique source port that
is not used to send other Request packets.
</t>
<t>
In the case where a RADIUS Client sends a Status-Realm-Request
packets from a source port also used to send other Request
packets, the Identifier field MUST be unique across all
outstanding Request packets for that source port,
independent of the value of the RADIUS Code field for those
outstanding requests. Once the RADIUS Client has either received a
corresponding Status-Realm-Response packet or determined
that the Status-Realm-Request has timed out, it may reuse
the Identifier in another Request packet.
</t>
<t>
The RADIUS Client MUST validate the Response Authenticator in the
Status-Realm-Response. If the Response Authenticator is not
valid, the packet MUST be silently discarded. If the
Response Authenticator is valid, then the packet MUST be
deemed to be a valid response.
</t>
</section>
<section title="Server Requirements">
<t>
Servers SHOULD permit administrators to globally enable or
disable the acceptance of Status-Realm-Request packets. The
default SHOULD be that acceptance is enabled. Servers
SHOULD also permit administrators to enable or disable
acceptance of Status-Realm-Request packets on a per-RADIUS Client
basis. The default SHOULD be that acceptance is enabled.
</t>
<t>
If a server does not support Status-Realm, or if it is
configured not to respond to Status-Realm-Requests, then it
MUST silently discard any Status-Realm-Requests messages
that it receives. If a server receives a
Status-Realm-Request packet from a RADIUS Client from which
it is configured not to accept Status-Realm-Requests, then
it MUST silently discard the message.
</t>
<t>
If a server supports Status-Realm, is
configured to respond to Status-Realm-Requets, and receives a
Status-Realm-Request packet from a permitted RADIUS Client, it MUST
first validate the Message-Authenticator attribute as
defined in <xref target="RFC3579"/>, Section 3.2. Packets
failing this validation MUST be silently discarded.
</t>
<t>
If the Status-Realm-Request passes Message-Authenticator
validation, then the server should check if the Target Realm
matches a local realm served by this Server. If it does
match, the server should send a Status-Realm-Response packet
indicating that status of the Target Realm, reachable or
unreachable (Status-Server-Response-Code = 0 or 2).
</t>
<t>
If the Target Realm does not match a local realm, then
the server should determine whether it is configured to
proxy packets towards the Target Realm. If so, the
server should implement the Proxy Server Requirements,
below. Servers SHOULD ignore the value of the "user" portion
of the User-Name attribute, if any.
</t>
<t>
Servers SHOULD NOT discard Status-Realm packets merely
because they have recently sent the RADIUS Client a response
packet. The query may have originated from an administrator
who does not have access to the response packet stream or
one who is interested in obtaining additional information
about the server.
</t>
<t>
The server MAY decide to send an error response to a
Status-Realm-Request packet based on local-site policy. For
example, a server that is running but is unable to perform
its normal duties SHOULD send a Status-Realm-Response packet
indicating an internal error (Status-Server-Response-Code =
257). This situation can happen, for example, when a server
requires access to a database for normal operation, but the
connection to that database is down. Or, it may happen when
the accepted load on the server is lower than the current
load.
</t>
<t>
The server MAY increment packet counters or create log
entries as a result of receiving a Status-Realm-Request
packet or sending a Status-Realm-Response packet. The
server SHOULD NOT perform any other action that is normally
performed when it receives a Request packet, other than
sending a Response packet.
</t>
<t>
If the Status-Realm-Request packet includes a Max-Hop-Count
attribute, that attribute (with its current value) MUST be
returned in any corresponding Status-Realm-Response packet.
</t>
<t>
Note that <xref target="RFC2865"/>, Section 3, defines a
number of RADIUS Codes, but does not make statements about
which Codes are valid for port 1812. In contrast, <xref
target="RFC2866"/>, Section 3, specifies that only RADIUS
Accounting packets are to be sent to port 1813. This
specification is compatible with the standards-track
specification <xref target="RFC2865"/>, as it defines a new
Message Type Code for packets to port 1812. This
specification is not compatible with the informational
document <xref target="RFC2866"/>, as it adds a new Code
(Status-Realm-Request) that is valid for port 1813.
</t>
</section>
<section title="Proxy Server Requirements">
<t>
Many RADIUS servers act as RADIUS proxies, forwarding
requests to other RADIUS servers. Such servers SHOULD proxy
Status-Realm-Request packets to enable RADIUS Clients to determine
the status of Authentication Realms that are not directly
connected to the RADIUS Client.
</t>
<t>
RADIUS proxies that support Status-Realm-Requests MUST
support the Max-Hop-Count attribute defined above. Before
forwarding a Status-Realm-Request packet, a proxy MUST check
the Max-Hop-Count Attribute. If the Max-Hop-Count attribute
is present and the Count is zero (0), the proxy MUST send a
Status-Realm-Response indicating that the hop count has been
exceeded (Status-Server-Response-Code = 4), and MUST NOT
forward the packet. If the Max-Hop-Count attribute is
present, and the Count value is not zero, the proxy MUST
decrement the Max-Hop-Count value before forwarding the
packet.
</t>
<t>
The RADIUS proxy MUST check the "realm" portion of the
User-Name attribute in the Status-Realm-Request to determine
the Target Realm for the request. If the target
realm is missing or malformed, the RADIUS proxy MUST send a
Status-Realm-Response indicating an invalid realm
(Status-Server-Response-Code = 3). If the realm is properly
formed, the Status-Realm-Request packet should be proxied
toward the Target Realm, using the same next-hop RADIUS
server that the proxy server would use for other request
packets received on the same port.
</t>
<t>
In some cases, a RADIUS proxy may not have an available
next-hop RADIUS server for the Target Realm. In that
case, the RADIUS proxy server MUST send a
Status-Realm-Response packet indicating that there is no
proxy route to the Target Realm
(Status-Server-Response-Code = 1).
</t>
<t>
In cases where a RADIUS proxy is configured to have a direct
connection to the RADIUS server(s) of the Target Realm,
but is configured not to forward Status-Realm-Request
packets to the target server(s), the proxy MAY use other
methods to determine the status of the Target Realm
(such as Status-Server packets or recent Access-Request
state information), and send a Status-Realm-Response
indicating the determined state of the Target Realm
(Status-Server-Response-Code = 0 or 2). If the proxy is
configured not to forward Status-Realm-Request packet to the
Target Realm and does not have other methods to detect
the status of the Target Realm, it SHOULD return a
Status-Realm-Response packet indicating that the request is
administrative prohibited (Status-Server-Response-Code =
257).
</t>
<t>
If the Status-Realm-Request packet includes a Max-Hop-Count
attribute, that attribute (with its current value) MUST be
returned in any corresponding Status-Realm-Response packet.
</t>
</section>
</section>
<section title="Status-Realm Packet Flow Implementation Status">
<t>
There is an initial implementation of Status-Realm available
here:
</t>
<t>
https://github.com/alandekok/freeradius-server/tree/Status-Realm
</t>
<section title="Packet Flow Examples">
<t>
Message exchange examples are TBD.
</t>
</section>
</section>
<section title="Loop Detection Implementation Requirements">
<t>
This section describes implementation details and requirements
for RADIUS Clients, Servers and Proxies that support Proxy
Loop Detection.
</t>
<section title="Server Requirements">
<t>
</t>
</section>
<section title="Proxy Requirements">
<t>
</t>
</section>
</section>
<section title="Proxy Loop Detection Implementation Status">
<t>
The Proxy Loop Detection mechanism is similar to RADIUS
Vendor-Specific attribute used today to detect RADIUS Proxy
Loops. Unlike the Vendor-Specific attributes in use today,
this mechanism includes server information within a single,
globally-defrined attribute, rather than requiring that a
different attribute type be allocated for each RADIUS Server
operator.
</t>
</section>
<section title="Management Information Base (MIB) Considerations">
<t>
Status-Realm-Request packets are sent to the defined RADIUS
ports, so they can affect the <xref target="RFC4669"/> and
<xref target="RFC4671"/> RADIUS server MIB modules. <xref
target="RFC4669"/> defines a counter named
radiusAuthServTotalUnknownTypes that counts the number of
RADIUS packets of unknown type that were received. <xref
target="RFC4671"/> defines a similar counter named
radiusAccServTotalUnknownTypes. Implementations not
supporting Status-Realm-Requests or implementations that are
configured not to respond to Status-Realm-Request packets MUST
use these counters to track received Status-Realm packets.
</t>
<t>
If, however, Status-Realm-Requests are supported and the server
is configured to respond as described above, then the counters
defined in <xref target="RFC4669"/> and <xref
target="RFC4671"/> MUST NOT be used to track
Status-Realm-Request or Status-Realm-Response packets. That
is, when a server fully implements Status-Realm, the counters
defined in <xref target="RFC4669"/> and <xref
target="RFC4671"/> MUST be unaffected by the transmission or
reception of packets relating to Status-Realm-Requests.
</t>
<t>
If a server supports Status-Realm-Request and the <xref
target="RFC4669"/> or <xref target="RFC4671"/> MIB modules,
then it SHOULD also support vendor-specific MIB extensions
dedicated solely to tracking Status-Realm-Request and
Status-Realm-Response packets. Any definition of the server
MIB modules for Status-Realm-Requests is outside of the scope
of this document.
</t>
</section>
<section title="Interaction with RADIUS Client MIB Modules">
<t>
RADIUS Clients implementing Status-Realm-Request MUST NOT increment
<xref target="RFC4668"/> or <xref target="RFC4670"/> counters
upon reception of Status-Realm-Response packets. That is,
when a RADIUS Client fully implements Status-Realm-Request, the counters
defined in <xref target="RFC4668"/> and <xref
target="RFC4670"/> MUST be unaffected by the transmission or
reception of packets relating to Status-Realm.
</t>
<t>
If an implementation supports Status-Realm-Request and the <xref
target="RFC4668"/> or <xref target="RFC4670"/> MIB modules,
then it SHOULD also support vendor-specific MIB extensions
dedicated solely to tracking Status-Realm requests and
responses. Any definition of the RADIUS Client MIB modules for
Status-Realm-Requests is outside of the scope of this document.
</t>
</section>
<section title="Table of Attributes">
<t>
The following table provides a guide to which attributes may
be found in Status-Realm-Request and Status-Realm-Response
packets, and in what quantity. Attributes other than the ones
listed below SHOULD NOT be found in a Status-Realm-Request
packet.
</t>
<t>
<artwork>
Status- Status-
Realm- Realm-
Request Response
1 1 1 User-Name
0 0 2 User-Password
0 0 3 CHAP-Password
0-1 0 4 NAS-IP-Address (Note 1)
0 0+ 18 Reply-Message
0+ 0+ 26 Vendor-Specific
0-1 0 32 NAS-Identifier (Note 1)
0 0 79 EAP-Message
1 0-1 80 Message-Authenticator
0-1 0 95 NAS-IPv6-Address (Note 1)
0 1 (TBD) Status-Realm-Response-Code
1 1 (TBD) Max-Hop-Count (see above)
0 0 103-121 Digest-*
</artwork>
</t>
<t>
Note 1: Status-Realm-Request packet SHOULD contain one of
(NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or
both NAS-Identifier and one of (NAS-IP-Address or
NAS-IPv6-Address).
</t>
<t>
The following table defines the meaning of the table entries
included above:
</t>
<t>
<artwork>
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
the packet.
0-1 Zero or one instance of this attribute MAY be present in
the packet.
1 Exactly one instance of this attribute MUST be present in
the packet.
</artwork>
</t>
</section>
<section title="IANA Considerations">
<t>
This document defines the Status-Realm-Request (TBD) and the
Status-Realm-Response (TBD) RADIUS Packet Type Codes, both of which
should be assigned by IANA from the Unassigned block of RADIUS
Packet Type Codes.
</t>
<t>
This document also defines two new RADIUS attributes,
Max-Hop-Count (TBD) and Status-Realm-Response-Code (TBD),
which should be assigned by IANA from an Unassigned block of
RADIUS Attribute Types, such as the Unassigned block for
Extended-Attribute-1.
</t>
</section>
<section title="Security Considerations">
<t>
Status-Realm-Request packets are similar to Access-Request
packets, and are therefore subject to the same security
considerations as described in <xref target="RFC2865"/>,
Section 8. Status-Realm packets also use the
Message-Authenticator attribute, and are therefore subject to
the same security considerations as <xref target="RFC3579"/>,
Section 4.
</t>
<t>
We reiterate that all Status-Realm-Request packets MUST
contain a Message-Authenticator. Servers not checking the
Message-Authenticator attribute could respond to Status-Realm
packets from an attacker, potentially enabling a reflected DoS
attack onto a real RADIUS Client.
</t>
<t>
Where this document differs from <xref target="RFC2865"/> is
that it defines a new request/response method in RADIUS: the
Status-Realm-Request and Status-Realm-Response. The
Status-Realm-Request is similar to the previously described