File: rfc2904.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 (1963 lines) | stat: -rw-r--r-- 78,098 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
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963






Network Working Group                                      J. Vollbrecht
Request for Comments: 2904                      Interlink Networks, Inc.
Category: Informational                                       P. Calhoun
                                                  Sun Microsystems, Inc.
                                                              S. Farrell
                                                  Baltimore Technologies
                                                              L. Gommans
                                                 Enterasys Networks EMEA
                                                                G. Gross
                                                     Lucent Technologies
                                                            B. de Bruijn
                                                 Interpay Nederland B.V.
                                                              C. de Laat
                                                      Utrecht University
                                                             M. Holdrege
                                                                 ipVerse
                                                               D. Spence
                                                Interlink Networks, Inc.
                                                             August 2000


                      AAA Authorization Framework

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This memo serves as the base requirements for Authorization of
   Internet Resources and Services (AIRS).  It presents an architectural
   framework for understanding the authorization of Internet resources
   and services and derives requirements for authorization protocols.












Vollbrecht, et al.           Informational                      [Page 1]

RFC 2904              AAA Authorization Framework            August 2000


Table of Contents

   1. Introduction ................................................  2
   2. Authorization Entities and Trust Relationships ..............  4
   3. Message Sequences ...........................................  7
      3.1. Single Domain Case .....................................  7
           3.1.1. The Agent Sequence ..............................  7
           3.1.2. The Pull Sequence ...............................  8
           3.1.3. The Push Sequence ...............................  9
      3.2. Roaming ................................................ 10
      3.3. Distributed Services ................................... 13
      3.4. Combining Roaming and Distributed Services ............. 15
   4. Relationship of Authorization and Policy .................... 16
      4.1. Policy Retrieval ....................................... 16
      4.2. Policy Evaluation ...................................... 17
      4.3. Policy Enforcement ..................................... 17
      4.4. Distributed Policy ..................................... 18
   5. Use of Attribute Certificates ............................... 19
   6. Resource Management ......................................... 22
      6.1. Session Management ..................................... 23
      6.2. The Resource Manager ................................... 24
   7. AAA Message Forwarding and Delivery ......................... 25
   8. End-to-End Security ......................................... 26
   9. Streamlined Authorization Process ........................... 27
   10. Summary of the Authorization Framework ..................... 28
   11. Security Considerations .................................... 28
   Glossary ....................................................... 29
   References ..................................................... 31
   Authors' Addresses ............................................. 32
   Full Copyright Statement ....................................... 35

1.  Introduction

   This document is one of a series of three documents under
   consideration by the AAAarch RG dealing with the authorization
   requirements for AAA protocols.  The three documents are:

         AAA Authorization Framework (this document)
         AAA Authorization Requirements [2]
         AAA Authorization Application Examples [3]

   There is a demonstrated need for a common scheme which covers all
   Internet services which offer Authorization.  This common scheme will
   address various functional architectures which meet the requirements
   of basic services.  We attempt to describe these architectures and
   functions as a basis for deriving requirements for an authorization
   protocol [2].




Vollbrecht, et al.           Informational                      [Page 2]

RFC 2904              AAA Authorization Framework            August 2000


   These architectures include Policy structures, Certificate
   Authorities, Resource Managers, Inter-Domain and Multi-Domain
   schemes, and Distributed Services.  The requirements are for the
   expected use of Authorization services across these architectures.

   A representative set of applications that may use this architecture
   to support their authorization needs is presented in [3].  The
   examples in [3] show how this framework may be used to meet a wide
   variety of different authorization needs.

   We expect that this work may be extended in the future to a more
   comprehensive model and that the scheme described here will be
   incorporated into a framework that includes authentication,
   accounting and auditing.  We have referenced a number of
   authorization sources, but also recognize that there may be some that
   we have missed and that should be included.  Please notify one of the
   authors of any such oversight so it can be corrected in a future
   revision.

   In general, it is assumed that the parties who are participating in
   the authorization process have already gone through an authentication
   phase.  The authentication method used by those parties is outside
   the scope of this document except to the extent that it influences
   the requirements found in a subsequent authorization process.
   Likewise, accounting requirements are outside the scope of this
   document other than recording accounting data or establishing trust
   relationships during an authorization that will facilitate a
   subsequent accounting phase.

   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
   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.

   This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their
   negatives, in the way described in RFC 2119 [4].








Vollbrecht, et al.           Informational                      [Page 3]

RFC 2904              AAA Authorization Framework            August 2000


2.  Authorization Entities and Trust Relationships

   The following framework is being presented in order to provide a
   framework for discussing authorization requirements for a large
   number of applications.  The intent is to provide some common
   vocabulary for the discussion.  Terminology is introduced for basic
   elements in the authorization transaction and for concepts that
   appear to be common to all (or at least many) authorization
   proposals.

   Figure 1, below,  identifies the basic conceptual entities that may
   be participants in an authorization:

   1. A User who wants access to a service or resource.

   2. A User Home Organization (UHO) that has an agreement with the user
      and checks whether the user is allowed to obtain the requested
      service or resource.  This entity may carry information required
      to authorize the User, which might not be known to the Service
      Provider (such as a credit limit).

   3. A Service Provider's AAA Server which authorizes a service based
      on an agreement with the User Home Organization without specific
      knowledge about the individual User.  This agreement may contain
      elements that are not relevant to an individual user (e.g., the
      total agreed bandwidth between the User Home Organization and the
      Service Provider).

   4. A Service Provider's Service Equipment which provides the service
      itself. This might, for example, be a NAS in dial service, or a
      Router in the QoS service, or a print server in the Internet
      Printing service.



















Vollbrecht, et al.           Informational                      [Page 4]

RFC 2904              AAA Authorization Framework            August 2000


               +------+      +-------------------------+
               |      |      | User Home Organization  |
               |      |      |  +-------------------+  |
               |      |      |  |    AAA Server     |  |
               |      |      |  |                   |  |
               |      |      |  +-------------------+  |
               |      |      |                         |
               |      |      +-------------------------+
               |      |
               |      |
               |      |
               | User |      +-------------------------+
               |      |      | Service Provider        |
               |      |      |  +-------------------+  |
               |      |      |  |    AAA Server     |  |
               |      |      |  |                   |  |
               |      |      |  +-------------------+  |
               |      |      |                         |
               |      |      |  +-------------------+  |
               |      |      |  |      Service      |  |
               |      |      |  |     Equipment     |  |
               |      |      |  +-------------------+  |
               |      |      |                         |
               +------+      +-------------------------+

              Fig. 1 -- The Basic Authorization Entities

   These entities will be referenced in the authorization requirements.

   There may be bilateral agreements between pairs of organizations
   involved in an authorization transaction.  Agreements between
   organizations may take the form of formal contracts or Service Level
   Agreements.  Figure 2 uses double lines to show relationships that
   may exist between the User and the User Home Organization and between
   the User Home Organization and the Service Provider.
















