File: rfc2903.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1459 lines) | stat: -rw-r--r-- 60,627 bytes parent folder | download | duplicates (5)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459






Network Working Group                                         C. de Laat
Request for Comments: 2903                            Utrecht University
Category: Experimental                                          G. Gross
                                                     Lucent Technologies
                                                              L. Gommans
                                                 Enterasys Networks EMEA
                                                           J. Vollbrecht
                                                               D. Spence
                                                Interlink Networks, Inc.
                                                             August 2000


                        Generic AAA Architecture

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo proposes an Authentication, Authorization, Accounting (AAA)
   architecture that would incorporate a generic AAA server along with
   an application interface to a set of Application Specific Modules
   that could perform application specific AAA functions.  A separation
   of AAA functions required in a multi-domain environment is then
   proposed using a layered protocol abstraction.  The long term goal is
   to create a generic framework which allows complex authorizations to
   be realized through a network of interconnected AAA servers.
















de Laat, et al.               Experimental                      [Page 1]

RFC 2903                Generic AAA Architecture             August 2000


Table of Contents

   1. Introduction ................................................  2
   2. Generic AAA Architecture ....................................  4
      2.1. Architectural Components of a Generic AAA Server .......  4
           2.1.1. Authorization Rule Evaluation ...................  4
           2.1.2. Application Specific Module (ASM) ...............  5
           2.1.3. Authorization Event Log .........................  6
           2.1.4. Policy Repository ...............................  6
           2.1.5. Request Forwarding ..............................  6
      2.2. Generic AAA Server Model ...............................  6
           2.2.1. Generic AAA Server Interactions .................  7
           2.2.2. Compatibility with Legacy Protocols .............  7
           2.2.3. Interaction between the ASM and the Service .....  9
           2.2.4. Multi-domain Architecture ....................... 10
      2.3. Model Observations ..................................... 10
      2.4. Suggestions for Future Work ............................ 11
   3. Layered AAA Protocol Model .................................. 12
      3.1. Elements of a Layered Architecture ..................... 14
           3.1.1. Service Layer Abstract Interface Primitives ..... 14
           3.1.2. Service Layer Peer End Point Name Space ......... 14
           3.1.3. Peer Registration, Discovery, and Location
           Resolution ............................................. 14
           3.1.4. Trust Relationships Between Peer End Points ..... 14
           3.1.5. Service Layer Finite State Machine .............. 15
           3.1.6. Protocol Data Unit Types ........................ 15
      3.2. AAA Application Specific Service Layer ................. 15
      3.3. Presentation Service Layer ............................. 16
      3.4. AAA Transaction/Session Management Service Layer ....... 17
      3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20
      3.6. AAA-TSM Layer End Point Name Space ..................... 21
      3.7. Protocol Stack Examples ................................ 22
   4. Security Considerations ..................................... 22
   Glossary ....................................................... 23
   References ..................................................... 24
   Authors' Addresses ............................................. 24
   Full Copyright Statement ....................................... 26

1.  Introduction

   The work for this memo was done by a group that originally was the
   Authorization subgroup of the AAA Working Group of the IETF.  When
   the charter of the AAA working group was changed to focus on MobileIP
   and NAS requirements, the AAAarch Research Group was chartered within
   the IRTF to continue and expand the architectural work started by the
   Authorization subgroup.  This memo is one of four which were created
   by the subgroup.  This memo is a starting point for further work
   within the AAAarch Research Group.  It is still a work in progress



de Laat, et al.               Experimental                      [Page 2]

RFC 2903                Generic AAA Architecture             August 2000


   and is published so that the work will be available for the AAAarch
   subgroup and others working in this area, not as a definitive
   description of architecture or requirements.

   The authorization subgroup of the AAA Working Group proposed an "AAA
   Authorization Framework" [2] illustrated with numerous application
   examples [3] which in turn motivates a proposed list of authorization
   requirements [4].  This memo builds on the framework presented in [2]
   by proposing an AAA infrastructure consisting of a network of
   cooperating generic AAA servers communicating via a standard
   protocol.  The protocol should be quite general and should support
   the needs of a wide variety of applications requiring AAA
   functionality.  To realize this goal, the protocol will need to
   operate in a multi-domain environment with multiple service providers
   as well as entities taking on other AAA roles such as User Home
   Organizations and brokers.  It should be possible to combine requests
   for multiple authorizations of different types in the same
   authorization transaction.  The AAA infrastructure will be required
   to forward the components of such requests to the appropriate AAA
   servers for authorization and to collect the authorization decisions
   from the various AAA servers consulted.  All of this activity is
   perfectly general in nature and can be realized in the common
   infrastructure.

   But the applications requiring AAA services will each have their own
   unique needs.  After a service is authorized, it must be configured
   and initialized.  This will require application specific knowledge
   and may require application specific protocols to communicate with
   application specific service components.  To handle these application
   specific functions, we propose an application interface between a
   generic AAA server and a set of one or more Application Specific
   Modules (ASMs) which can carry out the unique functionality required
   by each application.

   Since the data required by each application for authentication,
   authorization, or accounting may have unique structure, the standard
   AAA protocol should allow the encapsulation of opaque units of
   Application Specific Information (ASI).  These units would begin with
   a standard header to allow them to be forwarded by the generic
   infrastructure.  When delivered to the final destination, an ASI unit
   would be passed by a generic AAA server across its program interface
   to an appropriate ASM for application specific processing.
   Nevertheless, it remains a goal of the design for information units
   to be encoded in standard ways as much as possible so as to enable
   processing by a generic rule based engine.






de Laat, et al.               Experimental                      [Page 3]

RFC 2903                Generic AAA Architecture             August 2000


   The interactions of the generic AAA server with the Application
   Specific Modules and with each other to realize complex AAA functions
   is explored in section 2.  Then, in section 3, we attempt to further
   organize the AAA functions into logical groups using a protocol
   layering abstraction.  This abstraction is not intended to be a
   reference model ready to be used for protocol design.  At this point
   in the work, there are numerous questions that need to be addressed
   and numerous problems that remain to be solved.  It may be that an
   abstraction other than layering will prove to be more useful or, more
   likely, that the application layer will require some substructure of
   its own.

   Finally, in section 4, we show how the security requirements
   identified in [4] can be met in the generic server and the
   Application Specific Modules by applying security techniques such as
   public key encryption or digital signatures to the Application
   Specific Information units individually, so that different
   stakeholders in the AAA server network can protect selected
   information units from being deciphered or altered by other
   stakeholders in an authentication, authorization, or accounting
   chain.

2.  Generic AAA Architecture

   For the long term we envision a generic AAA server which is capable
   of authenticating users, handling authorization requests, and
   collecting accounting data.  For a service provider, such a generic
   AAA server would be interfaced to an application specific module
   which manages the resource for which authorization is required.
   Generic AAA components would also be deployed in other administrative
   domains performing authorization functions.

2.1.  Architectural Components of a Generic AAA Server

2.1.1.  Authorization Rule Evaluation

   The first step in the authorization process is for the user or an
   entity operating on the user's behalf to submit a well-formatted
   request to an AAA server.  A generic AAA server has rules (logic
   and/or algebraic formulas) to inspect the request and come to an
   authorization decision.  The first problem which arises is that
   Application Specific Information (ASI) has to be separated from the
   underlying logic for the authorization.  Ideally the AAA server would
   have a rule based engine at this point which would know the logic
   rules and understand some generic information in the request, but it
   would not know anything about application specific information except
   where this information can be evaluated to give a boolean or
   numerical value.  It should be possible to create rules that refer to



de Laat, et al.               Experimental                      [Page 4]

RFC 2903                Generic AAA Architecture             August 2000


   data elements that were not considered when the application was
   created.  For example, one could request to do a remote virtual
   control room experiment from home using a dialin provider. The
   request would only be successful if the dialin access server allows
   it and if there is bandwidth available (bandwidth broker) and if the
   experimenter has the money to pay for it (E-Commerce).  Possibly the
   people who specified the bandwidth broker protocol did not think of
   combining quality of service with a network service authorization in
   a single AAA request, but this generic model would allow it.

   +------+      +-------+      +-------+      +-------+      +-------+
   |      | auth |       | auth |       | auth |       | auth |       |
   |      |<---->|  AAA  |<---->|  AAA  |<---->|  AAA  |<---->|  AAA  |
   |      |      |       |      |       |      |       |      |       |
   |      |      +-------+      +-------+      +-------+      +-------+
   | User |          |              |              |              |
   |      |          |          +-------+      +-------+      +-------+
   |      |          |          |  BB   |      |  BB   |      |Budget |
   |      |          |          +-------+      +-------+      +-------+
   |      |          |              |              |
   |      |      +-------+          |              |
   |      |      |dial in|      +-------+      +-------+
   |      |<====>|service|<====>|network|<====>|network|<===> Experiment
   +------+      +-------+      +-------+      +-------+

     user <-> dialin <-> backbone with BB <-> <remote experiment>

     Fig. 1 -- Example of a Multi Domain Multi Type of Server Request

2.1.2.  Application Specific Module (ASM)

   Ultimately an AAA server needs to interact with an application
   specific module (ASM).  In a service provider, the ASM would manage
   resources and configure the service equipment to provide the
   authorized service.  It might also involve itself in the
   authorization decision because it has the application specific
   knowledge required.  A user home organization (UHO) may require ASMs
   as well, to perform application specific user authorization
   functions.  For example, a UHO ASM might be required to access
   certain application specific databases or interpret application
   specific service level specifications.

   Whatever the role of an administration relative to an authorization
   decision,  the capabilities of the generic AAA server and the
   interface between it and the ASMs remains the same.  This interface
   may be an Application Program Interface (API) or could even be a
   protocol based interface.  In this model, however, the application




de Laat, et al.               Experimental                      [Page 5]

RFC 2903                Generic AAA Architecture             August 2000


   specific module is regarded as as separate architectural component
   from the generic AAA server.  As such, it must be addressable and
   must therefore be part of a global naming space.

2.1.3.  Authorization Event Log

   For auditing purposes, the generic server must have some form of
   database to store time-stamped events which occur in the AAA server.
   This database can be used to account for authorizations which were
   given, but it can also be used in rules.  One can imagine rules in
   which an authorization is only given if some other event was logged
   in the past.  With the aid of certificates, this database could
   support non-repudiation.

2.1.4.  Policy Repository

   A database containing the available services and resources about
   which authorization decisions can be made and the policy rules to
   make them is also needed.  Here too, the naming space for the
   services and resources is important since they must be addressable
   from other AAA servers to be able to build complex authorization
   requests.

2.1.5.  Request Forwarding

   Due to the multiple administrative domain (multi-kingdom) nature of
   the AAA problem, a mechanism to forward messages between AAA servers
   is needed.  The protocol by which two AAA servers communicate should
   be a peer-to-peer protocol.