Vollbrecht, et al.           Informational                      [Page 5]

RFC 2904              AAA Authorization Framework            August 2000


              +------+      +-------------------------+
              |      |      | User Home Organization  |
              |      |======|  +-------------------+  |
              |      |      |  |    AAA Server     |  |
              |      |      |  |                   |  |
              |      |      |  +-------------------+  |
              |      |      |                         |
              |      |      +-------------------------+
              |      |                  ||
              |      |                  ||
              |      |                  ||
              | User |      +-------------------------+
              |      |      | Service Provider        |
              |      |      |  +-------------------+  |
              |      |      |  |    AAA Server     |  |
              |      |      |  |                   |  |
              |      |      |  +-------------------+  |
              |      |      |                         |
              |      |      |  +-------------------+  |
              |      |      |  |      Service      |  |
              |      |      |  |     Equipment     |  |
              |      |      |  +-------------------+  |
              |      |      |                         |
              +------+      +-------------------------+

                     Fig. 2 -- Service Agreements

   Authorization is based on these bilateral agreements between
   entities. Agreements may be chained, as shown in figure 2.  The User
   has an agreement with the User Home Organization (e.g., the User may
   have access to the service between 9:00 a.m. and 11:00 a.m. daily).
   The User Home Organization has an agreement with the Service Provider
   (e.g., that all requests for access will be granted, except between
   5:00 a.m. and 10:00 a.m. on Sunday).  The fulfillment of the User's
   request depends on both agreements being honored.

   Note that these agreements may be implemented by hand configuration
   or by evaluation of Policy data stored in a Policy database.  The
   point is that there must be a set of known rules in place between
   entities in order for authorization transactions to be executed.

   Trust is necessary to allow each entity to "know" that the policy it
   is authorizing is correct.  This is a business issue as well as a
   protocol issue.  Trust is often established through third party
   authentication servers (such as Kerberos), via a certificate
   authority, by configuring shared secrets or passwords, or by sharing
   a common facility (such as a connecting wire between processors).
   These "static" trust relationships are necessary for authorization



Vollbrecht, et al.           Informational                      [Page 6]

RFC 2904              AAA Authorization Framework            August 2000


   transactions to take place.  Static trust relationships are used in
   an authorization sequence to establish a "dynamic" relationship
   between the User and the Service Equipment.  Several possible
   authorization sequences are possible, each of which use the static
   trust "chain" to have the user first be approved by the User Home
   Organization, and then have the Service Provider accept the request
   based on its trust of the User Home Organization.

3.  Message Sequences

   In general, the User Home Organization and the Service Provider are
   different entities or different "administrative domains".  In the
   simplest case, however, the User Home Organization and the Service
   Provider may be combined as a single entity.  This case will be used
   to describe three authorization sequences possible with the simple
   case.

   In following sections these concepts will be applied to more
   complicated cases involving separate User Home Organization and
   Service Provider entities (as in roaming) and multiple Service
   Providers each with their own AAA Servers and Service Equipment (as
   in distributed services).

3.1.  Single Domain Case

   This case includes the User, the Service Provider's AAA Server, and
   the Service Provider's Service Equipment.  Examples of this case
   include a NAS supported by a standalone RADIUS server, or a QoS
   Router supported by a local bandwidth broker.

   The sequences considered in the following figures are the "agent",
   "pull", and "push" sequences for the single domain case.

3.1.1.  The Agent Sequence

   In the agent sequence (see figure 3), the Service Provider AAA Server
   functions as an agent between the User and the service itself.  The
   AAA Server receives a request from the User and forwards
   authorization and possibly configuration information to the Service
   Equipment.  In this model, the User sends a request to the Service
   Provider's AAA Server (1), which will apply a policy associated with
   the User and the particular service being requested.  The AAA Server
   sends a request to the Service Equipment, and the Service Equipment
   sets up whatever is requested (2).  The Service Equipment then
   responds to the AAA Server acknowledging that it has set up the
   Service for the user (3).  The AAA Server replies to the User telling
   it that the Service is set up (4).




Vollbrecht, et al.           Informational                      [Page 7]

RFC 2904              AAA Authorization Framework            August 2000


   Depending on the nature of the service, further communication may
   take place between the User and the Service Equipment.  For this to
   occur, there needs to be a binding between the User and the
   authorized service.  This requires further study.

                          +-------------------------+
            +------+      | Service Provider        |
            |      |   1  |  +-------------------+  |
            |      |------+->|    AAA Server     |  |
            |      |<-----+--|                   |  |
            |      |   4  |  +-------------------+  |
            | User |      |          |  /|\         |
            |      |      |          |2  |3         |
            |      |      |         \|/  |          |
            |      |      |  +-------------------+  |
            |      |      |  |      Service      |  |
            |      |      |  |     Equipment     |  |
            |      |      |  +-------------------+  |
            +------+      |                         |
                          +-------------------------+

                     Fig. 3 -- Agent Sequence

   Example: A regular user may ask for 1 Mb/s bandwidth (1).  The
   bandwidth broker (AAA Server) tells the router (Service Equipment) to
   set this user into the 1Mb/s "queue" (2).  The router responds that
   it has done so (3), and the bandwidth broker tells the User the
   bandwidth is set up (4).

3.1.2.  The Pull Sequence

   The pull sequence (figure 4) is what is typically used in the Dialin
   application, in the Mobile-IP proposal, and in some QoS proposals.
   The User sends a request to the Service Equipment (1), which forwards
   it to the Service Provider's AAA Server (2), which evaluates the
   request and returns an appropriate response to the Service Equipment
   (3), which sets up the service and tells the User it is ready (4).














Vollbrecht, et al.           Informational                      [Page 8]

RFC 2904              AAA Authorization Framework            August 2000


                          +-------------------------+
            +------+      | Service Provider        |
            |      |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |      |  |                   |  |
            |      |      |  +-------------------+  |
            | User |      |         /|\  |          |
            |      |      |          |2  |3         |
            |      |      |          |  \|/         |
            |      |   1  |  +-------------------+  |
            |      |------+->|      Service      |  |
            |      |<-----+--|     Equipment     |  |
            |      |   4  |  +-------------------+  |
            +------+      |                         |
                          +-------------------------+

                     Fig. 4 -- Pull Sequence