2.2.  Generic AAA Server Model

   With the implementation of the above mentioned components, the AAA
   server would be able to handle AAA requests.  It would inspect the
   contents of the request, determine what authorization is requested,
   retrieve the policy rules from the repository, perform various local
   functions, and then choose one of the following options to further
   process each of the components of the request:

   a) Let the component be evaluated by an attached ASM.

   b) Query the authorization event log or the policy repository for the
      answer.

   c) Forward the component(s) to another AAA server for evaluation.

   In the following sections we present the generic model.




de Laat, et al.               Experimental                      [Page 6]

RFC 2903                Generic AAA Architecture             August 2000


2.2.1.  Generic AAA Server Interactions

   Figure 2 illustrates a generic AAA Server with connections to the
   various architectural components described above. In this model, the
   user or another AAA server contacts the AAA server to get
   authorization, and the AAA server interacts with the service.  The
   request is sent to the AAA server using the future AAA protocol.  The
   server interacts with the service via a second protocol which we have
   labeled as type "2" in the figure.  We say no more of the type 2
   protocol than that it must support some global naming space for the
   application specific items.  The same holds for the type 3
   communication used to access the repository.

                         +------------------+
                         |                  |
   request  <-----1----->|Generic AAA Server|<---1---> AAA server
                         |Rule based engine |
                         |                  |\
                         +------------------+ 3 +------------+
                                  ^            \| Policy and |
                                  |             | event      |
                                  2             | repository |
                                  |             +------------+
                                  v
                         +------------------+
                         |   Application    |
                         |     Specific     |
                         |      Module      |
                         +------------------+

       The numbers in the links denote types of communication.

              Fig. 2 -- Generic AAA Server Interactions

2.2.2.  Compatibility with Legacy Protocols

   Because of the widespread deployment of equipment that implements
   legacy AAA protocols and the desire to realize the functionality of
   the new AAA protocol while protecting the investment in existing
   infrastructure, it may be useful to implement a AAA gateway function
   that can encapsulate legacy protocol data units within the messages
   of the new protocol.  Use of this technique, for example, would allow
   Radius attribute value pairs to be encapsulated in Application
   Specific Information (ASI) units of the new protocol in such a way
   that the ASI units can be digitally signed and encrypted for end-to-
   end protection between a service provider's AAA server and a home AAA
   server communicating via a marginally trusted proxy AAA server.  The
   service provider's NAS would communicate via Radius to the service



de Laat, et al.               Experimental                      [Page 7]

RFC 2903                Generic AAA Architecture             August 2000


   provider's AAA server, but the AAA servers would communicate among
   themselves via the new AAA protocol.  In this case, the AAA gateway
   would be a software module residing in the service provider's AAA
   server.  Alternatively the AAA gateway could be implemented as a
   standalone process.

   Figure 3 illustrates an AAA gateway.  Communication type 4 is the
   legacy protocol.  Communication type 1 is the future standard AAA
   protocol.  And communication type 2 is for application specific
   communication to Application Specific Modules (ASMs) or Service
   Equipment.

                    +-------+
                    |  AAA  |<---1---> to AAA server as in fig. 2
   request <---4--->|GateWay|
                    |       |<---2---> optionally to ASM/service
                    +-------+

   The numbers in the links denote types of communication.

               Fig. 3 -- AAA Gateway for Legacy AAA Protocols






























de Laat, et al.               Experimental                      [Page 8]

RFC 2903                Generic AAA Architecture             August 2000


2.2.3.  Interaction between the ASM and the Service

   In a service provider, the Application Specific Module (ASM) and the
   software providing the service itself may be tightly bound into a
   single "Service Application".  In this case, the interface between
   them is just a software interface.  But the service itself may be
   provided by equipment external to the ASM, for example, a router in
   the bandwidth broker application.  In this case, the ASM communicates
   with the service via some protocol.  These two possibilities are
   illustrated in figure 4.  In both cases, we have labeled the
   communication between the ASM and the service as communication type
   5, which of course, is service specific.

                            |                  |
             +--------------|----+             |
             | Service      2    |             2
             | Application  |    |             |
             |  +-------------+  |      +-------------+
             |  | Application |  |      | Application |
             |  |  Specific   |  |      |  Specific   |
             |  |   Module    |  |      |   Module    |
             |  +-------------+  |      +-------------+
             |         |         |             |
             |         5         |             5
             |         |         |             |
             |  +-------------+  |      +-------------+
             |  |   Service   |  |      |   Service   |
             |  |             |  |      |  Equipment  |
             |  +-------------+  |      +-------------+
             +-------------------+

          Fig. 4 -- ASM to Service Interaction (two views)



















de Laat, et al.               Experimental                      [Page 9]

RFC 2903                Generic AAA Architecture             August 2000


2.2.4.  Multi-domain Architecture

   The generic AAA server modules can use communication type 1 to
   contact each other to evaluate parts of requests.  Figure 5
   illustrates a network of generic AAA servers in different
   administrative domains communicating via communication type 1.

                                                  +-----+
                                         o--------| AAA |---->...
                                        /         |     |
                                       /          +-----+\
                                      /              |    \+----+
                                     /            +-----+  | RP |
                                    /             | ASM |  +----+
    +--------+      +-----+        /              |     |
    | Client |------| AAA |-------o               +-----+
    +--------+      |     |        \
                    +-----+        \
                       |    +----+  \      +-----+
                    +-----+  | RP |   o-----| AAA |---->...
                    | ASM |  +----+         |     |
                    |     |                 +-----+\
                    +-----+                    |    \+----+
                                            +-----+  | RP |
                                            | ASM |  +----+
                                            |     |
                                            +-----+

      The AAA servers use only communication type 1 to communicate.
      ASM = Application Specific Module
      RP  = Repository

      Fig. 5 -- Multi-domain Multi-type of Service Architecture

2.3.  Model Observations

   Some key points of the generic architecture are:

   1) The same generic AAA server can function in all three
      authorization models: agent, pull, and push [2].

   2) The rule based engine knows how to evaluate logical formulas and
      how to parse AAA requests.

   3) The Generic AAA server has no knowledge whatsoever about the
      application specific services so the application specific
      information it forwards is opaque to it.




de Laat, et al.               Experimental                     [Page 10]

RFC 2903                Generic AAA Architecture             August 2000


   4) Communication types 1, 2, and 3 each present their own naming
      space problems.  Solving these problems is fundamental to
      forwarding AAA messages, locating application specific entities,
      and locating applicable rules in the rule repositories.

   5) A standard AAA protocol for use in communication type 1 should be
      a peer-to-peer protocol without imposing client and server roles
      on the communicating entities.

   6) A standard AAA protocol should allow information units for
      multiple different services belonging to multiple different
      applications in multiple different administrative domains to be
      combined in a single AAA protocol message.

2.4.  Suggestions for Future Work

   It is hoped that by using this generic model it will be feasible to
   design a AAA protocol that is "future proof", in a sense, because
   much of what we do not think about now can be encoded as application
   specific information and referenced by policy rules stored in a
   policy repository.  From this model, some generic requirements arise
   that will require some further study.  For example, suppose a new
   user is told that somewhere on a specific AAA server a certain
   authorization can be obtained.  The user will need a AAA protocol
   that can:

   1) send a query to find out which authorizations can be obtained from
      a specific server,

   2) provide a mechanism for determining what components must be put in
      an AAA request for a specific authorization, and

   3) formulate and transmit the authorization request.

   Some areas where further work is particularly needed are in
   identifying and designing the generic components of a AAA protocol
   and in determining the basis upon which component forwarding and
   policy retrieval decisions are made.

   In addition to these areas, there is a need to explore the management
   of rules in a multi-domain AAA environment because the development
   and future deployment of a generic multi-domain AAA infrastructure is
   largely dependent on its manageability.  Multi-domain AAA
   environments housing many rules distributed over several AAA servers
   quickly become unmanageable if there is not some form of automated
   rule creation and housekeeping.  Organizations that allow their
   services to be governed by rules, based on some form of commercial
   contract, require the contract to be implemented with the least



de Laat, et al.               Experimental                     [Page 11]

RFC 2903                Generic AAA Architecture             August 2000


   possible effort.  This can, for example, be achieved in a scalable
   fashion if the individual user or user organization requesting a
   service is able to establish the service itself.  This kind of
   interaction requires policy rule establishment between AAA servers
   belonging to multiple autonomous administrative domains.

3.  Layered AAA Protocol Model

   In the previous section, we proposed the idea of a generic AAA server
   with an interface to one or more Application Specific Modules (ASMs).
   The generic server would handle many common functions including the
   forwarding of AAA messages between servers in different
   administrative domains.  We envision message transport, hop-by-hop
   security, and message forwarding as clearly being functions of the
   generic server.  The application specific modules would handle all
   application specific tasks such as communication with service
   equipment and access to special purpose databases.  Between these two
   sets of functions is another set of functions that presumably could
   take place in either the generic server or an ASM or possibly by a
   collaboration of both.  These functions include the evaluation of
   authorization rules against data that may reside in various places
   including attributes from the authorization request itself.  The more
   we can push these functions down into the generic server, the more
   powerful the generic server can be and the simpler the ASMs can be.

   One way of organizing the different functions mentioned above would
   be to assign them to a layered hierarchy.  In fact, we have found the
   layer paradigm to be a useful one in understanding AAA functionality.
   This section explores the use of a layered hierarchy consisting of
   the following AAA layers as a way of organizing the AAA functions:

         Application Specific Service Layer
         Presentation Service Layer
         Transaction/Session Management Service Layer
         Reliable/Secure Transport Service Layer

   Nevertheless, the interface between the generic AAA server and the
   ASMs proposed in the previous section may be more complex than a
   simple layered model would allow.  Even the division of functionality
   proposed in this section goes beyond a strict understanding of
   layering.  Therefore this paper can probably best be understood as
   the beginnings of a work to understand and organize the common
   functionality required for a general purpose AAA infrastructure
   rather than as a mature reference model for the creation of AAA
   protocols.






de Laat, et al.               Experimental                     [Page 12]