3.1.3.  The Push Sequence

   The push sequence (figure 5) requires that the User get from the
   Service Provider's AAA Server a ticket or certificate verifying that
   it is o.k. for the User to have access to the service (1,2).   The
   User includes the ticket in the request (3) to the Service Equipment.
   The Service Equipment uses the ticket to verify that the request is
   approved by the Service Provider's AAA Server.  The Service Equipment
   then sends an o.k. to the User (4).

   The ticket the user gets from the Service Provider's AAA Server will
   typically have some time limit on it.  It may contain an indication
   of service location, and in some applications, it might be used for
   more than one request.

   In the push sequence the communication between the AAA Server and the
   Service Equipment is relayed through the User rather than directly
   between themselves.















Vollbrecht, et al.           Informational                      [Page 9]

RFC 2904              AAA Authorization Framework            August 2000


                            +-------------------------+
              +------+      | Service Provider        |
              |      |   1  |  +-------------------+  |
              |      |------+->|    AAA Server     |  |
              |      |<-----+--|                   |  |
              |      |   2  |  +-------------------+  |
              | User |      |                         |
              |      |      |                         |
              |      |      |                         |
              |      |   3  |  +-------------------+  |
              |      |------+->|      Service      |  |
              |      |<-----+--|     Equipment     |  |
              |      |   4  |  +-------------------+  |
              +------+      |                         |
                            +-------------------------+

                     Fig. 5 -- Push Sequence

3.2.  Roaming -- the User Home Organization is not the Service Provider

   In many interesting situations, the organization that authorizes and
   authenticates the User is different from the organization providing
   the service.  This situation has been explored in the Roaming
   Operations (roamops) Working Group.  For purposes of this discussion,
   any situation in which the User Home Organization is different from
   the Service Provider is considered to be roaming.

   Examples of roaming include an ISP selling dialin ports to other
   organizations or a Mobile-IP provider allowing access to a user from
   another domain.

   The same agent, pull and push sequences are possible with roaming.
   If the Service Provider's AAA Server and the Service Equipment are
   grouped as a logical entity for purposes of description, then the
   following figures illustrate these cases.
















Vollbrecht, et al.           Informational                     [Page 10]

RFC 2904              AAA Authorization Framework            August 2000


            +------+      +-------------------------+
            |      |   1  | User Home Organization  |
            |      |----->|  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |<-----|  |                   |  |
            |      |   4  |  +-------------------+  |
            |      |      |                         |
            |      |      +-------------------------+
            |      |                 |  /|\
            |      |                 |2  |3
            |      |                \|/  |
            | User |      +-------------------------+
            |      |      | Service Provider        |
            |      |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |      |  |                   |  |
            |      |      |  +-------------------+  |
            |      |      |                         |
            |      |      |  +-------------------+  |
            |      |      |  |      Service      |  |
            |      |      |  |     Equipment     |  |
            |      |      |  +-------------------+  |
            |      |      |                         |
            +------+      +-------------------------+

                 Fig. 6 -- Roaming Agent Sequence

























Vollbrecht, et al.           Informational                     [Page 11]

RFC 2904              AAA Authorization Framework            August 2000


            +------+      +-------------------------+
            |      |      | User Home Organization  |
            |      |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |      |  |                   |  |
            |      |      |  +-------------------+  |
            |      |      |                         |
            |      |      +-------------------------+
            |      |                /|\  |
            |      |                 |2  |3
            |      |                 |  \|/
            |      |      +-------------------------+
            |      |      | Service Provider        |
            | User |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |   1  |  |                   |  |
            |      |----->|  +-------------------+  |
            |      |      |                         |
            |      |<-----|  +-------------------+  |
            |      |   4  |  |      Service      |  |
            |      |      |  |     Equipment     |  |
            |      |      |  +-------------------+  |
            |      |      |                         |
            +------+      +-------------------------+

                 Fig. 7 -- Roaming Pull Sequence

























Vollbrecht, et al.           Informational                     [Page 12]

RFC 2904              AAA Authorization Framework            August 2000


            +------+      +-------------------------+
            |      |   1  | User Home Organization  |
            |      |----->|  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |<-----|  |                   |  |
            |      |   2  |  +-------------------+  |
            |      |      |                         |
            |      |      +-------------------------+
            |      |
            |      |
            |      |
            | User |      +-------------------------+
            |      |      | Service Provider        |
            |      |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |   3  |  |                   |  |
            |      |----->|  +-------------------+  |
            |      |      |                         |
            |      |<-----|  +-------------------+  |
            |      |   4  |  |      Service      |  |
            |      |      |  |     Equipment     |  |
            |      |      |  +-------------------+  |
            |      |      |                         |
            +------+      +-------------------------+

               Fig. 8 -- Roaming Push Sequence

3.3.  Distributed Services

   To provide a complete service to a user, offerings from several
   service providers may need to be combined.  An example would be a
   user who requires a QoS service for a session that crosses multiple
   ISPs.  Any service that is provided by more than one Service Provider
   acting in concert is a distributed service.  Figure 9 illustrates
   distributed services.
















Vollbrecht, et al.           Informational                     [Page 13]

RFC 2904              AAA Authorization Framework            August 2000


                 +-------------------+      +-------------------+
   +------+      | Org1              |      | Org2              |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |  | AAA Server  |  |      |  | AAA Server  |  |
   |      |      |  |             |  |      |  |             |  |
   |      |      |  +-------------+  |      |  +-------------+  |
   | User |======|                   |======|                   |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |  |   Service   |  |      |  |   Service   |  |
   |      |      |  |  Equipment  |  |      |  |  Equipment  |  |
   |      |      |  +-------------+  |      |  +-------------+  |
   +------+      |                   |      |                   |
                 +-------------------+      +-------------------+

                  Fig. 9 -- Distributed Services

   The agreements between entities in figure 9 imply that the request
   from the User will be authenticated and authorized by the first
   organization, then forwarded to the second organization.  Note that
   the sequence between User and Org1 may be different than between Org1
   and Org2.  The first might use a pull sequence, and the second might
   use an agent sequence.  This example is illustrated in figure 10.

                 +-------------------+      +-------------------+
   +------+      | Org1              |      | Org2              |
   |      |      |  +-------------+  |   3  |  +-------------+  |
   |      |      |  | AAA Server  |--+------+->| AAA Server  |  |
   |      |      |  |             |<-+------+--|             |  |
   |      |      |  +-------------+  |   6  |  +-------------+  |
   | User |      |       /|\  |      |      |        |  /|\     |
   |      |      |        |2  |7     |      |        |4  |5     |
   |      |      |        |  \|/     |      |       \|/  |      |
   |      |   1  |  +-------------+  |      |  +-------------+  |
   |      |------+->|   Service   |  |      |  |   Service   |  |
   |      |<-----+--|  Equipment  |  |      |  |  Equipment  |  |
   |      |   8  |  +-------------+  |      |  +-------------+  |
   +------+      |                   |      |                   |
                 +-------------------+      +-------------------+

             Fig. 10 -- A Possible Distributed Sequence

   There are a number of other ways that authorization sequences for
   distributed services can be set up.  For example, it is possible
   that, in order to reduce delay time in setting up a session, Org1
   could send a response to the user before receiving a verification
   that Org2 has authorized the service.  In that case Org1 would need
   to be able to revoke the authorization sent earlier if Org2 does not
   send the authorization in some amount of time.