RFC 2903                Generic AAA Architecture             August 2000


   In our view of AAA services modeled as a hierarchy of service layers,
   there is a set of distributed processes at each service layer that
   cooperate and are responsible for implementing that service layer's
   functions.  These processes communicate with each other using a
   protocol specialized to carry out the functions and responsibilities
   assigned to their service layer.  The protocol at service layer n
   communicates to its peers by depending on the services available to
   it from service layer n-1.  The service layer n also has a protocol
   end point address space, through which the peer processes at service
   layer n can send messages to each other.  Together, these AAA service
   layers can be assembled into an AAA protocol stack.

   The advantage of this approach is that there is not just one
   monolithic "AAA protocol".  Instead there is a suite of protocols,
   and each one is optimized to solve the problems found at its layer of
   the AAA protocol stack hierarchy.

   This approach realizes several key benefits:

   -  The protocol used at any particular layer in the protocol stack
      can be substituted for another functionally equivalent protocol
      without disrupting the services in adjacent layers.

   -  Requirements in one layer may be met without impact on protocols
      operating in other layers.  For example, local security
      requirements may dictate the substitution of stronger or weaker
      "reliable secure transport" layer security algorithms or
      protocols.  These can be introduced with no change or awareness of
      the substitution by the layers above the Reliable/Secure Transport
      layer.

   -  The protocol used for a given layer is simpler because it is
      focused on a specific narrow problem that is assigned to its
      service layer. In particular, it should be feasible to leverage
      existing protocol designs for some aspects of this protocol stack
      (e.g. CORBA GIOP/CDR for the presentation layer).

   -  A legacy AAA protocol message (e.g. a RADIUS message) can be
      encapsulated within the protocol message(s) of a lower layer
      protocol, preserving the investment of a Service Provider or User
      Home Organization in their existing AAA infrastructure.

   -  At each service layer, a suite of alternatives can be designed,
      and the service layer above it can choose which alternative makes
      sense for a given application.  However, it should be a primary
      goal of the AAA protocol standardization effort to specify one
      mandatory to implement protocol at the AAA Transaction/Session
      Management (AAA-TSM) service layer (see section 3.4).



de Laat, et al.               Experimental                     [Page 13]

RFC 2903                Generic AAA Architecture             August 2000


3.1.  Elements of a Layered Architecture

   At each layer of a layered architecture, a number of elements need to
   be defined.  These elements are discussed in the following sections.

3.1.1.  Service Layer Abstract Interface Primitives

   The service layer n is assumed to present a program interface through
   which its adjacent service layer n+1 can access its services.  The
   types of abstract program service primitives and associated
   parameters exchanged across the boundary between these service layers
   must be specified.

3.1.2.  Service Layer Peer End Point Name Space

   Each service layer is treated as a set of cooperating processes
   distributed across multiple computing systems.  The service layer
   must manage an end point name space that identifies these peer
   processes.  The conventions by which a service layer assigns a unique
   end point name to each such peer process must be specified.

3.1.3.  Peer Registration, Discovery, and Location Resolution

   Along with defining an end point name space, a service layer must
   also specify how its peers:

   -  announce their presence and availability,

   -  discover one another when they first begin operation, and

   -  detect loss of connectivity or service withdrawal.

   It is also necessary to specify what mechanisms, if any, exist to
   resolve a set of service layer specific search attributes into one or
   more peer end point names that match the search criteria.

3.1.4.  Trust Relationships Between Peer End Points

   Once an end point has established its initial contact with another
   peer, it must decide what authentication policy to adapt.  It can
   trust whatever authentication was done on its behalf by a lower
   service layer or, through a pre-provisioning process, implicitly
   trust the peer, or else go through an authentication process with its
   peer.  The supported mechanisms for establishing a service layer's
   end point trust relationships must be specified.






de Laat, et al.               Experimental                     [Page 14]

RFC 2903                Generic AAA Architecture             August 2000


3.1.5.  Service Layer Finite State Machine

   To the extent that a service layer's internal states are externally
   visible, the layer's behavior in terms of a Finite State Machine
   (FSM) should be specified.  Events that can drive the FSM state
   transitions may include:

   -  service layer n+1 interface primitive requests

   -  protocol data unit arrivals from peer service layer n end points
      received through the layer n-1 access point

   -  service layer n-1 interface primitives (e.g. call backs or
      interrupts)

   -  timer expirations

3.1.6.  Protocol Data Unit Types

   Each service layer defines a lexicon of protocol data units (PDUs)
   that communicate between the layer's peer processes the information
   that controls and/or monitors that service layer's distributed state
   and allows the service processes of that layer to perform their
   functions.  Embedded in the PDUs of each layer are the PDUs of the
   higher layers which depend on its services.  The PDUs of each service
   layer must be specified.

3.2.  AAA Application Specific Service Layer

   AAA applications have almost unlimited diversity, but imposing some
   constraints and commonality is required for them to participate in
   this generic AAA architectural framework.  To satisfy these
   constraints, participating AAA applications would derive their
   application specific program logic from a standardized "Authorization
   Server" abstract base object class.  They would also support an
   "Authorized Session" object class.  An Authorization Session object
   instance represents an approved authorization request that has a
   long-lived allocation of services or resources.  The generic AAA
   architecture could be extended to include other abstract base object
   classes in the future (e.g. Authorization Reservation, Authentication
   Server, etc.).  How to implement the derived Authorization Server
   class's public methods for a given problem domain is entirely up to
   the application.  One technique might be to place a software
   "wrapper" around an existing embedded application specific service to
   adapt it to the standardized Authorization Server object paradigm.
   The major Authorization Server class methods are:





de Laat, et al.               Experimental                     [Page 15]

RFC 2903                Generic AAA Architecture             August 2000


   -  Publish an advertisement that describes the Authorization Server's
      service attributes and its application specific service layer end
      point address.  Once the Authorization Server has registered, peer
      processes can discover its presence or send messages addressed to
      it.

   -  Application Specific Authorization Decision Function (AS-ADF)
      method takes a User's application specific authorization request
      and returns a decision of approve, deny, or conditionally approve
      with referral to another stakeholder.  In the latter case, the
      application may create a reservation for the requested services or
      resources.  This method represents the "condition" side of a
      policy rule's condition/action pair.

   -  Commit a service or set of resources to a previously conditionally
      approved authorization decision.  For those authorization requests
      that have a long-term lifecycle (as opposed to being
      transactions), this method mobilizes a reservation into an
      Authorized Session object instance.  This method represents the
      "action" side of a policy rule's condition/action pair.

   -  Cancel a previously conditionally approved Authorization request.
      This method releases any associated reservations for services or
      resources.

   -  Withdraw the Authorization Server's service advertisement.

   A key motivation for structuring an AAA application as an
   Authorization Server object instance is to separate the generic
   authorization decision logic from the application-specific
   authorization decision logic.  In many cases, the application can be
   divorced from the AAA problem altogether, and its AAA responsibility
   can be assigned to an external rules based generic AAA Server.  (The
   idea is similar to that of a trust management policy server as
   defined in [5].)  This would facilitate a security administrator
   deploying AAA policy in a central repository.  The AAA policy is
   applied consistently across all users of the applications, resources,
   and services controlled by the AAA server.  However, it is recognized
   that for many problem domains, there are unique rules intrinsic to
   the application.  In these cases, the generic AAA Server must refer
   the User's authorization request to the relevant Application Specific
   Module.