Vollbrecht, et al.           Informational                     [Page 14]

RFC 2904              AAA Authorization Framework            August 2000


3.4.  Combining Roaming and Distributed Services

   Figure 11 shows a combination of Roaming and Distributed Services.
   Contract and trust relationships may be set up in number of ways,
   depending on a variety of factors, especially the business model.

   +------+      +-------------------+      +-------------------+
   |      |      | User Home Org     |      | SuperOrg          |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |  | AAA Server  |  |      |  | AAA Server  |  |
   |      |      |  |             |  |      |  |             |  |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |                   |      |                   |
   |      |      +-------------------+      +-------------------+
   |      |
   |      |
   |      |      +-------------------+      +-------------------+
   | User |      | Org1              |      | Org2              |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |  | AAA Server  |  |      |  | AAA Server  |  |
   |      |      |  |             |  |      |  |             |  |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |                   |      |                   |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |  |   Service   |  |      |  |   Service   |  |
   |      |      |  |  Equipment  |  |      |  |  Equipment  |  |
   |      |      |  +-------------+  |      |  +-------------+  |
   |      |      |                   |      |                   |
   +------+      +-------------------+      +-------------------+

            Fig. 11 -- Roaming and Distributed Services

   New entities that combine or add capabilities can be created to meet
   business needs.   In figure 11, one such possibility, a SuperOrg
   entity is shown.  The idea is that this entity would provide
   authentication and authorization for organizations that are providing
   services to end-users. It could be considered to be a wholesaler or
   broker.  While not all authorization will require having a broker,
   authorization protocols should allow such entities to be created to
   meet legitimate requirements.

   Having considered the basic players and how they interact, we will
   now consider different ways that authorization data may be stored in
   the network.







Vollbrecht, et al.           Informational                     [Page 15]

RFC 2904              AAA Authorization Framework            August 2000


4.  Relationship of Authorization and Policy

   The Policy Framework (policy) Working Group is seeking to provide a
   framework to represent, manage, and share policies and policy
   information in a vendor-independent, interoperable, scalable manner.
   [5],[6],[7].  This section explores the relationship of policy and
   authorization and sets the stage for defining protocol requirements
   for supporting policy when included as part of multi-domain
   authorization.  The work presented here builds on the policy
   framework, extending it to support policy across multiple domains.

   One view of an authorization is that it is the result of evaluating
   policies of each organization that has an interest in the
   authorization decision.  In this document the assumption is that each
   administration may have policies which may be indexed by user, by
   service, or by other attributes of the request.  The policies of each
   administration are defined independently of other administrations.

   Each independent policy must be 1) retrieved, 2) evaluated, and 3)
   enforced.

4.1.  Policy Retrieval

   Policy definitions are maintained and stored in a policy repository
   [5] by (or on behalf of) the organization that requires them.  The
   Policy Framework WG is working on a way to describe policy [7].
   Other implementations describe policy as a set of ACL lists.  Policy
   definitions must be retrieved in order to be evaluated and enforced.
   Policy Definitions can be indexed by requester, by service attribute,
   or by some other key.  The organization requiring the policy is also
   responsible for determining which policy is to be applied to a
   specific authorization request.

   Policy retrieval is typically done by the administration that defines
   the policy or by an agent acting for that administration.  Thus a
   policy defining the times of day that a particular User is allowed to
   connect to the network is maintained and retrieved by the User
   Organization.  A policy defining a time that ports will be unusable
   because of maintenance is maintained and retrieved by the Service
   Provider.

   Note that some implementation may choose to have the Service Provider
   retrieve a policy from the User Home Organization using a distributed
   directory access protocol.  This may be appropriate in some cases,
   but is not a general solution.  To understand why, suppose the remote
   administration and the home administration communicate via a broker
   which proxies their communications.  In this case the remote and home




Vollbrecht, et al.           Informational                     [Page 16]

RFC 2904              AAA Authorization Framework            August 2000


   administrations have no prior relationship, and therefore the home
   administration directory is unlikely to be open for access by the
   remote administration and vice versa.

4.2.  Policy Evaluation

   Evaluation of policy requires access to information referenced by the
   policy.  Often the information required is not available in the
   administration where the policy is retrieved.  For example, checking
   that a user is allowed to login at the current time can readily be
   done by the User Home Organization because the User Home Organization
   has access to current time.  But authorizing a user requiring a 2Mb/s
   path with less than 4 hops requires information available at a
   Service Provider and not directly available to the UHO, so the UHO
   must either 1) have a way to query a remote administration for the
   needed information or 2) forward the policy to the remote
   administration and have the remote administration do the actual
   evaluation or 3) attempt somehow to "shadow" the authoritative source
   of the information (e.g by having the Service Provider send updates
   to the UHO).

   Applications might support either 1) or 2), and a general
   authorization protocol must allow both.  Case 3) is not considered
   further as shadowing seems too "expensive" to be supported by an AAA
   protocol.

   An example of case 1 is when a Service Provider forwards a request to
   a UHO which includes a query for the clearance code of the User.  The
   Service Provider policy includes reference to the clearance code and
   the information in the reply is used as input to that policy.

   An example of case 2 is when the UHO approves an authorization
   conditional on the Service Provider confirming that there is
   currently a specific resource available for its use.  The UHO
   includes the "policy" along with a conditional authorization to the
   Service Provider.

4.3.  Policy Enforcement

   Policy Enforcement is typically done by the Service Provider on the
   Service Equipment.  The Service Equipment is equivalent to the Policy
   Target described in the Policy Framework [5].  Thus a NAS may enforce
   destination IP address limits via "filters" and a Router may enforce
   QoS restrictions on incoming packets.  The protocol that sends the
   information between the Service Equipment and the Service Provider
   AAA Server may be specific to the Service Equipment, but it seems
   that the requirements are not different in kind from what is required
   between other AAA servers.



Vollbrecht, et al.           Informational                     [Page 17]

RFC 2904              AAA Authorization Framework            August 2000


   In particular, an AAA Server could send a "policy" to the Service
   Equipment stating what the equipment should do under various
   situations.  The Service equipment should either set up to "enforce"
   the policy or reject the request.

   The AAA Server could also send a query to the Service Equipment for
   information it requires to evaluate a policy.