3.3.  Presentation Service Layer

   The presentation service layer solves the data representation
   problems that are encountered when communicating peers exchange
   complex data structures or objects between their heterogeneous



de Laat, et al.               Experimental                     [Page 16]

RFC 2903                Generic AAA Architecture             August 2000


   computing systems.  The goal is to transfer semantically equivalent
   application layer data structures regardless of the local machine
   architecture, operating system, compiler, or other potential inter-
   system differences.

   One way to better understand the role of the presentation layer is to
   evaluate an existing example.  The Generic Inter-ORB Protocol (GIOP)
   and its Common Data Representation (CDR) is a presentation service
   layer protocol developed by the Object Management Group (OMG)
   industry consortium.  GIOP is one component within the Common Object
   Request Broker Architecture (CORBA).  Peer Object Request Brokers
   (ORB) executing on heterogeneous systems use GIOP to invoke remote
   CORBA object interface methods.  GIOP encodes an object method's
   input and output parameters in the Common Data Representation (CDR).
   While there are other presentation service layer protocols in the
   industry, GIOP in combination with CDR represents a mature,
   comprehensive solution that exhibits many of the presentation service
   layer requirements that are applicable within the AAA protocol model.

   In the context of Internet access AAA protocols, RADIUS and its
   successors use the Attribute Value Pair (AVP) paradigm as the
   presentation service layer encoding scheme.  While such an approach
   is versatile, it is also prone to becoming splintered into many ad
   hoc and vendor specific dialects.  There is no structure imposed or
   method to negotiate the constraints on which AVPs are combined and
   interpreted for a given conversation in a consistent way across AAA
   protocol implementations or problem domains.  At run-time, it can be
   hard for the communicating peers to negotiate to a common inter-
   operable set of AVPs.

   To avoid this pitfall, a primary presentation service layer
   responsibility is the ability to let peers negotiate from a base
   Authorization Server object class towards a commonly understood
   derived Authorization Server object class that both presentation
   service layer peers have implemented for their application specific
   problem domain.  This negotiation implies a requirement for a
   globally registered and maintained presentation service layer
   hierarchy of Authorization Server object class names.

3.4.  AAA Transaction/Session Management Service Layer

   The AAA Transaction/Session Management (AAA-TSM) service layer is a
   distributed set of AAA Servers, which typically reside in different
   administrative domains.  Collectively they are responsible for the
   following three services:






de Laat, et al.               Experimental                     [Page 17]

RFC 2903                Generic AAA Architecture             August 2000


   Authentication -- Execute the procedure(s) needed to confirm the
      identity of the other parties with which the AAA TSM entity has a
      trust relationship.

   Authorization -- Make an authorization decision to grant or deny a
      User's request for services or resources.  The generic rules based
      policy engine described earlier in this document executes the
      authorization decision function.  When the User's request is
      instantaneous and transient, then its authorization approval is
      treated as an ephemeral transaction.  If the authorization
      approval implies a sustained consumption of a service or
      resources, then the request is transformed into an Authorized
      Session.  For the duration of the Authorized Session's lifetime:

      -  its state may be queried and reported, or

      -  it may be canceled before service is completed, or

      -  the service being delivered may be modified to operate under
         new parameters and conditions, or

      -  the service may complete on its own accord.

      In each of these cases, the AAA-TSM service layer must synchronize
      the Authorized Session's distributed state across all of those AAA
      Servers which are implementing that specific Authorized Session.

   Accounting -- Generate any relevant accounting information regarding
      the authorization decision and the associated Authorized Session
      (if any) that represents the ongoing consumption of those services
      or resources.

   The peer AAA servers and their AAA-TSM end points exchange AAA-TSM
   messages to realize these AAA functions.  A central AAA-TSM concept
   is that there is a set of one or more AAA Server stakeholders who are
   solicited to approve/disapprove a User request for application layer
   services.  The AAA-TSM service layer routes the User's request from
   one stakeholder to the next, accumulating the requisite approvals
   until they have all been asked to make an authorization decision.

   The AAA Servers may also do User authentication (or re-
   authentication) as part of this approval process.  The overall flow
   of the routing from one stakeholder to another may take the form of
   the "push", "pull", or "agent" authorization models developed in [2].
   However, in principle, it is feasible to have an arbitrary routing
   path of an AAA-TSM authorization request among stakeholders. Once the
   final approval is received, the AAA-TSM service layer commits the
   requested service by notifying all of those stakeholders that require



de Laat, et al.               Experimental                     [Page 18]