4.4.  Distributed Policy

   A policy is retrieved by a Policy Retrieval Point (PRP) from a Policy
   Repository, evaluated at a Policy Decision Point (PDP) or Policy
   Consumer, and enforced at a Policy Enforcement Point (PEP) or Policy
   Target [5].

   Generally, any of the AAA Servers involved in an authorization
   transaction may retrieve a policy or evaluate a policy, and any of
   the Service Equipment may enforce a policy.  Policy Repositories may
   reside on any of the AAA Servers or be located elsewhere in the
   network.

   Information against which policy conditions are evaluated (such as
   resource status, session state, or time of day) are accessible at
   Policy Information Points (PIPs) and might be accessed using Policy
   Information Blocks (PIBs). An interesting question in any
   authorization application that uses policy is where are the PDPs,
   PRPs, PIPs  and PEPs?

   Figure 12 shows which policy elements may be available at different
   points in the model.  In distributed services, there may be multiple
   Service Providers involved in the authorization transaction, and each
   may act as the policy elements shown below.

   Note that the User (or requester) may also be a PRP (e.g. use policy
   description to specify what service is being requested), a PIP (have
   information needed by other entities to evaluate their policy), and a
   PDP (decide if it will accept a service with specific parameters).














Vollbrecht, et al.           Informational                     [Page 18]

RFC 2904              AAA Authorization Framework            August 2000


            +------+      +------------------------------+
            |      |      | User Home Organization       |
            |      |      |  +-------------------+  PRP  |
            |      |      |  |    AAA Server     |  PIP  |
            |      |      |  |                   |  PDP  |
            |      |      |  +-------------------+       |
            |      |      |                              |
            |      |      +------------------------------+
            |      |
            |      |
            |      |      +------------------------------+
            | User |      | Service Provider             |
            |      |      |  +-------------------+  PRP  |
            | PRP  |      |  |    AAA Server     |  PIP  |
            | PIP  |      |  |                   |  PDP  |
            | PDP  |      |  +-------------------+       |
            |      |      |                              |
            |      |      |  +-------------------+       |
            |      |      |  |      Service      |  PIP  |
            |      |      |  |     Equipment     |  PEP  |
            |      |      |  +-------------------+       |
            |      |      |                              |
            +------+      +------------------------------+

              PRP = Policy Retrieval Point
              PIP = Policy Information Point
              PDP = Policy Decision Point
              PEP = Policy Enforcement Point

       Fig. 12 -- Where Different Policy Elements May be Located

   An AAA protocol must be able to transport both policy definitions and
   the information needed to evaluate policies.  It must also support
   queries for policy information.

5.  Use of Attribute Certificates to Store Authorization Data

   This section outlines another mechanism that could be used for
   securely transporting the attributes on which an authorization
   decision is to be made.   Work on X.509 Attribute Certificates is
   currently being undertaken in the Public Key Infrastructure (PKIX)
   Working Group [8].  This proposal is largely based on that work.

   When considering authorization using certificate-based mechanisms,
   one is often less interested in the identity of the entity than in
   some other attributes, (e.g. roles, account limits etc.), which
   should be used to make an authorization decision.




Vollbrecht, et al.           Informational                     [Page 19]

RFC 2904              AAA Authorization Framework            August 2000


   In many such cases, it is better to separate this information from
   the identity for management, security, interoperability or other
   reasons. However, this authorization information may also need to be
   protected in a fashion similar to a public key certificate.  The name
   used here for such a structure is an Attribute Certificate (AC) which
   is a digitally signed (certified) set of attributes.

   An AC is a structure that is similar to an X.509 public key
   certificate [9] with the main difference being that it contains no
   public key.  The AC typically contains group membership, role,
   clearance and other access control information associated with the AC
   owner.  A syntax for ACs is also defined in the X.509 standard.

   When making an access decision based on an AC, an access decision
   function (in a PEP, PDP or elsewhere) may need to ensure that the
   appropriate AC owner is the entity that has requested access.  The
   linkage between the request and the AC can be achieved if the AC has
   a "pointer" to a Public Key Certificate (PKC) for the requester and
   that the PKC has been used to authenticate the request.  Other forms
   of linkage can be defined which work with other authentication
   schemes.

   As there is often confusion about the difference between public key
   certificates (PKC's) and attribute certificates (ACs), an analogy may
   help. A PKC can be considered to be like a passport: it identifies
   the owner, it tends to be valid for a long period, it is difficult to
   forge, and it has a strong authentication process to establish the
   owner's identity.  An AC is more like an entry visa in that it is
   typically issued by a different authority than the passport issuing
   authority, and it doesn't have as long a validity period as a
   passport.  Acquiring an entry visa typically requires presenting a
   passport that authenticates that owner's identity.  As a consequence,
   acquiring the entry visa becomes a simpler procedure.  The entry visa
   will refer to the passport as a part of how that visa specifies the
   terms under which the passport owner is authorized to enter a
   country.

   In conjunction with authentication services, ACs provide a means to
   transport authorization information securely to applications.
   However, there are a number of possible communication paths that an
   AC may take.

   In some environments, it is suitable for a client to "push" an AC to
   a server.  This means that no new connections between the client and
   server domains are required.  It also means that no search burden is
   imposed on servers, which improves performance.





Vollbrecht, et al.           Informational                     [Page 20]

RFC 2904              AAA Authorization Framework            August 2000


   In other cases, it is more suitable for a client simply to
   authenticate to the server and for the server to request the client's
   AC from an AC issuer or a repository.  A major benefit of the this
   model is that it can be implemented without changes to the client and
   client/server protocol.  It is also more suitable for some inter-
   domain cases where the client's rights should be assigned within the
   server's domain, rather than within the client's "home" domain.

   There are a number of possible exchanges that can occur, and there
   are three entities involved: client, server, and AC issuer.  In
   addition the use of a directory service as a repository for AC
   retrieval may be supported.

   Figure 13 shows an abstract view of the exchanges that may involve
   ACs. Note that the lines in the diagram represent protocols which
   must be defined, not data flows.  The PKIX working group will define
   the required acquisition protocols.  One candidate for the lookup
   protocols is LDAP (once an LDAP schema exists which states where an
   AC is to be found).

      +--------------+                        +---------------+
      |  AAA Server/ |                        |               |
      |  AC Issuer   +----+                   |   Directory   |
      |              |    |                   |               |
      +--+-----------+    | Server            +-------+-------+
         |                | Acquisition               |
         |Client          |                           |Server
         |Acquisition     +----------------------+    |Lookup
         |                                       |    |
      +--+-----------+                        +--+----+-------+
      |              |     AC in application  |   Service     |
      |     User     +------------------------+  Equipment/   |
      |              |        protocol        | AAA Server    |
      +--+-----------+                        +---------------+
         |
         | Client Lookup
      +--+-----------+
      |              |
      |  Directory   |
      |              |
      +--------------+

                       Fig. 13 -- AC Exchanges








Vollbrecht, et al.           Informational                     [Page 21]

RFC 2904              AAA Authorization Framework            August 2000


   Figure 14 shows the data flows which may occur in one particular
   case, that termed "push" above (section 2.1.3).

      +--------------+
      |  AAA Server/ |
      |  AC Issuer   |
      |              |
      +--+-----------+
         |
         |Client
         |Acquisition (1)
         |
      +--+-----------+                        +---------------+
      |              |     AC in application  |   Service     |
      |     User     +------------------------+  Equipment/   |
      |              |        protocol (2)    | AAA Server    |
      +--------------+                        +---------------+

              Fig. 14 -- One example of an AC exchange

   In the diagram, the user first contacts the AC Issuer and then
   incorporates the AC into the application protocol.  The Service
   Equipment must then validate the AC and use it as the basis for the
   access decision (this functionality may be distributed between a PEP
   and PDP).

6.  Resource Management

   Authorization requests may be chained through a set of servers, as
   described in previous sections.  Each of the servers may have a
   contractual relationship with servers on either side of it in the
   chain.  In many of the applications being considered, the
   authorization results in establishing of an ongoing service which we
   call a session.  Each of the servers involved in the authorization
   may also want to keep track of the state of the session, and be able
   to effect changes to the session if required.  To make it simple to
   discuss this capability, we assume that each AAA Server MAY have a
   Resource Manager component.  Resource Managers tracking the same
   session need to be able to initiate changes to the session, and to
   inform other Resource Managers when changes occur.  Communication
   between Resource Managers creates requirements for an authorization
   protocol.

   An example of the use of resource management might be a user which
   sets up a QoS path through two ISPs, and while this path is active,
   one of the ISPs gets a request for more bandwidth from a higher
   priority user.  The ISP may need to take some bandwidth from a the
   lower priority user's previously allocated session and give it to the



Vollbrecht, et al.           Informational                     [Page 22]

RFC 2904              AAA Authorization Framework            August 2000


   new request.  To do this, each of the administrations in the
   authorization path must be informed and agree to the change (this
   could be considered to be "authorizing the new value").

6.1.  Session Management and State Synchronization

   When an AAA Server grants authorization of some resource to an AAA
   requester (either a User or another AAA Server), the server may need
   to maintain session state information.  This is used to make
   decisions about new sessions based on the state of current sessions,
   and to allow monitoring of sessions by all interested AAA Servers.

   Each session is identified by a session identifier, which must be
   unique within each AAA Server.  Communication between AAA Servers
   must include the session identifier.  It is desirable that the
   session identifier is the same across all AAA servers, otherwise each
   server will have to map identifiers from other servers to its own
   identifiers.  A single session identifier significantly simplifies
   auditing and session control functions.

   Maintaining session state across AAA administrative boundaries
   increases the complexity of the problem, especially if each AAA
   Server in the trust chain must keep state as well.  This can be
   viewed as an interdomain database replication problem.  The protocol
   must include tools to help manage replicated state.  Some of the
   problems to be addressed are:

   a) Service Equipment must be able to notify its Resource Manager when
      a session terminates or changes state in some other way.  The
      Resource Manager must inform other Resource Managers which keep
      state for this session.

   b) The Resource Manager will need to set a time limit for each
      session which must be refreshed by having the Resource Manager
      query for authoritative status or by having the authoritative
      source send periodic keep alive messages that are forwarded to all
      Resource Managers in the authorization chain.  Determining the
      appropriate session lifetime may be application specific and
      depends on the acceptable level of risk.  If the service being
      offered is billed based on time, the session lifetime may need to
      be relatively small; if the service is billed on usage, the
      lifetime may be relatively large.

   c) Any Resource Manager in the chain must have the ability to
      terminate a session.  This requires the Resource Manager to have
      knowledge of at least the adjacent AAA Servers in the
      authorization chain.




Vollbrecht, et al.           Informational                     [Page 23]

RFC 2904              AAA Authorization Framework            August 2000


   An example of how resource management can be used is in the PPP
   dialin application.  A home ISP may wish to restrict the number of
   concurrent sessions that a user can have at any given time.  This is
   particularly important when service providers give all-you-can-eat
   Internet access.  The possibility for fraud is quite large, since a
   user could provide his or her username/password to many people,
   causing a loss of revenue.  Resource management would allow the home
   ISP AAA server to identify when a user is active and to reject any
   authorization request for the user until termination indication is
   received from the NAS or until the session expires.

6.2.  The Resource Manager

   This section describes the functions of the Resource Manager in more
   detail.

   The Resource Manager is the component which tracks the state of
   sessions associated with an AAA Server or Service Equipment.  It also
   may allocate resources to a session (e.g. IP addresses) and may track
   use of resources allocated by peer resource managers to a session
   (e.g. bandwidth in a foreign administrative domain).  The resource
   manager also provides interfaces to allow the User to acquire or
   release authorized sessions.

   The Resource Manager maintains all session specific AAA state
   information required by the AAA Server.  That state information may
   include pointers to peer Resource Managers in other administrative
   domains that possess additional AAA state information that refers to
   the same session.  The Resource Manager is the anchor point in the
   AAA Server from which a session can be controlled, monitored, and
   coordinated even if that session is consuming network resources or
   services across multiple Service Provider administrative domains.

   The Resource Manager has several important functions:

   a) It allows a Service Provider operations staff to inspect the
      status of any of the allocated resources and services including
      resources that span foreign Service Provider administrative
      boundaries.  The peer Resource Managers will cooperatively share
      only the state information subset that is required to assist in
      diagnosing cross-domain trouble tickets.  The network operator may
      also modify or altogether cancel one of the User's active
      authorizations.

   b) It is the process contacted by other Resource Managers to inform
      the AAA Server that a specific session has been cancelled.  This
      information is relayed to the other peer Resource Managers that
      also know about that session and hence must cancel it.



Vollbrecht, et al.           Informational                     [Page 24]

RFC 2904              AAA Authorization Framework            August 2000


   c) The Resource Manager conceals the identity and location of its
      private internal AAA components from other administrative domains
      and from the User, while at the same time facilitating cooperation
      between those domains.

   d) The Resource Manager cooperates with "policy servers" or Policy
      Decision Points (PDPs).  The Resource Manager maintains internal
      state information, possibly complex cross-administrative domain
      information, supported by dialogues with its peer Resource
      Managers.  A policy server can use the state information when
      evaluating a particular policy.

   e) The separation of the Resource Manager and the policy server into
      two distinct architectural components allows a single session to
      span multiple administrative domains, where each administrative
      domain has one or more policy server cooperating with its Resource
      Manager.

   AAA resource managers will normally use the same trust relationships
   needed for authorization sequences.  It is possible for independent
   relationships to be established, but that is discouraged.