RFC 2903                Generic AAA Architecture             August 2000


   a confirmation (i.e. turn on a pending reservation and do a
   transaction commit).  Alternatively, any stakeholder among those on
   the consent list can veto the authorization request.  In that case,
   all stakeholders who previously approved the request and had asked
   for a confirmation are told that the request has been denied (i.e.,
   cancel reservation and do a transaction rollback).

   The AAA-TSM authorization request payload must carry its own "Context
   State", such that when an AAA server receives it, there is sufficient
   information that it is essentially self-contained.  Embedding the
   Context State within the AAA-TSM message provides two benefits.
   First, the message can be immediately processed with respect to the
   AAA Server's local policy, and this minimizes or altogether avoids
   the need for the AAA Server to exchange additional AAA-TSM messages
   with its peers to complete its piece of the overall authorization
   decision.  The other benefit is that the AAA Server minimizes the
   amount of state information resources that it commits to a user's
   pending request until it is fully approved.  This helps protect
   against denial of service attacks.

   One can envision many possible message elements that could be part of
   the Context State carried within an AAA-TSM request message:

   -  AAA-TSM session identifier, a unique handle representing this
      authorization request.  All AAA servers who participate in a
      request's approval process and its subsequent monitoring
      throughout its Session lifetime refer to this handle.

   -  permission lists stating which AAA Servers are allowed to modify
      which parts of the message.

   -  User's authorization request, encoded as a presentation layer PDU.

   -  User authentication information, (e.g. an X.509 public key
      certificate).

   -  User credentials information, or else a pointer to where that
      information can be found by an AAA server. An example of such
      credentials would be an X.509 attributes certificate.

   -  the list of AAA Server stakeholders who have yet to be visited to
      gain full approval of the User's authorization request.  Each
      element in that list contains a presentation layer message
      encoding how the user authorization request should be evaluated by
      its application specific Authorization Decision Function (ADF).

   -  the current position in the list of AAA Server stakeholders to be
      visited.



de Laat, et al.               Experimental                     [Page 19]

RFC 2903                Generic AAA Architecture             August 2000


   -  a list of those AAA servers which have already conditionally
      approved the User's authorization request, but which have
      predicated their approval on the request also completing its
      approval from those stakeholders who have not yet seen the
      request.  Each element in the list has a digital signature or
      comparable mechanism by which their approval can be subsequently
      verified.

   -  an expiration time stamp, expressed in a universally understood
      time reference, which sets a lifetime limit on the AAA-TSM
      message's validity.  This offers some replay attack protection,
      and inhibits messages from circulating indefinitely seeking the
      completion of a request's approval.

   -  a message payload modification audit trail, tracing which parties
      introduced changes into the User's authorization request terms and
      conditions.

   -  an AAA-TSM message integrity check, computed across the whole
      message rather than its individual elements, and signed by the
      most recent AAA-TSM layer end point process to modify the AAA-TSM
      message before its transmission to its AAA-TSM peer.  This
      function may be delegated to the underlying Reliable Secure
      Transport layer connection to that destination peer.

3.5.  AAA-TSM Service Layer Program Interface Primitives

   The AAA-TSM service layer and its adjacent presentation service layer
   communicate across their boundary through a set of program interface
   primitives.  A key design goal is to keep these primitives the same
   regardless of the higher level AAA application, analogous to a
   callable "plug-in".  The two service layers are responsible for
   coordinating their state information.  This responsibility includes
   all of the pending Authorization requests and the Authorization
   Sessions that they are both controlling and monitoring.  The initial
   contact between these two layers is through an abstract object that
   is called an AAA-TSM Service Access Point (SAP).  A particular
   service instance between these two layers is realized in an abstract
   object that is called an Authorized Session.  The presentation
   service layer invokes AAA-TSM interface primitives against an AAA-TSM
   SAP.

   The AAA-TSM service layer interface primitives can be broadly
   characterized as follows:

   -  Register a presentation end point address identifier and its
      associated set of attributes to a service access point.




de Laat, et al.               Experimental                     [Page 20]

RFC 2903                Generic AAA Architecture             August 2000


   -  Send a presentation layer message to a specified destination
      presentation layer peer end point address.

   -  Receive a presentation layer message from another presentation
      layer end point address.  A receive operation may select a
      specific originating presentation layer end point address from
      which the message is expected, or receive a message from any
      presentation layer peer.

   -  The AAA-TSM service layer calls an application specific
      authorization decision function, which returns a condition code
      expressing an approval, denial, or partially approves with a
      referral to another AAA Server.

   -  AAA-TSM service layer tells the presentation layer to commit an
      earlier partially approved authorization request.

   -  Cancel an earlier partially approved authorization request (i.e.
      rollback).

   -  The presentation service layer notifies the AAA-TSM service layer
      that it has terminated an in-progress Authorized Session.

   -  AAA-TSM service layer notifies the presentation service layer that
      another presentation service layer peer has terminated an
      Authorized Session.

   -  Un-register a presentation service layer end point address.

3.6.  AAA-TSM Layer End Point Name Space

   The AAA-TSM service layer end point name space is the N-tuple formed
   by concatenating the following components:

   -  AAA Server's Reliable/Secure Transport layer end point address

   -  AAA-TSM authorization request serial number, a unique durable
      unsigned integer generated by the AAA Server who first receives
      the User's authorization request.

   Some AAA applications may require that each assigned AAA-TSM
   transaction serial number be stored in persistent storage, and
   require that it be recoverable across AAA Server system re-boots.
   The serial number generation algorithm must be guaranteed unique even
   if the AAA Server does a re-boot.






de Laat, et al.               Experimental                     [Page 21]

RFC 2903                Generic AAA Architecture             August 2000