7.  AAA Message Forwarding and Delivery

   An AAA Server is responsible for securely forwarding AAA messages to
   the correct destination system or process in the AAA infrastructure.
   Two well known examples are forwarding AAA messages for a roaming AAA
   service, and forwarding AAA messages for a distributed AAA service.
   The same principle can also be applied to intra-domain
   communications.  The message forwarding is done in one of two modes.

   The first mode is when an AAA server needs to forward a message to a
   peer AAA server that has a known "logical destination address" that
   must be resolved by an application-specific procedure into its actual
   network address.  Typically the forwarding procedure indexes into a
   database by an application-specific identifier to discover the peer's
   network address.  For example, in the roaming dialin application, the
   application-specific identifier may be an NAI. A bandwidth brokerage
   application would use other search indices unique to its problem
   domain to select the addressed peer AAA server. After the address
   resolution procedure has completed successfully, then the AAA server
   transmits the message to its peer over the connection associated with
   that destination network address.

   The second mode is when the AAA server already has an established
   session representing an authorization.  The session's state contains
   the addressing and context used to direct the message to its
   destination peer AAA server, PDP, PEP, or User.  The message is sent



Vollbrecht, et al.           Informational                     [Page 25]

RFC 2904              AAA Authorization Framework            August 2000


   over the AAA server's connection to that destination peer,
   multiplexed with other session's messages. The message must be
   qualified by a session identifier that is understood by both end
   points.  The AAA message's destination may be either intra-
   administrative domain, or inter-administrative domain.  In the former
   case, the destination process may reside on the same system as the
   AAA server.

   In addition to the above message forwarding processing, the
   underlying message delivery service must meet the following
   requirements:

   -  Unicast capability -- An end system can send a message to any
      other end system with minimal latency of session setup/disconnect
      overhead messages, and no end system overhead of keeping state
      information about every potential peer.

   -  Data integrity and error detection -- This data transport protocol
      assumes an underlying datagram network layer service that includes
      packet discard on error detection, and data integrity protection
      against third party modifications.

   -  Reliable data transport assurance -- When an end system
      successfully receives a message marked receipt requested, it must
      acknowledge that message to the sending system by either
      piggybacking the acknowledgement on an application-specific reply
      message, or else as a standalone acknowledgement message.  The
      sending system maintains a retry timer; when the timer expires,
      the sending system retransmits a copy of its original message. It
      gives up after a configurable number of unsuccessful retries.

   -  Sequenced data delivery -- If multiple messages are sent between a
      pair of end systems, those messages are delivered to the addressed
      application in the same order as they were transmitted.
      Duplicates are silently suppressed.

   -  Responsive to network congestion feedback -- When the network
      enters into congestion, the end systems must detect that
      condition, and they must back off their transmission rate until
      the congestion subsides.  The back off and recovery algorithms
      must avoid oscillations.

8.  End-to-End Security

   When AAA servers communicate through intermediate AAA servers, such
   as brokers, it may be necessary that a part of the payload be secure
   between the originator and the target AAA server.  The security
   requirement may consist of one or more of the following: end-to-end



Vollbrecht, et al.           Informational                     [Page 26]

RFC 2904              AAA Authorization Framework            August 2000


   message integrity, confidentiality, replay protection, and
   nonrepudiation.  Furthermore, it is a requirement that intermediate
   AAA servers be able to append information such as local policy to a
   message before forwarding the message to its intended destination.
   It may also be required that an intermediate AAA Server sign such
   appended information.

   This requirement has been clearly documented in [10], which describes
   many current weaknesses of the RADIUS protocol [11] in roaming
   networks since RADIUS does not provide such functionality.  One
   well-known attack is the ability for the intermediate nodes to modify
   critical accounting information, such as a session time.

   Most popular security protocols (e.g. IPSec, SSL, etc.) do not
   provide the ability to secure a portion of the payload. Therefore, it
   may be necessary for the AAA protocol to implement its own security
   extensions to provide end-to-end security.

9.  Streamlined Authorization Process

   The techniques described above allow for great flexibility in
   distributing the components required for authentication and
   authorization.  However, working groups such as Roamops and MobileIP
   have identified requirements to minimize Internet traversals in order
   to reduce latency.  To support these requirements, data fields
   necessary for both authentication and authorization SHOULD be able to
   be carried in a single message set.  This is especially important
   when there are intermediate servers (such as Brokers) in the AAA
   chain.

   Furthermore, it should be possible for the Brokers to allow end-to-
   end (direct) authentication and authorization.  This can be done as
   follows. The User Home Organization generates a ticket which is
   signed using the UHO's private key.  The ticket is carried in the
   accounting messages. The accounting messages must flow through the
   Broker since the Broker is acting as the settlement agent and
   requires this information.  There are Brokers that will require to be
   in the authentication and authorization path as well since they will
   use this information to detect fraudulent activity, so the above
   should be optional.

   In order for end-to-end authentication and authorization to occur, it
   may be necessary for the Broker to act as a certificate authority.
   All members of the roaming consortium would be able to trust each
   other (to an extent) using the certificates.  A Service Provider's
   AAA server that sends a request to the Broker should be able to
   receive a redirect message which would allow the two peers (Service
   Provider and UHO) to interact directly.  The redirect message from



Vollbrecht, et al.           Informational                     [Page 27]

RFC 2904              AAA Authorization Framework            August 2000


   the Broker should include the UHO's certificate, which eliminates the
   Service Provider from accessing the certificate archive.  The request
   from the Service Provider could include its own certificate, and a
   token from the Broker's redirect message that is timestamped and
   guarantees that the Service Provider is in good standing with the
   Broker.  This eliminates the home domain from accessing the
   Certificate Revocation List (CRL).

10.  Summary of the Authorization Framework

   The above has introduced the basic players in an authorization
   transaction as User, User Home Organization, Service Provider's AAA
   Server, and Service Equipment.  It has discussed relationships
   between entities based on agreements or contracts, and on "trust".
   Examples of authorization sequences have been given.

   Concepts of roaming and distributed services have been briefly
   described.  Combination of roaming and distributed services was also
   considered and the concept of a "wholesaler" or Broker was
   introduced. We have considered the use of policies and attribute
   certificates to store and transmit authorization data.  We discussed
   the problem of managing the resources to which access has been
   authorized including the problem of tracking state information for
   session-oriented services, and we defined the Resource Manager
   component of a AAA Server.  We considered the problem of forwarding
   AAA messages among servers in possibly different administrative
   domains.  We considered the need for end-to-end security of portions
   of the payload of authorization messages that pass through
   intermediate AAA Servers.  Finally we stressed the need for support
   of a streamlined authorization process that minimizes delay for
   latency-sensitive applications.

   The intent is that this will provide support for discussing and
   understanding requirements of specific applications that need
   authorization services.

11.  Security Considerations

   Authorization is itself a security mechanism.  As such, it is
   important that authorization protocols cannot easily be abused to
   circumvent the protection they are intended to ensure.  It is the
   responsibility of protocol designers to design their protocols to be
   resilient against well-known types of attacks.  The following are
   some considerations that may guide protocol designers in the
   development of authorization protocols.






Vollbrecht, et al.           Informational                     [Page 28]

RFC 2904              AAA Authorization Framework            August 2000


   Authorization protocols must not be susceptible to replay attacks.
   If authentication data is carried with the authorization data, for
   example, the authentication protocol used must either be impervious
   to replay or else the confidentiality of the authentication data must
   be protected.

   If proxying is required, the authorization protocol must not be
   susceptible to man-in-the-middle attacks.

   If the push model is used, the confidentiality of the authorization
   data must be ensured so that it may not be hijacked by third parties
   and used to obtain a service fraudulently.

   If the agent model is used, the binding between the authorization and
   the service itself must be protected to prevent service authorized to
   one party from being fraudulently received by another.

   In addition to guarding against circumvention, authorization
   protocols designed according to this framework will have some
   intrinsic security requirements.  These are included among the
   requirements in [2] and summarized briefly below.

   Among the intrinsic security needs is the fact that authorization
   protocols may carry sensitive information.  It is necessary to
   protect such information from disclosure to unauthorized parties
   including (as discussed in section 8) even certain parties involved
   in the authorization decision.

   We have discussed the use of multi-party trust chains involving
   relaying of authorization data through brokers or other parties.  In
   such cases, the integrity of the chain must be maintained.  It may be
   necessary to protect the data exchanged between parties using such
   mechanisms as encryption and digital signatures.

   Finally, because authorization will be necessary to gain access to
   many Internet services, a denial of service attack against an
   authorization server can be just as effective as a denial of service
   attack against the service equipment itself in preventing access to
   Internet services.

Glossary

   Attribute Certificate -- structure containing authorization
      attributes which is digitally signed using public key
      cryptography.






Vollbrecht, et al.           Informational                     [Page 29]

RFC 2904              AAA Authorization Framework            August 2000


   Contract Relationship -- a relation established between two or more
      business entities where terms and conditions determine the
      exchange of goods or services.

   Distributed Service -- a service that is provided by more than one
      Service Provider acting in concert.

   Dynamic Trust Relationship -- a secure relationship which is
      dynamically created between two entities who may never have had
      any prior relationship. This relationship can be created if the
      involved entities have a mutually trusted third party. Example: A
      merchant trusts a cardholder at the time of a payment transaction
      because they both are known by a credit card organization.

   Policy Decision Point (PDP) -- The point where policy decisions are
      made.

   Policy Enforcement Point (PEP) -- The point where the policy
      decisions are actually enforced.

   Resource Manager -- the component of an AAA Server which tracks the
      state of sessions associated with the AAA Server or its associated
      Service Equipment and provides an anchor point from which a
      session can be controlled, monitored, and coordinated.

   Roaming -- An authorization transaction in which the Service Provider
      and the User Home Organization are two different organizations.
      (Note that the dialin application is one for which roaming has
      been actively considered, but this definition encompasses other
      applications as well.)

   Security Association -- a collection of security contexts, between a
      pair of nodes, which may be applied to protocol messages exchanged
      between them. Each context indicates an authentication algorithm
      and mode, a secret (a shared key, or appropriate public/private
      key pair), and a style of replay protection in use. [12]

   Service Equipment -- the equipment which provides a service.

   Service Provider -- an organization which provides a service.

   Static Trust Relationship -- a pre-established secure relationship
      between two entities created by a trusted party.  This
      relationship facilitates the exchange of AAA messages with a
      certain level of security and traceability. Example: A network
      operator (trusted party) who has access to the wiring closet





Vollbrecht, et al.           Informational                     [Page 30]

RFC 2904              AAA Authorization Framework            August 2000


      creates a connection between a user's wall outlet and a particular
      network port.  The user is thereafter trusted -- to a certain
      level -- to be connected to this particular network port.

   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.

References

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

   [2]  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.

   [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]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Stevens, M., "Policy Framework", Work in Progress.

   [6]  Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core
        Information Model -- Version 1 Specification", Work in Progress.

   [7]  Strassner, John, et al, "Policy Framework LDAP Core Schema",
        Work in Progress.

   [8]  Farrell, Stephen and Russell Housley, "An Internet Attribute
        Certificate Profile for Authorization", Work in Progress.

   [9]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
        Public Key Infrastructure -- Certificate and CRL Profile", RFC
        2459, January 1999.

   [10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
        Implementation in Roaming", RFC 2607, June 1999.

   [11] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2138, April
        1997.



Vollbrecht, et al.           Informational                     [Page 31]

RFC 2904              AAA Authorization Framework            August 2000


   [12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
        Policy-based Admission Control", RFC 2753, January 2000.

Authors' Addresses

   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
   Mail: jrv@interlinknetworks.com


   Pat R. Calhoun
   Network and Security Research Center, Sun Labs
   Sun Microsystems, Inc.
   15 Network Circle
   Menlo Park, California, 94025
   USA

   Phone:  +1 650 786 7733
   Fax:    +1 650 786 6445
   EMail:  pcalhoun@eng.sun.com


   Stephen Farrell
   Baltimore Technologies
   61 Fitzwilliam Lane
   Dublin 2
   Ireland

   Phone:  +353 1 647 7406
   Fax:    +353 1 647 7499
   EMail:  stephen.farrell@baltimore.ie












Vollbrecht, et al.           Informational                     [Page 32]

RFC 2904              AAA Authorization Framework            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


   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


   Betty de Bruijn
   Interpay Nederland B.V.
   Eendrachtlaan 315
   3526 LB Utrecht
   The Netherlands

   Phone: +31 30 2835104
   EMail: betty@euronet.nl


   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








Vollbrecht, et al.           Informational                     [Page 33]

RFC 2904              AAA Authorization Framework            August 2000


   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803

   EMail: matt@ipverse.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


































Vollbrecht, et al.           Informational                     [Page 34]

RFC 2904              AAA Authorization Framework            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.



















Vollbrecht, et al.           Informational                     [Page 35]