3.7.  Protocol Stack Examples

   The layering paradigm makes it possible to use the most appropriate
   syntax for each application for encoding the Application Specific
   Information units of that application.  This encoding would take
   place at the presentation layer.  Similarly the application layer can
   recognize the semantics specific to each application.  Figure 6
   illustrates some possible AAA protocol stacks.

   +------------++------------++-----------++-----------++----------+
   |            || Application|| E-Commerce|| Bandwidth || Roaming &|
   |    AAA     ||  specific  || Internet  ||  Broker   || mobile IP|
   | Application||object class||   Open    ||cross-admin||  remote  |
   |  Service   || interface  ||  Trading  ||  domain   ||  access  |
   |   Layer    ||specified in|| Protocol  ||   COPS    ||   AVP    |
   |            || CORBA IDL  ||  (IOTP)   || extensions|| lexicons |
   +------------++------------++-----------++-----------++----------+
   |            ||   CORBA    ||Extensible ||  Common   || DIAMETER |
   |Presentation||  Generic   ||  Markup   ||   Open    ||    or    |
   |  Service   || Inter-ORB  || Language  ||  Policy   ||  RADIUS  |
   |   Layer    ||  Protocol  ||   (XML)   ||Specificatn||Attribute |
   |            ||   (GIOP)   ||           ||  (COPS)   ||Value/Pair|
   +------------++------------++-----------++-----------++----------+
   |   AAA-TSM Service Layer Application Program Interface (API)    |
   +----------------------------------------------------------------+
   |   AAA Transaction/Session Management (AAA-TSM) Service Layer   |
   +----------------------------------------------------------------+
   |                Reliable Secure Transport Layer                 |
   +----------------------------------------------------------------+

                 Fig. 6 -- Possible AAA Protocol Stacks

4.  Security Considerations

   Security considerations for the framework on which the work described
   in this memo is based are discussed in [2].  Security requirements
   for authorization are listed in section 2.2 of [3].

   This memo identifies a basic set of AAA functions that are general in
   nature and common to many different AAA applications.  We propose
   that a standard set of security mechanisms should be defined as part
   of a base AAA protocol which would include such things as public key
   encryption and digital signatures that could be applied to individual
   information units within an AAA message.  Security with this
   granularity is needed to meet the end-to-end security requirement
   specified in section 2.2.7 of [3] because a single AAA message may





de Laat, et al.               Experimental                     [Page 22]

RFC 2903                Generic AAA Architecture             August 2000


   contain multiple information units each generated by AAA servers from
   different administrative domains and destined to AAA servers in
   different domains.

   In addition, it may be necessary to encrypt or sign an entire AAA
   message on a hop-by-hop basis.  This could be handled by a standard,
   lower layer protocol such as IPSEC.  If so, then certain auditing
   requirements will have to be met so that it can be established later
   that the messages relative to some specific session ID were, in fact,
   protected in a particular way.  Alternatively, hop-by-hop security
   mechanisms may be built into the base AAA protocol itself.

Glossary

   Application Specific Information (ASI) -- information in an AAA
      protocol message that is specific to a particular application.

   Application Specific Module (ASM) -- a software module that
      implements a program interface to a generic AAA server which
      handles application specific functionality for an AAA protocol
      message.

   Service Provider -- an organization which provides a service.

   User -- the entity seeking authorization to use a resource or a
      service.

   User Home Organization (UHO) -- An organization with whom the User
      has a contractual relationship which can authenticate the User and
      may be able to authorize access to resources or services.





















de Laat, et al.               Experimental                     [Page 23]

RFC 2903                Generic AAA Architecture             August 2000


References

   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [2]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
        G., de Bruijn, B., de Laat, D., Holdrege, M. and D. Spence, "AAA
        Authorization Framework", RFC 2904, August 2000.

   [3]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
        G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
        Authorization Application Examples", RFC 2905, August 2000.

   [4]  Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross,
        G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
        Authorization Requirements", RFC 2906, August 2000.

   [5]  Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis, "The
        KeyNote Trust-Management System Version 2", RFC 2704, September
        1999.

Authors' Addresses

   Cees T.A.M. de Laat
   Physics and Astronomy dept.
   Utrecht University
   Pincetonplein 5,
   3584CC Utrecht
   Netherlands

   Phone: +31 30 2534585
   Phone: +31 30 2537555
   EMail: delaat@phys.uu.nl


   George M. Gross
   Lucent Technologies
   184 Liberty Corner Road, m.s. LC2N-D13
   Warren, NJ 07059
   USA

   Phone:  +1 908 580 4589
   Fax:    +1 908-580-4991
   EMail:  gmgross@lucent.com







de Laat, et al.               Experimental                     [Page 24]

RFC 2903                Generic AAA Architecture             August 2000


   Leon Gommans
   Enterasys Networks EMEA
   Kerkplein 24
   2841 XM  Moordrecht
   The Netherlands

   Phone: +31 182 379279
   email: gommans@cabletron.com
          or at University of Utrecht:
          l.h.m.gommans@phys.uu.nl


   John R. Vollbrecht
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA

   Phone: +1 734 821 1205
   Fax:   +1 734 821 1235
   EMail: jrv@interlinknetworks.com


   David W. Spence
   Interlink Networks, Inc.
   775 Technology Drive, Suite 200
   Ann Arbor, MI  48108
   USA

   Phone: +1 734 821 1203
   Fax:   +1 734 821 1235
   EMail: dspence@interlinknetworks.com



















de Laat, et al.               Experimental                     [Page 25]

RFC 2903                Generic AAA Architecture             August 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















de Laat, et al.               Experimental                     [Page 26]