File: rfc2905.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 (2971 lines) | stat: -rw-r--r-- 118,645 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
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971






Network Working Group                                      J. Vollbrecht
Request for Comments: 2905                      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 Application Examples

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 describes several examples of applications requiring
   authorization.  Each application is described in terms of a
   consistent framework, and specific authorization requirements of each
   application are given.  This material was not contributed by the
   working groups responsible for the applications and should not be
   considered prescriptive for how the applications will meet their
   authorization needs.  Rather the intent is to explore the fundamental
   needs of a variety of different applications with the view of
   compiling a set of requirements that an authorization protocol will
   need to meet in order to be generally useful.






Vollbrecht, et al.           Informational                      [Page 1]

RFC 2905         AAA Authorization Application Examples      August 2000


Table of Contents

   1. Introduction ................................................    3
   2. PPP Dialin with Roaming .....................................    4
      2.1. Descriptive Model ......................................    4
      2.2. Authorization Requirements .............................    6
   3. Mobile-IP ...................................................    6
      3.1. Relationship to the Framework ..........................   10
      3.2. Minimized Internet Traversal ...........................   10
      3.3. Key Distribution .......................................   10
      3.4. Mobile-IP Authorization Requirements ...................   11
   4. Bandwidth Broker ............................................   12
      4.1. Model Description ......................................   13
      4.2. Components of the Two-Tier Model .......................   13
      4.3. Identification of Contractual Relationships ............   13
           4.3.1. Single-Domain Case ..............................   14
           4.3.2. Multi-Domain Case ...............................   15
      4.4. Identification of Trust Relationships ..................   16
      4.5. Communication Models and Trust Relationships ...........   18
      4.6. Bandwidth Broker Communication Models ..................   19
           4.6.1. Concepts ........................................   19
                4.6.1.1. Intra-Domain Authorization ...............   19
                4.6.1.2. Inter-Domain Authorization ...............   19
           4.6.2. Bandwidth Broker Work Phases ....................   20
           4.6.3. Inter-Domain Signaling ..........................   20
                4.6.3.1. Phase 0 ..................................   20
                4.6.3.2. Phase 1 ..................................   20
           4.6.4. Bandwidth Broker Communication Architecture .....   22
           4.6.5. Two-Tier Inter-Domain Model .....................   23
                4.6.5.1. Session Initialization ...................   23
                4.6.5.2. Service Setup ............................   23
                4.6.5.3. Service Cancellation .....................   24
                4.6.5.4. Service Renegotiation ....................   24
                4.6.5.5. RAR and RAA ..............................   24
                4.6.5.6. Session Maintenance ......................   24
                4.6.5.7. Intra-domain Interface Protocol ..........   24
      4.7. Requirements ...........................................   24
   5. Internet Printing ...........................................   25
      5.1. Trust Relationships ....................................   26
      5.2. Use of Attribute Certificates ..........................   27
      5.3. IPP and the Authorization Descriptive Model ............   28
   6. Electronic Commerce .........................................   29
      6.1. Model Description ......................................   30
           6.1.1. Identification of Components ....................   30
           6.1.2. Identification of Contractual Relationships .....   31
           6.1.3. Identification of Trust Relationships ...........   32
                6.1.3.1. Static Trust Relationships ...............   33
                6.1.3.2. Dynamic Trust Relationships ..............   35



Vollbrecht, et al.           Informational                      [Page 2]

RFC 2905         AAA Authorization Application Examples      August 2000


           6.1.4. Communication Model .............................   35
      6.2. Multi Domain Model .....................................   37
      6.3. Requirements ...........................................   38
   7. Computer Based Education and Distance Learning ..............   40
      7.1. Model Description ......................................   40
           7.1.1. Identification of Components ....................   40
           7.1.2. Identification of Contractual Relationships .....   41
           7.1.3. Identification of Trust Relationships ...........   43
           7.1.4. Sequence of Requests ............................   44
      7.2. Requirements ...........................................   46
   8. Security Considerations .....................................   47
   Glossary .......................................................   47
   References .....................................................   48
   Authors' Addresses .............................................   50
   Full Copyright Statement .......................................   53

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 [2]
         AAA Authorization Requirements [3]
         AAA Authorization Application Examples (this document)

   In this memo, we examine several important Internet applications that
   require authorization.  For each application, we present a model
   showing how it might do authorization and then map that model back to
   the framework presented in [2].  We then present the authorization
   requirements of the application as well as we presently understand
   them.  The requirements presented in this memo have been collected
   together, generalized, and presented in [3].

   The intent of this memo is to validate and illustrate the framework
   presented in [2] and to motivate the requirements presented in [3].
   This work is intended to be in alignment with the work of the various
   working groups responsible for the authorization applications
   illustrated.  This memo should not, however, be regarded as
   authoritative for any of the applications illustrated.  Where
   authoritative documents exist or are in development, they are listed
   in the references at the end of this document.









Vollbrecht, et al.           Informational                      [Page 3]

RFC 2905         AAA Authorization Application Examples      August 2000


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

2.  PPP Dialin with Roaming

   In this section, we present an authorization model for dialin network
   access in terms of the framework presented in [2].  Included in the
   model are the multi-domain considerations required for roaming [5].
   Detailed requirements for network access protocols are presented in
   [6].

2.1.  Descriptive Model

   The PPP dialin application uses the pull sequence as discussed in
   [2].  The roaming case uses the roaming pull sequence, also discussed
   in [2].  This sequence is redrawn using dialin roaming terminology in
   figure 1, below.






















Vollbrecht, et al.           Informational                      [Page 4]

RFC 2905         AAA Authorization Application Examples      August 2000


            +------+      +-------------------------+
            |      |      | Home ISP                |
            |      |      | (User Home Organization)|
            |      |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |      |  |                   |  |
            |      |      |  +-------------------+  |
            |      |      |             /|\  |      |
            |      |      +--------------+---+------+
            |      |                     |   |
            |      |                     |3  |4
            |      |                     |   |
            |      |      +--------------+---+------+
            |      |      | Visited ISP  |   |      |
            |      |      |              |  \|/     |
            | User |      |  +-------------------+  |
            |      |      |  |    AAA Server     |  |
            |      |      |  |                   |  |
            |      |      |  +-------------------+  |
            |      |      |             /|\  |      |
            |      |      |              |2  |5     |
            |      |      |              |  \|/     |
            |      |   1  |  +-------------------+  |
            |      |------+->| NAS (Service      |  |
            |      |<-----+--|      Equipment)   |  |
            |      |   6  |  +-------------------+  |
            |      |      |  (Service Provider)     |
            +------+  PPP +-------------------------+

            Fig. 1 -- Dialin Authorization
                      Based on Roaming Pull Sequence

   In this model, the User dials in to a Network Access Server (NAS)
   provided by the visited (or foreign) ISP (the Service Provider in the
   general model). The User is authenticated using a protocol such as
   PAP, CHAP, or EAP which is encapsulated in PPP frames (1).  Because
   the User has not yet gained access to the network, he or she cannot
   send IP datagrams to a AAA server. At this point, the User can only
   communicate with the NAS (Service Equipment).  The NAS forwards the
   User's authentication/ authorization request including the Network
   Access Identifier (NAI) [7] to a AAA server in its own domain via
   RADIUS [8] or a successor AAA protocol (2).  The visited ISP's AAA
   server examines the realm from the NAI and forwards the request to
   the User's home domain AAA server (3).  The home domain AAA server
   authenticates the user and authorizes access according to a roaming
   agreement.  The home domain AAA server may return service parameters





Vollbrecht, et al.           Informational                      [Page 5]

RFC 2905         AAA Authorization Application Examples      August 2000


   (e.g. Idle-Timeout) to the visited ISP's AAA server (4) which
   forwards them to the NAS, possibly adding additional service
   parameters (5).  The NAS completes PPP session initialization (6).

   In the future, this model may be expanded in several ways [9].  For
   instance, Authentication and Authorization may be done in separate
   passes using different servers in order to support specialized forms
   of authentication.  Or to better support roaming, a broker may be
   inserted between the visited ISP and the home ISP.  Or authorization
   may be supported based on other identifiers such as the caller ID and
   called ID obtained from the PSTN (e.g., using ANI and DNIS).

2.2.  Authorization Requirements

   The following requirements are identified in [9] for authorizing PPP
   dialin service using roaming.

   -  Authorization separate from authentication should be allowed when
      necessary, but the AAA protocol MUST allow for a single message to
      request both authentication and authorization.

   -  The AAA protocol MUST be "proxyable", meaning that a AAA Server or
      PDP MUST be able to forward the request to another AAA Server or
      PDP, which may or may not be within the same administrative
      domain.

   -  The AAA protocol MUST allow for intermediate brokers to add their
      own local Authorization information to a request or response.

   -  When a broker is involved, the protocol MUST provide end to end
      security.

   -  The broker MUST be able to return a forwarding address to a
      requester, allowing two nodes to communicate together.

   -  The protocol MUST provide the following features (per user
      session):

      1. One Authentication, One Authorization
      2. One Authentication, Multiple Authorization
      3. Multiple Authentication, Multiple Authorization

3.  Mobile-IP

   The Mobile-IP protocol is used to manage mobility of an IP host
   across IP subnets [10].  Recent activity within the Mobile-IP Working
   Group has defined the interaction between Mobile-IP and AAA in order
   to provide:



Vollbrecht, et al.           Informational                      [Page 6]

RFC 2905         AAA Authorization Application Examples      August 2000


      -  Better scaling of security associations
      -  Mobility across administrative domain boundaries
      -  Dynamic assignment of Home Agent

   The Mobile IP protocol, as defined in [10], works well when all
   mobile nodes belong to the same administrative domain.  Some of the
   current work within the Mobile IP Working Group is to allow Mobile IP
   to scale across administrative domains.  This changes the trust model
   that is currently defined in [10].

   The requirements for Mobile-IP authorization are documented in [11].
   In this section, we develop a multi-domain model for Mobile-IP
   authorization and present it in the terms of the framework presented
   in [2].

   Figure 2 depicts the new AAA trust model for Mobile-IP.  In this
   model each network contains mobile nodes (MN) and a AAA server (AAA).
   Each mobility device shares a security association (SA) with the AAA
   server within its own home network.  This means that none of the
   mobility devices initially share a security association.  Both
   administrative domains' AAA servers can either share a security
   association, or can have a security association with an intermediate
   broker.

                             Broker AAA
                             +--------+
                             |        |
                             |  AAA   |
                       /=====|        |=====\
                      //     +--------+     \\
            Foreign  // SA                SA \\   Home
              AAA   //                        \\  AAA
             +--------+                      +--------+
             |        |          SA          |        |
             |  AAA   |======================|  AAA   |
             |        | (in lieu of broker)  |        |
             +--------+                      +--------+
                 ||                           ||    ||
              SA ||                        SA ||    || SA
                 ||                           ||    ||
                 ||                           ||    ||
             +---------+              +---------+  +---------+
             |         |              |         |  |         |
             |   FA    |              |   HA    |  |   MN    |
             |         |              |         |  |         |
             +---------+              +---------+  +---------+

                    Fig. 2 -- Mobile-IP AAA Trust Model



Vollbrecht, et al.           Informational                      [Page 7]

RFC 2905         AAA Authorization Application Examples      August 2000


   Figure 3 provides an example of a Mobile-IP network that includes
   AAA. In the integrated Mobile-IP/AAA Network, it is assumed that each
   mobility agent shares a security association between itself and its
   local AAA server.  Further, the Home and Foreign AAA servers both
   share a security association with the broker's AAA server.  Lastly,
   it is assumed that each mobile node shares a trust relationship with
   its home AAA Server.

           Visited Access      Broker          Home IP
           Provider Network    Network         Network
             +--------+      +--------+      +--------+
             |        |      |        |      |        |
             |  AAA   |------|  AAA   |------|  AAA   |
             |        |      |        |      |        |
             +--------+      +--------+      +--------+
                  |                              |
                  |                              |
              AAA |                              | AAA
                  |                              |
                  |                              |
             +---------+                    +---------+
             |         |                    |         |
             |   FA    |                    |   HA    |
             |         |                    |         |
             +---------+                    +---------+
                  |
                  |   Visited Access     Home Network
                  |  Provider Network       -Private Network
           Mobile |                         -Home Provider
             IP   |                         -Home ISP
                  |
             +--------+
             | Mobile |
             | Node   |
             +--------+

    Fig. 3 -- General Wireless IP Architecture for Mobile-IP AAA

   In this example, a Mobile Node appears within a foreign network and
   issues a registration to the Foreign Agent.  Since the Foreign Agent
   does not share any security association with the Home Agent, it sends
   a AAA request to its local AAA server, which includes the
   authentication information and the Mobile-IP registration request.
   The Mobile Node cannot communicate directly with the home AAA Server
   for two reasons:






Vollbrecht, et al.           Informational                      [Page 8]

RFC 2905         AAA Authorization Application Examples      August 2000


      -  It does not have access to the network.  The registration
         request is sent by the Mobile Node to request access to the
         network.
      -  The Mobile Node may not have an IP address, and may be
         requesting that one be assigned to it by its home provider.

   The Foreign AAA Server will determine whether the request can be
   satisfied locally through the use of the Network Access Identifier
   [7] provided by the Mobile Node.  The NAI has the format of
   user@realm and the AAA Server uses the realm portion of the NAI to
   identify the Mobile Node's home AAA Server. If the Foreign AAA Server
   does not share any security association with the Mobile Node's home
   AAA Server, it may forward the request to its broker.  If the broker
   has a relationship with the home network, it can forward the request,
   otherwise a failed response is sent back to the Foreign AAA Server.

   When the home AAA Server receives the AAA Request, it authenticates
   the user and begins the authorization phase.  The authorization phase
   includes the generation of:

      -  Dynamic Session Keys to be distributed among all Mobility
         Agents
      -  Optional Dynamic assignment of a Home Agent
      -  Optional Dynamic assignment of a Home Address (note this could
         be done by the Home Agent).
      -  Optional Assignment of QOS parameters for the Mobile Node [12]

   Once authorization is complete, the home AAA Server issues an
   unsolicited AAA request to the Home Agent, which includes the
   information in the original AAA request as well as the authorization
   information generated by the home AAA server.  The Home Agent
   retrieves the Registration Request from the AAA request and processes
   it, then generates a Registration Reply that is sent back to the home
   AAA server in a AAA response.  The message is forwarded through the
   broker back to the Foreign AAA server, and finally to the Foreign
   Agent.

   The AAA servers maintain session state information based on the
   authorization information.  If a Mobile Node moves to another Foreign
   Agent within the foreign domain, a request to the foreign AAA server
   can immediately be done in order to immediately return the keys that
   were issued to the previous Foreign Agent.  This minimizes an
   additional round trip through the internet when micro mobility is
   involved, and enables smooth hand-off.







Vollbrecht, et al.           Informational                      [Page 9]

RFC 2905         AAA Authorization Application Examples      August 2000


3.1.  Relationship to the Framework

   Mobile-IP uses the roaming pull model described in [2].  The Mobile
   Node is the User.  The Foreign Network is the Service Provider with
   the Foreign Agent as the Service Equipment.  The Home Network is the
   User Home Organization.  Note that the User Home Organization
   operates not only a AAA Server, but also the Home Agent.  Note, also,
   that a broker has been inserted between the Service Provider and the
   User Home Organization.

3.2.  Minimized Internet Traversal

   Although it would have been possible for the AAA interactions to be
   performed for basic authentication and authorization, and the
   Registration flow to be sent directly to the Home Agent from the
   Foreign Agent, one of the key Mobile-IP AAA requirements is to
   minimize Internet Traversals. Including the Registration Request and
   Replies in the AAA messages allows for a single traversal to
   authenticate the user, perform authorization and process the
   Registration Request.  This streamlined approach is required in order
   to minimize the latency involved in getting wireless (cellular)
   devices access to the network.  New registrations should not increase
   the connect time more than what the current cellular networks
   provide.

3.3.  Key Distribution

   In order to allow the scaling of wireless data access across
   administrative domains, it is necessary to minimize the security
   associations required. This means that each Foreign Agent does not
   share a security association with each Home Agent on the Internet.
   The Mobility Agents share a security association with their local AAA
   server, which in turn shares a security association with other AAA
   servers.  Again, the use of brokers, as defined by the Roaming
   Operations (roamops) Working Group, allows such services to scale by
   allowing the number of relationships established by the providers to
   be reduced.

   After a Mobile Node is authenticated, the authorization phase
   includes the generation of Sessions Keys.  Specifically, three keys
   are generated:

      -  k1 - Key to be shared between the Mobile Node and the Home
         Agent
      -  k2 - Key to be shared between the Mobile Node and the Foreign
         Agent
      -  k3 - Key to be shared between the Foreign Agent and the Home
         Agent



Vollbrecht, et al.           Informational                     [Page 10]

RFC 2905         AAA Authorization Application Examples      August 2000


   Each Key is propagated to each mobility device through the AAA
   protocol (for the Foreign and Home Agent) and via Mobile-IP for the
   Mobile Node (since the Mobile Node does not interface directly with
   the AAA servers).

   Figure 4 depicts the new security associations used for Mobile-IP
   message integrity using the keys derived by the AAA server.

             +--------+                      +--------+
             |        |          k3          |        |
             |   FA   |======================|   HA   |
             |        |                      |        |
             +--------+                      +--------+
                   \\                          //
                    \\ k2                  k1 //
                     \\      +--------+      //
                      \\     |        |     //
                       \=====|   MN   |=====/
                             |        |
                             +--------+

       Fig. 4 -- Security Association after Key Distribution

   Once the session keys have been established and propagated, the
   mobility devices can exchange registration information directly
   without the need of the AAA infrastructure.  However the session keys
   have a lifetime, after which the AAA infrastructure must be used in
   order to acquire new session keys.

3.4.  Mobile-IP Authorization Requirements

   To summarize, Mobile-IP has the following authorization requirements:

   1. Mobile-IP requires an AAA protocol that makes use of the pull
      model.

   2. Mobile-IP requires broker support, and data objects must contain
      data integrity and confidentiality end-to-end.  This means that
      neither the broker nor any other intermediate AAA node should be
      able to decrypt the data objects, but they must be able to verify
      the objects' validity.

   3. Authorization includes Resource Management.  This allows the AAA
      servers to maintain a snapshot of a mobile node's current
      location, keying information, etc.






Vollbrecht, et al.           Informational                     [Page 11]

RFC 2905         AAA Authorization Application Examples      August 2000


   4. Due to the nature of the service being offered, it is imperative
      that the AAA transaction add minimal latency to the connect time.
      Ideally, the AAA protocol should allow for a single round trip for
      authentication and authorization.

   5. If the AAA protocol allows for the Mobile-IP registration messages
      to be embedded within the authentication/authorization request,
      this will further reduce the number of round trips required and
      hence reduce the connect time.

   6. It must be possible to pass Mobile-IP specific key management data
      along with the authorization data.  This allows the AAA server to
      act as a Key Distribution Center (KDC).

   7. It must be possible to pass other application-specific data units
      such as home agent selection and home address assignment to be
      carried along with the authorization data units.

   8. The authorization response should allow for diffserv (QOS)
      profiles, which can be used by the mobility agents to provide some
      quality of service to the mobile node.

   9. The AAA protocol must allow for unsolicited messages to be sent to
      a "client", such as the AAA client running on the Home Agent.

4.  Bandwidth Broker

   This section describes authorization aspects derived from the
   Bandwidth Broker architecture as discussed within the Internet2 Qbone
   BB Advisory Council.  We use authorization model concepts to identify
   contract relationships and trust relationships, and we present
   possible message exchanges.  We will derive a set of authorization
   requirements for Bandwidth Brokers from our architectural model.  The
   Internet 2 Qbone BB Advisory Council researches a single and multi-
   domain implementation based on 2-tier authorization concepts.  A 3-
   tier model is considered as a future work item and therefore not part
   of this description. Information concerning the Internet 2 Bandwidth
   Broker work and its concepts can be found at:

      http://www.merit.edu/working.groups/i2-qbone-bb

   The material in this section is based on [13] which is a work in
   progress of the Internet2 Qbone BB Advisory Council.








Vollbrecht, et al.           Informational                     [Page 12]

RFC 2905         AAA Authorization Application Examples      August 2000


4.1.  Model Description

   The establishment of a model involves four steps:

   1. identification of the components that are involved and what they
      are called in this specific environment,
   2. identification of the relationships between the involved parties
      that are based on some form of agreement,
   3. identification of the relationships that are based on trust, and
   4. consideration of the sequence of messages exchanged between
      components.

4.2.  Components of the Two-Tier Model for Bandwidth Brokerage

   We will consider the components of a bandwidth broker transaction in
   the context of the conceptual entities defined in [2].  The bandwidth
   broker two-tier model recognizes a User and the Service Provider
   controlling the Service Equipment.

   The components are as follows:

   -  The Service User (User) -- A person or process willing to use
      certain level of QoS by requesting the allocation of a
      quantifiable amount of resource between a selected destination and
      itself.  In bandwidth broker terms, the User is called a Service
      User, capable of generating a Resource Allocation Request (RAR).

   -  The Bandwidth Broker (Service Provider) -- a function that
      authorizes allocation of a specified amount of bandwidth resource
      between an identified source and destination based on a set of
      policies.  In this context we refer to this function as the
      Bandwidth Broker.  A Bandwidth Broker is capable of managing the
      resource availability within a network domain it controls.

   Note: a 3-tier model involving a User Home Organization is recognized
   in [13], however its development is left for future study and
   therefore it is not discussed in this document.

4.3.  Identification of Contractual Relationships

   Authorizations to obtain bandwidth are based on contractual
   relationships. In both the single and multi-domain cases, the current
   Bandwidth Broker model assumes that a User always has a contractual
   relationship with the service domain to which it is connected.







Vollbrecht, et al.           Informational                     [Page 13]

RFC 2905         AAA Authorization Application Examples      August 2000


4.3.1.  Single-Domain Case

   In the single-domain case, the User has a contract with a single
   Service Provider in a single service domain.

                                    +-------------+
                                    |             |
                                    | +---------+ |
                                    | |Bandwidth| |
                  +-------+         | |Broker   | |
                  |       |         | |         | |
                  |Service|         | +---------+ |
                  |User   |=========|             |
                  |       |         | +---------+ |
                  |       |         | | Network | |
                  +-------+         | | Routing | |
                                    | | Devices | |
                                    | +---------+ |
                                    | Autonomous  |
                                    | Service     |
                                    | Domain      |
                                    +-------------+
                  ==== contractual
                       relationship

     Fig. 5 -- Two-Tier Single Domain Contractual Relationships

























Vollbrecht, et al.           Informational                     [Page 14]

RFC 2905         AAA Authorization Application Examples      August 2000


4.3.2.  Multi-Domain Case

   In the multi-domain case, the User has a contract with a single
   Service Provider.  This Service Provider has a contract with
   neighboring Service Providers.  This model is used when independent
   autonomous networks establish contracts with each other.

                        +-------------+        +-------------+
                        |             |        |             |
                        | +---------+ |        | +---------+ |
                        | |Bandwidth| |        | |Bandwidth| |
      +-------+         | |Broker   | |        | |Broker   | |
      |       |         | |         | |        | |         | |
      |Service|         | +---------+ |        | +---------+ |
      |User   |=========|             |========|             |
      |       |         | +---------+ |        | +---------+ |
      |       |         | | Network | |        | | Network | |
      +-------+         | | Routing | |        | | Routing | |
                        | | Devices | |        | | Devices | |
                        | +---------+ |        | +---------+ |
                        | Autonomous  |        | Autonomous  |
                        | Service     |        | Service     |
                        | Domain A    |        | Domain B    |
                        +-------------+        +-------------+

      ==== contractual
           relationship

     Fig. 6 -- Two-Tier Multi-Domain Contractual Relationships






















Vollbrecht, et al.           Informational                     [Page 15]

RFC 2905         AAA Authorization Application Examples      August 2000


4.4.  Identification of Trust Relationships

   Contractual relationships may be independent of how trust, which is
   necessary to facilitate authenticated and possibly secure
   communication, is implemented.  There are several alternatives in the
   Bandwidth Broker environment to create trusted relationships.
   Figures 7 and 8 show two alternatives that are options in the two-
   tier Bandwidth Broker model.

                        +-------------+        +-------------+
                        |             |        |             |
                        | +---------+ |        | +---------+ |
                        | |Bandwidth| |        | |Bandwidth| |
      +-------+         | |Broker   | |        | |Broker   | |
      |       O***********O         O************O         | |
      |Service|         | +----O----+ |        | +----O----+ |
      |User   |=========|      *      |========|      *      |
      |       |         | +----0----+ |        | +----O----+ |
      |       |         | |Network  | |        | |Network  | |
      +-------+         | |Routing  | |        | |Routing  | |
                        | |Devices  | |        | |Devices  | |
                        | +---------+ |        | +---------+ |
                        | Autonomous  |        | Autonomous  |
                        | Service     |        | Service     |
                        | Domain A    |        | Domain B    |
                        +-------------+        +-------------+

      ==== contractual relationship
      O**O trust relationship

     Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1




















Vollbrecht, et al.           Informational                     [Page 16]

RFC 2905         AAA Authorization Application Examples      August 2000


                        +-------------+        +-------------+
                        |             |        |             |
                        | +---------+ |        | +---------+ |
                        | |Bandwidth| |        | |Bandwidth| |
      +-------+         | |Broker   | |        | |Broker   | |
      |       |         | |         | |        | |         | |
      |Service|         | +----O----+ |        | +----O----+ |
      |User   |=========|      *      |========|      *      |
      |       |         | +----O----+ |        | +----O----+ |
      |       O***********O Network O************O Network | |
      +-------+         | | Routing | |        | | Routing | |
                        | | Devices | |        | | Devices | |
                        | +---------+ |        | +---------+ |
                        | Autonomous  |        | Autonomous  |
                        | Service     |        | Service     |
                        | Domain A    |        | Domain B    |
                        +-------------+        +-------------+

      ==== contractual relationship
      O**O trust relationship

     Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2

   Although [13] does not recommend specifics regarding this question,
   the document recognizes the need for trust relationships.  In the
   first model, a trust relationship, based on some form of
   authentication method, is created between the User and the Bandwidth
   Broker and among Bandwidth Brokers.  In the second model, which
   enjoys some popularity in enterprise networks, the trust relationship
   may be established via the wiring closet and the knowledge of which
   physical router port or MAC address is connected to which user.  The
   router-Bandwidth Broker relationship may be established physically or
   by some other authentication method or secure channel.

   A Certificate Authority (CA) based trust relationship is shown in
   figure 9.  In this figure, a CA signs public key certificates, which
   then can be used in encrypted message exchanges using public keys
   that are trusted by all involved.  As a first step, each involved
   party must register with the CA so it can join a trust domain.  The
   Router-Bandwidth Broker relationship may be established as described
   in the two previous figures.  An interesting observation regarding
   this kind of model is that the bandwidth broker in domain B may route
   information to the user via the bandwidth broker in domain A without
   BB1 being able to read the information (using end-to-end security).
   This model creates a meshed trust relationship via a tree like CA
   structure.





Vollbrecht, et al.           Informational                     [Page 17]

RFC 2905         AAA Authorization Application Examples      August 2000


                               +-------------------+
                               |  Certificate      |
           ....................|  Authority        |
          :                  ..|                   |..
          :                 :  +-------------------+  :
          :                 :                         :
          :                 :                         :
          :  ***************:***********************  :
          :  *          +---:---------+        +---*--:------+
          :  *          |   :         |        |   *  :      |
          :  *          | +-:-------+ |        | +-O--:----+ |
          :  *          | |{C}      | |        | |   {C}   | |
      +---:--O+         | |Bandwidth| |        | |Bandwidth| |
      |  {C}  O***********O Broker  O************O Broker  | |
      |Service|         | +----O----+ |        | +----O----+ |
      |User   |=========|      *      |========|      *      |
      |       |         | +----0----+ |        | +----O----+ |
      |       |         | |Network  | |        | |Network  | |
      +-------+         | |Routing  | |        | |Routing  | |
                        | |Devices  | |        | |Devices  | |
                        | +---------+ |        | +---------+ |
                        | Autonomous  |        | Autonomous  |
                        | Service     |        | Service     |
                        | Domain A    |        | Domain B    |
                        +-------------+        +-------------+

      ==== contractual relationship
      O**O trust relationship
      {C}. certification process

     Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3

4.5.  Communication Models and Trust Relationships

   When describing the Bandwidth Broker communication model, it is
   important to recognize that trust relationships between components
   must ensure secure and authenticated communication between the
   involved components.  As the Internet 2 Qbone Bandwidth Broker work
   does not recommend any particular trust relationship model, we make
   the same assumptions as [13].  In theory, the trust model and
   communication model can be independent, however communication
   efficiency will determine the most logical approach.









Vollbrecht, et al.           Informational                     [Page 18]

RFC 2905         AAA Authorization Application Examples      August 2000


4.6.  Bandwidth Broker Communication Models

4.6.1.  Concepts

   The current Internet 2 Qbone Bandwidth Broker discussion describes a
   two-tier model, where a Bandwidth Broker accepts Resource Allocation
   Requests (RAR's) from users belonging to its domain or RAR's
   generated by upstream Bandwidth Brokers from adjacent domains.  Each
   Bandwidth Broker will manage one service domain and subsequently
   provide authorization based on a policy that decides whether a
   request can be honored.

4.6.1.1.  Intra-Domain Authorization

   Admission Authorization or Connection Admission Control (CAC) for
   intra-domain communication is performed using whatever method is
   appropriate for determining availability of resources within the
   domain. Generally a Bandwidth Broker configures its service domain to
   certain levels of service.  RAR's are subsequently accommodated using
   a policy-based decision.

4.6.1.2.  Inter-Domain Authorization

   Service Level Specifications (SLS's) provide the basis for handling
   inter-domain bandwidth authorization requests.  A Bandwidth Broker
   monitors both the state of its network components and the state of
   its connections to neighboring networks.  SLS's are translations of
   SLA's established between Autonomous Service Domains.  Each Bandwidth
   Broker will initialize itself so it is aware of existing SLS's.
   SLS's are established in a unidirectional sense.  Two SLS's must
   govern a bi-directional connection.  SLS's are established on the
   level of aggregate data-flows and the resources (bandwidth)
   provisioned for these flows.

   A Bandwidth Broker may honor an inter-domain RAR by applying policy
   decisions determining that a particular RAR does fit into a pre-
   established SLS.  If successful, the Bandwidth Broker will authorize
   the usage of the bandwidth.  If unsuccessful, the Bandwidth Broker
   may deny the request or approve the request after it has re-
   negotiated the SLS with its downstream Bandwidth Broker.

   A separate Policy Manager may be involved in the CAC decision.  The
   Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal
   environment where Bandwidth Brokers and Policy Managers work together
   to provide CAC using integrated policy services [13].






Vollbrecht, et al.           Informational                     [Page 19]

RFC 2905         AAA Authorization Application Examples      August 2000


4.6.2.  Bandwidth Broker Work Phases

   The Internet 2 Qbone Bandwidth Broker discussion proposes development
   of the Bandwidth Broker model in several phases:

   -  Phase 0: Local Admission.  RAR's are only handled within a local
      domain. SLS's are pre-established using manual methods (fax, e-
      mail).

   -  Phase 1: Informed Admission.  RAR's spanning multiple domains are
      authorized based on information obtained from one or more
      Bandwidth Brokers along the path.

   -  Phase 2: Dynamic SLS admission.  Bandwidth Brokers can dynamically
      set up new SLS's.

   Although the local admission case is addressed, the current Internet
   2 Qbone Bandwidth Broker work is currently concerned with solving
   multi-domain problems in order to allow individual Bandwidth Brokers
   to inter-operate as identified in phase 0 or 1.

4.6.3.  Inter-Domain Signaling

4.6.3.1.  Phase 0

   In phase 0 implementations, no electronic signaling between Bandwidth
   Brokers is performed and SLS negotiation will be performed manually
   (phone, email etc) by network operators.  An RAR is only handled
   within the domain and may originate from a User or ingress router.

4.6.3.2.  Phase 1

   Here a CAC decision is made on information obtained from downstream
   Bandwidth Brokers.  This information could come from the next hop
   Bandwidth Broker or all Bandwidth Brokers downstream to the
   destination.

   Two fundamental signaling approaches between Bandwidth Brokers have
   been identified for the Informed Admission case.  These are
   illustrated in figure 10.











Vollbrecht, et al.           Informational                     [Page 20]

RFC 2905         AAA Authorization Application Examples      August 2000


   +-------+         +-------+         +-------+         +-------+
   |       |         |       |         |       |         |       |
   |       |RAR      |       |    1    |       |   2     |       |
   | User  |-------->|       |-------->|       |-------->|       |
   |       |     RAA | BB1   |    4    |  BB2  |   3     |  BB3  |
   |       |<--------|       |<--------|       |<--------|       |
   |       |         |       |         |       |         |       |
   |       |         |       |         |       |         |       |
   +-------+         +-------+         +-------+         +-------+

   A)End-to-end signaling

   +-------+         +-------+         +-------+         +-------+
   |       |         |       |         |       |         |       |
   |       |RAR      |       |    1    |       |   3     |       |
   | User  |-------->|       |-------->|       |-------->|       |
   |       |     RAA | BB1   |    2    |  BB2  |   4     |  BB3  |
   |       |<--------|       |<--------|       |<--------|       |
   |       |    7    |       |    6    |       |   5     |       |
   |       |<--------|       |<--------|       |<--------|       |
   +-------+         +-------+         +-------+         +-------+

   B) Immediate response signaling.

            Fig. 10 -- Fundamental Signalling Approaches

   -  End to End signaling.  An RAR from a User to BB1 is forwarded to
      BB2 (1). BB2 will forward the request to BB3 (2).  If BB3 is the
      destination of the request, BB3 will authorize the request and
      reply to BB2 (3).  BB2 will then reply to BB1 (4), and BB1 will
      send a Resource Allocation Answer (RAA) back to the User to
      complete the authorization.

   -  Immediate response signaling.  This is the case where BB1 will
      want to authorize an RAR from its domain and forwards the
      authorization request to BB2 (1).  If BB2 approves, the response
      is immediately returned to BB1 (2).  BB1 will send an RAA back to
      the User.  If the authorization was positive BB2 will forward
      subsequently a request to the next BB, BB3 (3).  BB3 authorizes
      the request and responds to BB2 (4).  If the response is negative
      (5), BB2 will cancel the authorization it previously issued to BB1
      (6) and this will result in a cancellation from BB1 to the user
      (7).  In this case the RAA authorization is valid until revoked by
      7.







Vollbrecht, et al.           Informational                     [Page 21]

RFC 2905         AAA Authorization Application Examples      August 2000


4.6.4.  Bandwidth Broker Communication Architecture

   Figure 11 shows components of the discussed Bandwidth Broker
   architecture with its interfaces.

   -  An intra-domain interface allows communication with all the
      service components within the network that the Bandwidth Broker
      controls.

   -  An inter-domain interface allows communication between Bandwidth
      Brokers of different autonomous networks.

   -  A user/application interface allows the Bandwidth Broker to be
      managed manually.  Requests can be sent from the User or a host
      application.

   -  A policy manager interface allows implementation of complex policy
      management or admission control.

   -  A routing table interface allows the Bandwidth Broker to
      understand the network topology.

   -  An NMS interface allows coordination of network provisioning and
      monitoring.



























Vollbrecht, et al.           Informational                     [Page 22]

RFC 2905         AAA Authorization Application Examples      August 2000


           adjacent BB <---------------------------> adjacent BB
                                     |
                                     V
                      +------------------------------+
                      |       | inter-domain |       |
                      |        --------------  ------|
          application |                       |  PM  |
          server  \   |                       |iface |
                   \  |-------   ---------+    ------|
                    ->| user/ | | simple  |    ------|
          user/host-->| app   | | policy  |   | NMS  |
                    ->| iface | | services|   |iface |
                   /  |-------   ---------+    ------|
          network /   |                              |
          operator    |  -------          -------    |
                      | | data  |        |routing|   |
                      | | store |        |info   |   |
                      | |       |        |       |   |
                      |  -------          -------    |
                      |                              |
                      |       ----------------       |
                      |      | intra-domain   |      |
                      +------------------------------+
                                     ^
                                     |
        edge router(s) <---------------------------> edge router(s)

              Fig. 11 -- Bandwidth Broker Architecture

4.6.5.  Two-Tier Inter-Domain Bandwidth Broker Communication Model

4.6.5.1.  Session Initialization

   Before Bandwidth Brokers can configure services between two adjacent
   domains, they have to establish and initialize a relationship.  No
   authentication is used; therefore any trust relationship is implicit.
   Part of the initialization is an exchange of topology information
   (list of adjacent Bandwidth Brokers).

4.6.5.2.  Service Setup

   The Bandwidth Broker must first be configured in regard to agreed
   bi-lateral service levels.  All resources allocated to a particular
   level of provisioned service must be reserved in each domain.

   A Service Setup Request (SSR) is generated  (on demand by the
   operator or at startup of the system) and forwarded to a downstream
   Bandwidth Broker.  The downstream Bandwidth Broker will check the



Vollbrecht, et al.           Informational                     [Page 23]

RFC 2905         AAA Authorization Application Examples      August 2000


   consistency with its own service level specifications and respond
   with Setup Answer message (SA) agreements. This message exchange
   confirms and identifies pre-established service authorization levels.

4.6.5.3.  Service Cancellation

   A Service Cancellation (SC) message may cancel a service
   authorization. This message may be initiated by the operator or by an
   expiration date. A Cancellation Answer (CA) is returned.

4.6.5.4.  Service Renegotiation

   An (optional) Service-Renegotiation message (SR) may allow a
   Bandwidth Broker to re-negotiate an existing service.  This message
   may be initiated by the operator or automatically when a certain
   threshold is reached.  Renegotiations happen within the margins of a
   pre-established authorization.

4.6.5.5.  Resource Allocation Request and Resource Allocation Answer

   An RAR allocates a requested level of service on behalf of the User
   and when available it will decide on the admittance of a certain User
   to the service. A Bandwidth Broker may receive an RAR via either the
   intra-domain or inter-domain interface.  The RAR must refer to the
   Service SetUp Identification (SSU_ID), which binds a request to a
   certain authorization. A Resource Allocation Answer (RAA) confirms or
   rejects a request or it may indicate an "in progress" state.

4.6.5.6.  Session Maintenance

   A certain level of session maintenance is required to keep Bandwidth
   Brokers aware of each other.  This must be implemented using time-
   outs and keep-alive messages.  This will help Bandwidth Brokers to
   notice when other Bandwidth Brokers disappear.

4.6.5.7.  Intra-domain Interface Protocol

   The Intra-domain interface protocol used between a Bandwidth Broker
   and the routers it controls may be COPS, SNMP, or Telnet Command Line
   Interface.

4.7.  Requirements

   From the above descriptions we derive the following requirements.







Vollbrecht, et al.           Informational                     [Page 24]

RFC 2905         AAA Authorization Application Examples      August 2000


   -  The Authorization mechanism may require trust relationships to be
      established before any requests can be made from the User to the
      Service Provider.  Currently trust relationship establishment is
      implicit.

   -  A confirmation of authorization is required in order to initialize
      the system.

   -  A negation of static authorization is required to shut down
      certain services.

   -  A renegotiation of static authorization is required to alter
      services (SLS's).

   -  Dynamic authorization requests (RAR) must fit into pre-established
      static authorizations (SLS's).

   -  Dynamic authorization requests (RAR) may be answered by an "in
      progress state" answer.

   -  Provisions must be made to allow reconstruction of authorization
      states after a Bandwidth Broker re-initializes.

5.  Internet Printing

   The Internet Printing Protocol, IPP [14], has some potentially
   complex authorization requirements, in particular with the "print-
   by-reference" model.  The following attempts to describe some
   possible ways in which an authorization solution for this aspect of
   IPP might work, and to relate these to the framework described in
   [2].  This is not a product of the IPP working group, and is meant
   only to illustrate some issues in authorization in order to establish
   requirements for a "generic" protocol to support AAA functions across
   many applications.

   IPP print-by-reference allows a user to request a print service to
   print a particular file.  The user creates a request to print a
   particular file on a printer (or one of a group of printers).  The
   key aspect is that the request includes only the file name and not
   the file content. The print service must then read the file from a
   file server prior to printing.  Both the file server and the print
   server must authorize the request.  Once initiated, printing will be
   done without intervention of the user; i.e., the file will be sent
   directly to the print service rather than through the user to the
   printer.






Vollbrecht, et al.           Informational                     [Page 25]

RFC 2905         AAA Authorization Application Examples      August 2000


5.1.  Trust Relationships

   The assumption is that the Printer and File Server may be owned and
   operated by different organizations.  There appear to be two models
   for how "agreements" can be set up.

   1. User has agreement with Print Server; Print Server has agreement
      with File Server.

   2. User has agreements with both File and Print Server directly.

   In case 1, the user has a trust relationship with the Print Service
   AAA Server.  The Printer forwards the request to the File Server. The
   File Server authorizes the Printer and determines if the Printer is
   allowed access to the file.  Note that while there may be some cases
   where a Print Server may on its own be allowed access to files
   (perhaps some "public files", or that can only be printed on certain
   "secure" printers), it is normally the case that files are associated
   with users and not with printers.  This is not a good "generic" model
   as it tends to make the print service an attractive point of attack.

            +------+       +----------------------+
            |      |       | File Service         |----+
            |      |       | AAA Server           |<-+ |
            |      |       +----------------------+  | |
            |      |       |                      |  | |
            |      |       | File Server          |  | |
            |      |       |                      |  | |
            | User |       +----------------------+  | |
            |      |                                 | |
            |      |                                 | |
            |      |                                 | |
            |      |       +----------------------+  | |
            |      |------>| Print Service        |--+ |
            |      |<------| AAA Server           |<---+
            |      |       +----------------------+
            |      |       | Print Server         |
            |      |       |  and Printer         |
            +------+       +----------------------+

          Fig. 12 -- Case 1
                     User authorizes with Print Service.
                     Printer authorizes with File Service.

   In case 2, the user must have a trust relationship with both the file
   and print services so that each can verify the service appropriate to
   the User.  In this case, the User first contacts the File Service AAA
   Server and requests that it enable authorization for the Print



Vollbrecht, et al.           Informational                     [Page 26]

RFC 2905         AAA Authorization Application Examples      August 2000


   Service to access the file.  This might be done in various ways, for
   example the File Service AAA Server may return a token to the User
   which can (via the Print Service) be presented to the File Server to
   enable access.

               +------+       +----------------------+
               |      |------>| File Service         |
               |      |<------| AAA Server           |
               |      |       +----------------------+
               |      |
               |      |       +----------------------+
               |      |       | File Server          |
               | User |       +----------------------+
               |      |              /|\  |
               |      |               |   |
               |      |               |  \|/
               |      |       +----------------------+
               |      |------>| Print Service        |
               |      |<------| AAA Server           |
               |      |       +----------------------+
               |      |       | Print Server         |
               |      |       |  and Printer         |
               +------+       +----------------------+

         Fig. 13 -- Case 2
                    User authorizes File and Print Service.
                    Must create binding for session between
                    Print Service and File Service.

5.2.  Use of Attribute Certificates in Print-by-Reference

   The print-by-reference case provides a good example of the use of
   attribute certificates as discussed in [2].  If we describe case 2
   above in terms of attribute certificates (ACs) we get the diagram
   shown in figure 14.
















Vollbrecht, et al.           Informational                     [Page 27]

RFC 2905         AAA Authorization Application Examples      August 2000


      +------+       +----------------------+
      |      |------>| File Service         |
      |      |<------| AAA Server           |
      |      |Get AC +----------------------+
      |      |
      |      |       +----------------------+
      |      |       | File Server          |----+
      |      |       |                      |<-+ |
      | User |       +----------------------+  | |
      |      |                                 | |
      |      |   +---authorize passing AC      | |<---Create session
      |      |   |                             | |    Using AC
      |      |   V   +----------------------+  | |
      |      |------>| Print Service        |  | |
      |      |<------| AAA Server           |  | |
      |      |       +----------------------+  | |
      |      |       | Print Server         |--+ |
      |      |       |  and Printer         |<---+
      +------+       +----------------------+

       Fig. 14 -- Using Attribute Certificates in IPP Authorization

   In this case, the User gets an AC from the File Service's AAA Server
   which is signed by the File Service AAA Server and contains a set of
   attributes describing what the holder of the AC is allowed to do. The
   User then authorizes with the Print Service AAA Server and passes the
   AC in the authorization request.  The Printer establishes a session
   with the File Server, passing it the AC.  The File Server trusts the
   AC because it is signed by the File Service AAA Server and allows (or
   disallows) the session.

   It is interesting to note that an AC could also be created and signed
   by the User, and passed from the Print Server to the File Server. The
   File Server would need to be able to recognize the User's signature.
   Yet another possibility is that the Print Service AAA Server could
   simply authenticate the User and then request an AC from the File
   Service AAA Server.

5.3.  IPP and the Authorization Descriptive Model

   The descriptive model presented in [2] includes four basic elements:
   User, User Home Organization, Service Provider AAA Server, and
   Service Equipment.

   Mapping these to IPP, the User is the same, the User Home
   Organization (if included) is the same.  The Service Provider AAA
   Server and the Service Equipment  are expected to be closely coupled
   on the same processor.  In other words, the interface between the



Vollbrecht, et al.           Informational                     [Page 28]

RFC 2905         AAA Authorization Application Examples      August 2000


   Print Service AAA Server and the Printer as well as that between the
   File Service AAA Server and the File Server is an internal one that
   will not require a formal protocol (although some standard API might
   be useful).

   The concept of a Resource Manager (see [2]) has some interesting
   twists relative to IPP.  Once started, the user is not involved in
   the service, but until printing is complete it seems useful that any
   of the parties in the authorization process be allowed to query for
   status or to cancel the print session.   The user needs a way to
   "bind" to a particular session, and may have to reauthorize to be
   allowed to access Resource Manager information.

6.  Electronic Commerce

   This section describes the authorization aspects of an e-commerce
   architecture typically used in Europe.  We will use this model to
   identify contractual and trust relationships and message exchanges.
   We will then identify a set of authorization requirements for e-
   commerce.

   Whereas most e-commerce protocols focus on authentication and message
   integrity, e-commerce exchanges as described by the Internet Open
   Trading Protocol (trade) Working Group in [15] also involve
   authorization.  This section will examine one e-commerce protocol
   called SET (Secure Electronic Transaction) that provides for credit
   and debit card payments.  We will analyze the authorization aspects
   from an architectural viewpoint.  We will apply concepts and terms
   defined in [2].

   We are not here proposing SET as a standard authorization protocol.
   Rather, we are examining the SET model as a way of understanding the
   e-commerce problem domain so that we can derive requirements that an
   authorization protocol would have to meet in order to be used in that
   domain.

   E-commerce protocols and mechanisms such as those described in [16]
   may not only be important to allow customers to shop safely in
   Cyberspace, but may also be important for purchases of Internet
   services as well.  With emerging technologies allowing Internet
   transport services to be differentiated, an inherently more complex
   pricing model will be required as well as additional payment methods.
   Flexible authorization of services will be an important aspect to
   allow, for example, globally roaming users ad hoc allocation of
   premium bandwidth with an ISP who is authorized to accept certain
   credit card brands.





Vollbrecht, et al.           Informational                     [Page 29]

RFC 2905         AAA Authorization Application Examples      August 2000


6.1.  Model Description

   The establishment of a model involves four steps:

   1. identification of the components that are involved and what they
      are called in this specific environment,
   2. identification of the relationships between the involved parties
      that are based on some form of agreement,
   3. identification of the relationships that are based on trust, and
   4. consideration of the sequence of messages exchanged between
      components.

6.1.1.  Identification of Components

   We will consider the components of an electronic commerce transaction
   in the context of the conceptual entities defined in [2].

   -  The Cardholder (User) -- the person or organization that is to
      receive and pay for the goods or services after a request to
      purchase has been received.  In SET terms this is called a
      Cardholder.

   -  The Issuer (User Home Organization) -- the financial organization
      that guarantees to pay for authorized transactions to purchase
      goods or services on behalf of the User when using a debit or
      credit card it issues.  The financial organization (typically a
      bank or Brand Organization) will transfer money from the user
      account to the account the party to which the User instructs it to
      send the payment. The issued card authorizes the User to use the
      card for payments to merchants who are authorized to accept the
      card.  In SET terms this organization is called the Issuer.  This
      organization is considered "home" to the Cardholder.

   -  The Merchant (Service Provider) -- the organization from whom the
      purchase is being made and who is legally responsible for
      providing the goods or services and receives the benefit of the
      payment made.  In SET terms this organization is called a
      Merchant.  The Cardholder is considered to be "foreign" to the
      Merchant.

   -  The Acquirer (Broker) -- the organization that processes credit or
      debit card transactions.  Although in reality this function may be
      rather complex and may span several organizations, we will simply
      assume this organization to be a Brand Organization fulfilling the
      role of the Acquirer as defined in SET.  The Acquirer establishes
      an account with the Merchant.  The Acquirer operates a Payment
      Gateway that will accept payment authorization requests from




Vollbrecht, et al.           Informational                     [Page 30]

RFC 2905         AAA Authorization Application Examples      August 2000


      authorized merchants and provide responses from the issuer.  The
      Acquirer will forward an authorization request to the Issuer.  The
      Acquirer is considered "home" to the Merchant.

   As the SET document [16] notes, a Brand Organization (credit card
   organization) may handle both the Issuer function and Acquirer
   function that operates a Payment Gateway.  For simplicity, we
   therefore assume that the authorization role of Broker (Acquirer) and
   User Home Organization (Issuer) both belong to the Brand
   Organization.

   In order to be more descriptive we now use the SET terms.  In the
   requirements section these terms are mapped back into the
   authorization framework terms again.

6.1.2.  Identification of Contractual Relationships

   Contractual relationships are illustrated in figure 15, below.

   -  The Cardholder has a contractual relationship with the card
      Issuer.  The Cardholder holds an account with the Issuer and
      obtains an account number.

   -  The Merchant has a contractual relationship with the Acquirer.
      The Merchant obtains a Merchant ID from the Acquirer.

   -  In the real world there may be no direct contractual relationship
      between the Issuer and the Acquirer.  The contractual
      relationships allowing an Acquirer to relay a payment
      authorization request to an Issuer may be very complex and
      distributed over multiple organizations. For simplicity, however,
      we assume there are contracts in place allowing an Acquirer to
      request payment authorization from an Issuer.  These contracts are
      facilitated by the Brand Organization.  Therefore, in our
      simplified example, the Acquirer and Issuer belong to the same
      Brand Organization.  The Acquirer operates a Payment Gateway for
      which it needs a Bank Identification Number (BIN).














Vollbrecht, et al.           Informational                     [Page 31]

RFC 2905         AAA Authorization Application Examples      August 2000


               +----------------+       +------------------------+
               | Issuer         |       | Acquirer               |
               | (User Home     |       | (Broker)               |
               |  Organization) |       |  +------------------+  |
               |                |=======|  |  Payment         |  |
               |                |       |  |  Gateway         |  |
               |                |       |  +------------------+  |
               |                |       |                        |
               +----------------+       +------------------------+
                       ||                             ||
                       ||                             ||
                       ||                             ||
               +----------------+       +--------------------+
               | Cardholder     |       | Merchant           |
               | (User)         |       | (Service Provider) |---+
               |                |       |                    |   |
               |                |       |                    |   |
               |                |       +--------------------+   |
               |                |         |                      |
               |                |         | Fulfillment          |
               |                |         |                      |
               +----------------+         +----------------------+

                    Fig. 15 -- SET Contractual Relationships

6.1.3.  Identification of Trust Relationships

   It is important to recognize that there are two kinds of trust
   relationships: static and dynamic trust relationships.  Static trust
   relationships in SET are established by means of a registration
   process that will request a certificate to be issued to the party
   that needs to be trusted and authorized to be part of a SET
   transaction.  Dynamic trust is created at the time of a payment
   transaction and its subsequent authorization request.  Note that at
   the issue phase of a certificate, based on identification and
   registration, the user of the certificate gets an implicit static
   authorization and a means of authenticating and securing messages.
   For this purpose a Certificate Authority (CA) will issue certificates
   that are used to sign and/or encrypt messages exchanged according to
   the SET protocol.











Vollbrecht, et al.           Informational                     [Page 32]

RFC 2905         AAA Authorization Application Examples      August 2000


6.1.3.1.  Static Trust Relationships

   In the discussion that follows, refer to figure 16, below.

                               +-------+
                               | Root  |
                               |  CA   |
                               +-------+     CA = Certificate Authority
                                   |        {C} = Certificate
                                   |
                        +-----------------+
                        |        Brand    |
                        |         CA      |
                        +-----------------+
                          |        |    |
                          |        | +-------+
                          |        | |Payment|
   +----------------+     |        | |Gateway| +----------------------+
   | Issuer         |     |        | |  CA   | | Acquirer             |
   | (User Home     | +----------+ | +-------+ | (Broker)             |
   |  Organization) | |Cardholder| |    |      |  +----------------+  |
   |                | |    CA    | |    +------+--+-{C} Payment    |  |
   |                | +----------+ |       3   |  |     Gateway    |  |
   |                |     |        |           |  +----------------+  |
   |                |     |   +---------+      |                      |
   +----------------+     |   | Merchant|      +----------------------+
                          |   |    CA   |
                          |   +---------+
                          |        |
   +----------------+     |        |           +--------------------+
   | Cardholder     |     |        |           | Merchant           |
   | (User)         |     |        |           | (Service Provider) |--+
   |            {C}-+-----+        |           |                    |  |
   |                |  1           +-----------+-{C}                |  |
   |                |                    2     |                    |  |
   |                |                          |                    |  |
   |                |                          +--------------------+  |
   |                |                            |                     |
   |                |                            | Fulfillment         |
   |                |                            |                     |
   +----------------+                            +---------------------+

         Fig. 16 -- SET Trust Relationships within a Brand Domain

   -  The Brand Organization operates a Brand CA and is therefore the
      holder of the common trust within the described domain.  All
      involved parties (Cardholder, Issuer, Merchant and Acquirer) are
      members of the same trust domain.  We will identify three separate



Vollbrecht, et al.           Informational                     [Page 33]

RFC 2905         AAA Authorization Application Examples      August 2000


      CA's which issue a certificate on behalf of the Issuer, the
      Acquirer and the Brand Organization.  The Brand CA, according to a
      tree like hierarchy, certifies all underlying CA's.  The Brand CA
      obtains its trust from a single Root Certificate Authority.
      Before any party can obtain a Certificate from a CA, the party
      must have some form of contractual relationship.

   -  After an account has been established with the Issuer, the
      Cardholder has to register with a Cardholder CA (CCA) through a
      series of registration steps (1) as defined in the SET protocol.
      If the CCA approves the registration, the Cardholder will obtain a
      Cardholder Certificate.  The CCA may be operated by the Brand
      Organization on behalf of the Issuer.  The Cardholder Certificate
      is an electronic representation of the payment card.  This process
      creates a trust relationship between the Cardholder and the Brand.
      After the cardholder has received the Cardholder Certificate, the
      Cardholder is authorized to perform payments to an authorized
      Merchant.

   -  After the Merchant has obtained a Merchant ID from the Acquirer,
      the Merchant has to register with the Merchant CA (MCA) through a
      series of registration steps (2) as defined in the SET protocol.
      If the MCA approves the registration, the Merchant will obtain a
      Merchant Certificate.  This process creates a trust relationship
      between the Merchant and the Brand.  The MCA may be operated by
      the Brand Organization on behalf of the Acquirer.  After
      registration, the Merchant is authorized to accept payment
      requests from Cardholders and to send authorization requests to
      the Acquirer's Payment Gateway.

   -  After the Acquirer has obtained a valid Bank Identification Number
      (BIN), the Acquirer must register with the Payment Gateway CA
      (PCA) in order to obtain a Payment Gateway Certificate (3).  The
      Payment Gateway Certificate authorizes the Gateway to accept
      payment authorization requests originating from Merchants within
      its trust domain.

   -  The Acquirer and Issuer have a trust relationship via the Brand
      Organization.  The trust relationship is not ensured by procedures
      or a mechanism defined by SET, as this is a problem solved by
      agreements between financial organizations facilitating the
      payment service.  Again, for simplicity, we assume that the
      relationship ensures that payment authorization requests received
      by the Acquirer's gateway will be forwarded in a secure and
      efficient way to the Issuer and its response is handled in the
      same way.





Vollbrecht, et al.           Informational                     [Page 34]

RFC 2905         AAA Authorization Application Examples      August 2000


6.1.3.2.  Dynamic Trust Relationships

   Note that there is no prior established static trust relationship
   between the Cardholder and the Merchant, as a Cardholder does not
   have to register with a Merchant or vice versa.  The trust
   relationship is dynamically created during the communication process
   and is based on the common relationship with the Brand.  By means of
   digital signatures using public key cryptography, the Cardholder's
   software is able to verify that the Merchant is authorized to accept
   the Brand Organization's credit card.  The merchant is able to verify
   that the Cardholder has been authorized to use the Brand
   Organization's credit card.

6.1.4.  Communication Model

   The purchase request from Cardholder to Merchant and subsequent
   payment authorization exchange between Merchant and Acquirer is
   illustrated in figure 17 and described below.

































Vollbrecht, et al.           Informational                     [Page 35]

RFC 2905         AAA Authorization Application Examples      August 2000


         +----------------+       +------------------------+
         | Issuer         |       | Acquirer               |
         | (User Home     |       | (Broker)               |
         |  Organization) |       |  +------------------+  |
         |                |<------+--|  Payment         |  |
         |                |   5   |  |  Gateway         |  |
         |                |-------+->|                  |  |
         |                |   6   |  +------------------+  |
         |                |       |        /|\  |          |
         +----------------+       +---------+---+----------+
                                            |4  |7
                                            |  \|/
         +----------------+       +--------------------+
         | Cardholder     |       | Merchant           |
         | (User)         |       | (Service Provider) |---+
         |                |------>|                    |   |
         |                |   1   |                    |   |
         |                |<------|                    |   |
         |                |   2   |                    |   |
         |                |------>|                    |   |
         |                |   3   |                    |   |
         |                |<------|                    |   |
         |                |   8   |                    |   |
         |                |       |                 |  |   |
         |                |       +-----------------+--+   |
         |                |         |               |9     |
         |                |<--------| Fulfillment  \|/     |
         |                |   10    |                      |
         +----------------+         +----------------------+

                  Fig. 17 -- Communication Sequence

   1. The Cardholder shops and decides to purchase some goods at
      merchant.com. The Cardholder has selected a list of goods and the
      Merchant's software has subsequently prepared an order form for
      the Cardholder indicating the price, the terms and conditions, and
      the accepted payment methods.  The SET transaction starts at the
      moment the Cardholder indicates that he or she wants to pay for
      the goods using a certain payment brand.  The Cardholder software
      sends a request to the Merchant that initiates the payment
      process.

   2. The Merchant checks the order and signs it and returns it to the
      Cardholder including a certificate from the Acquirer's Gateway
      that allows the Cardholder to encrypt payment instructions that
      are only relevant to the Gateway and not to the Merchant (e.g.,
      the Cardholder's credit card information).  The Cardholder also
      includes his or her own certificate.



Vollbrecht, et al.           Informational                     [Page 36]

RFC 2905         AAA Authorization Application Examples      August 2000


   3. The Cardholder now verifies both certificates (the software has
      the CA's root certificate).  The Cardholder software generates a
      message containing the order information and the payment
      instructions that is signed by the Cardholder.  Using the Gateway
      Certificate, it will encrypt the Payment Instruction so that it
      will only be readable by the Gateway.  The Cardholder will include
      his or her certificate.

   4. The Merchant verifies the Cardholder certificate and checks the
      message integrity.  He or she will now process the payment and
      issue a payment authorization request to the gateway.  The payment
      authorization request contains the Cardholder's certificate and
      both Merchant certificates.

   5. The Gateway verifies the Merchant's signature certificate and that
      the Merchant signed the authorization request.  Next it will
      obtain the account information and payment instructions and will
      check the message integrity and the Cardholder's certificate.  If
      everything is in proper order it will send an authorization
      request to the Issuer via a secure bank network.

   6. The issuer returns the authorization.

   7. The Acquirer's Gateway generates an authorization response which
      includes the gateway's certificate.

   8. The Merchant checks the authorization response and completes the
      process by forwarding a purchase response to the Cardholder.

   9. The Merchant software authorizes the delivery of the purchased
      goods.

   10. The Cardholder receives the purchased goods.

6.2.  Multi Domain Model

   In the previous "single" domain case we already assume that there are
   multiple Cardholders, Merchants, Issuers and Acquirers.  However all
   these parties belong to a single trust domain as there is only a
   single CCA, MCA and PCA.  The trust relationship between multiple
   cardholders and multiple Issuers go via a single CCA in the same way
   as the trust relationship between an Acquirer and a Merchant uses the
   same MCA.  The multi-domain case arises when there are multiple
   domains of CCA's, MCA's and PCA's.  In SET these domains reside under
   a particular Geopolitical CA (GCA) which is illustrated in figure 18.






Vollbrecht, et al.           Informational                     [Page 37]

RFC 2905         AAA Authorization Application Examples      August 2000


                        +-----------+
                        |  Root CA  |
                        |           |
                        +-----------+
                              |
                              |
       +----------------------|-------------------------------+
      +-----------------------------------------------------+ |
      |                   Brand CA                          | |
      |                                                     |-+
      +-----------------------------------------------------+
                              |
                              |
       +----------------------|-------------------------------+
      +-----------------------------------------------------+ |
      |                   Geopolitical CA                   | |
      |                                                     |-+
      +-----------------------------------------------------+
            |                 |                    |
            |                 |                    |
       +----|--------+    +---|-------+    +-------|----------+
      +------------+ |   +----------+ |   +-----------------+ |
      | Cardholder | |   | Merchant | |   | Payment Gateway | |
      |     CA     |-+   |    CA    |-+   |       CA        |-+
      +------------+     +----------+     +-----------------+

         Fig. 18 -- SET Certificate Management Architecture

   A GCA may represent a country or region.  The architecture defines a
   trust hierarchy needed to manage and verify SET Certificates as these
   need to be issued, renewed or revoked.  Each geopolitical region may
   have different policies for issuing, renewing or revoking
   certificates. However once certificates have been issued, Cardholders
   and Merchants belonging to different GCA's can still be recognized as
   belonging to the same Brand.  This will allow a European Cardholder
   to purchase goods in the U.S.  The U.S. Acquirer's gateway will
   recognize that the Cardholder belongs to the same Brand and will
   therefore accept a payment authorization request.

6.3.  Requirements

   Many e-commerce environments do not use SET.  Other mechanisms exist
   based on SSL, XML, and S/MIME.  Also a mechanism that uses SET only
   for the payment authorization to the Gateway exists and is known as
   half SET.  However, using the model described in this document, we
   can derive a fairly comprehensive set of protocol requirements for
   e-commerce.  In these requirements, the SET terms are replaced again
   by the descriptive model terms:



Vollbrecht, et al.           Informational                     [Page 38]

RFC 2905         AAA Authorization Application Examples      August 2000


      Cardholder = User
      Merchant = Service Provider
      Issuer = User Organization
      Acquirer = Broker

   1. The Authorization mechanism must allow trust relationships to be
      established before any requests can be made from the User to the
      Service Provider and from the Service Provider via a Broker to the
      User Organization.  This process will enable the parties to
      communicate securely by creating an authenticated channel and, by
      so doing, implicitly authorizing its usage.

   2. Upon receipt of any request or response, entities need to be able
      to verify whether the transmitting party is still authorized to
      send this request or response.

   3. The User must be able to authorize the Service Provider to request
      an authorization from the User Home Organization.

   4. The User must be able to authorize fulfillment of a proposed
      service offer from the Service Provider.

   Other requirements related to the authorization process:

   Integrity

   5. For any authorization request or response, the receiving party
      needs to verify that the content of the message has not been
      altered.

   Confidentiality/Privacy

   6. The User must be able to pass information relevant to the session
      authorization process to the User Home Organization via a Broker
      and the Service Provider without allowing the Broker or the
      Service Provider to examine its content.

   7. The User Home Organization must be able to communicate information
      relevant to the session authorization via the Broker and the
      Service Provider to the User without allowing the Broker or the
      Service Provider to examine its content.

   Nonrepudiation

   8. There is a need for a recorded, authenticated and authorized
      agreement about the request for and delivery of service.





Vollbrecht, et al.           Informational                     [Page 39]

RFC 2905         AAA Authorization Application Examples      August 2000


7.  Computer Based Education and Distance Learning

   This section describes the authorization aspects of computer based
   distance learning environments.  In this section we will model the
   relationships and working practices in a hypothetical university
   environment where a student enrolls in courses, attends lectures, and
   takes the corresponding exams from remote locations (distance
   learning) or via computer equipment (computer based education).  When
   completed successfully, a student is authorized to enroll in a set of
   subsequent courses according to his or her curriculum requirements.
   Completion of required courses with passing grades results in
   graduation.

   Although this section specifically describes an example of a student
   taking courses at a faculty (department) of the university, the
   resulting requirements should also be valid for other applications in
   similar environments, e.g. library loans, electronic abstract and
   reprint services, computer and network access, use of copy machines,
   budget management, store retrievals, use of coffee machines and
   building access.

   It is important to recognize that the AAA environment we are
   describing also needs to be managed.  For example, for an application
   such as budget management, it is necessary to delegate budget
   authority from a central financial department to budget managers in
   education or faculty groups.  An AAA environment must allow creation
   of policy rules either by certain individuals or by other AAA servers
   with authorization to do so.

7.1.  Model Description

   The establishment of the model involves four steps:

   1. identification of the components that are involved and what they
      are called in this specific environment,

   2. identification of the contractual relationships between the
      involved parties,

   3. identification of the relationships that are based on trust, and

   4. consideration of the sequence of messages exchanged between
      components.

7.1.1.  Identification of Components

   We will consider the components of a distance learning environment in
   the context of the conceptual entities defined in [2].



Vollbrecht, et al.           Informational                     [Page 40]

RFC 2905         AAA Authorization Application Examples      August 2000


   -  The Student (User) -- the person enrolling in a course (Service)
      and taking the corresponding exam.

   -  The Educator (Service Equipment) -- the education content server
      for which the content is delivered by the Professor.

   -  The Educator Authorization Module (Service Provider AAA Server).
      This module must check at the service access point whether the
      student complies with the requirements for enrolling in the
      course.  The authorization may be based on both local (by the
      professor) and remote policies (originating from the faculty).
      Rules must allow enough flexibility to prevent students from being
      falsely denied access to courses.  Strict rules must only be
      applied at graduation time.

   -  The Faculty (Service Provider) -- the organization (department in
      U.S. terms) which controls the Service "Equipment" of which the
      Educator is one example.

   -  The Curriculum Commission (Part of User Home Organization) -- body
      responsible for creating rules by which a student is allowed to
      enroll in a certain course and how this course will count toward
      his or her graduation requirements.  Students may legally take any
      course available at any time, however the Curriculum Commission
      will decide whether this course will contribute towards their
      graduation.  When a Student registers with a certain Educator, the
      Educator may check with the Curriculum Commission AAA server
      whether the course will count towards graduation and confirm this
      with the student.

   -  The Student Administration (Part of User Home Organization) -- the
      administrative organization that authorizes students to enroll in
      courses if certain criteria, including financial criteria, are
      met.  Next to the student, the Student Administration will keep
      track of any exam results for the student and will issue a
      graduation certificate when all criteria are met.

7.1.2.  Identification of Contractual Relationships

   Contractual relationships are illustrated in figure 19, below. Based
   on contract relationships,specific trust relationships are created as
   required.

   Although not shown in figure 19, it is assumed that the university
   has contractual relationships with the faculties in which every
   faculty is allowed and obligated to build, maintain and present one
   or more specific studies.




Vollbrecht, et al.           Informational                     [Page 41]

RFC 2905         AAA Authorization Application Examples      August 2000


                     +---------------------------------------------+
                     | +-----------------------------------------+ |
                     | |          Faculty administration         | |
                     | |+----------------+     +----------------+| |
                     | |O Student        |     | Curriculum     || |
                     | *| Administration O*****O Commission     || |
                     |*|| AAA Server     |     | AAA Server     || |
                     */|+---O------O-----+     +-----O------O---+| |
                    *//|    *       *               *       *    | |
                   *// +----*---------*-----------*---------*----+ |
                  *//|      *   ||      *       *     ||    *      |
                 *// |      *   ||        *   *       ||    *      |
                *//  |      *   ||          *         ||    *      |
               *//   |      *   ||        *   *       ||    *      |
              *//    |      *   ||      *       *     ||    *      |
             *//     | +----*---------*--+     +--*---------*----+ |
            *//      | |    *       *    |     |    *       *      |
           *//       | |+---O------O----+|     |+----O------O---+| |
          *//        | || Educator A    ||     || Educator B    || |
         *//         | || AAA Server    ||     || AAA Server    || |
        *//          | || Service admin.||     || Service admin.|| |
       *//           | |+---O-----------+|     |+-----------O---+| |
      *//            | |    *            |     |            *    | |
   +-O-------+       | |    *            |     |            *    | |
   |         |       | |+---O-----------+|     |+-----------O---+| |
   | Student |       | || Educator      ||     || Educator      || |
   |         |       | || Course A      ||     || Course B      || |
   |         |       | |+---------------+|     |+---------------+| |
   +---------+       | +-----------------+     +-----------------+ |
                     |                   Faculty                   |
                     +---------------------------------------------+

                     // = contractual relationship
                     ** = trust relationship

       Fig. 19 -- Contractual relationships - single domain case

   As shown in figure 19, the Student has a contractual relationship
   with the Faculty.  The contract allows the Student to pursue a course
   of study consisting of a set of courses.  Courses are presented to
   the Students by the Educators.  A course of study may consist of
   courses from different Faculties.

   Faculties have contracts among them allowing Students from one
   Faculty to enroll in courses from other Faculties.






Vollbrecht, et al.           Informational                     [Page 42]

RFC 2905         AAA Authorization Application Examples      August 2000


   Faculties instantiate Educators based on a contract between the
   Faculty Administration and the professor implementing and managing
   the Educator. Authorization is based on policy rules defined by one
   or more parties in the contractual relationships.  For example, a
   professor has a policy to give the course only in the afternoon and
   the Faculty has a policy to give the course to their own students and
   students from faculty-x but not, when oversubscribed, to faculty-y
   students.

7.1.3.  Identification of Trust Relationships

   Figure 19 illustrates relevant trust relationships which statically
   enable AAA entities to communicate certain attributes in our
   simplified example. However, in order for the illustrated entities to
   work, other trust relationships that are not illustrated must already
   be in existence:

   -  A trust relationship based on a contract between the Faculty and
      the university enables a faculty to create and teach specific
      courses belonging to a course of study.

   -  Although not further detailed in this example, it is worth noting
      that trust relationships between faculties authorize students from
      one faculty to enroll in courses with other faculties.

   -  A professor responsible for the content of the Educator has a
      trust relationship with the administration of the faculty.
      Through this relationship, the faculty enables the professor to
      teach one or more courses fitting the requirements of the
      Curriculum Commission.

   Figure 19 illustrates the following trust relationships:

   -  When a person wants to become a Student of a Faculty, the contract
      requires the Student to register with the Student Administration
      of the Faculty.  If the requirements for registration are met, a
      trust relationship with the Faculty enables the Student to
      register for courses.  For this purpose, the Student
      Administration will issue a student card which contains a student
      ID and information about the Faculty he or she is admitted to.
      The Student Administration will only admit Students who pay the
      necessary fees and have met certain prerequisites.  The Student
      Administration will also keep track of Student grades and will
      ultimately issue a certificate at graduation. The Student
      Administration AAA server has access to relevant student data and
      will only issue grade information and other student-related
      information to authorized parties which have a specified means of
      authenticating.



Vollbrecht, et al.           Informational                     [Page 43]

RFC 2905         AAA Authorization Application Examples      August 2000


   -  The Curriculum Commission AAA server needs a trust relationship
      with the Student Administration AAA server in order to obtain
      grade information to check whether a student has met the required
      course prerequisites.  The Curriculum Commission creates certain
      rules within its AAA server which are evaluated when a particular
      student attempts to register for a particular course in order to
      give an advisory to the student.

   -  The Educator AAA server needs a trust relationship with the
      Student Administrator AAA server in order to verify whether this
      particular Student is in good standing with the Faculty.  Only
      authorized Educator AAA servers may send requests to the Student
      Administration AAA server.

   -  The Educator AAA server needs a trust relationship with the
      Curriculum Commission AAA server in order to allow the Educator to
      obtain an advisory for the Student whether this course is
      consistent with his or her curriculum or whether the student meets
      the course prerequisites.  Only authorized Educator AAA servers
      may send requests to the Curriculum AAA Server.

7.1.4.  Sequence of Requests

   For the sake of simplicity, we take the example of a student from the
   same faculty as the professor.

   In this example the following interactions take place for a
   hypothetical course (see figure 20).























Vollbrecht, et al.           Informational                     [Page 44]

RFC 2905         AAA Authorization Application Examples      August 2000


                   +----------------------------------------------+
                   |                                              |
                   |  +----------------+  6   +----------------+  |
                   |  | Student        |----->| Curriculum     |  |
                   |  | Administration |<-----| Commission     |  |
                   |  | AAA Server     |  5   | AAA Server     |  |
                   |  +----------------+    _ +----------------+  |
                   |    /|\ |               /|/                   |
                   |     |  |              / /                    |
                   |  2,8|  |3            / /6                    |
                   |     |  |           4/ /                      |
                   |     |  |           / /                       |
                   |     |  |          / /                        |
                   |     | \|/        /|/                         |
                   |  +---------------+ --     +---------------+  |
                   |  | Educator A    |        | Educator B    |  |
                   |  | AAA Server    |        | AAA Server    |  |
                   |  +---------------+        +---------------+  |
                   |    /|\ |                                     |
                   |2,4,8|  |3,6                                  |
   +---------+     |     | \|/                                    |
   |         | 1,7 |  +---------------+        +---------------+  |
   | Student |------->| Educator      |        | Educator      |  |
   |         |<-------| Course A      |        | Course B      |  |
   |         | 7,8 |  +---------------+        +---------------+  |
   +---------+     |                   Faculty                    |
                   +----------------------------------------------+

           Fig. 20 -- AAA transactions - single domain case

   1. After the Professor has set up the Service Equipment (Educator)
      students come to it presenting their ID (college card,
      name+faculty) and ask to be admitted to the course.

   2. The Educator checks the ID to determine it is indeed dealing with
      a student from the faculty.  This can include a check with the
      Student Administration.

   3. The Student Administration replies to the Educator AAA Server, and
      the Educator AAA Server replies to the Educator.

   4. The Educator checks the request of the Student against its own
      policy (courses only in the afternoon) and checks with the
      Curriculum Commission whether this student is advised to take the
      course.  The necessary information is not normally known to or
      maintained by the professor.





Vollbrecht, et al.           Informational                     [Page 45]

RFC 2905         AAA Authorization Application Examples      August 2000


   5. The Curriculum Commission may check against the Student
      Administration to see if the Student had the necessary grades for
      the previous courses according to the policies set by the
      Curriculum Commission.

   6. The Student Administration replies to the Curriculum Commission,
      the Curriculum Commission replies to the Educator AAA Server, and
      the Educator AAA Server replies to the Educator.

   7. If now authorized, the Student is presented the material and the
      Student returns completed exams.

   8. If the Student passes the tests, the Educator informs both the
      Student and the Student Administration that the Student has
      passed.

7.2.  Requirements

   We identify the following requirements for an AAA server environment
   for this example:

   1. It must be possible to delegate authority to contracted partners.
      Although this requirement is not explicit in the limited example,
      the relationship between University and Faculty may require
      delegation of authority regarding the curriculum to the Faculty.
      In the case of budget management, this requirement is evident.

   2. A system to manage the delegated authority must be established.
      It is possible that this is just another AAA server environment.
      This comes from the fact that one partner requires the presence of
      specific rules to be in the AAA server of another partner.  For
      example, the Faculty must be sure that certain checks are
      performed by the Educator's AAA server.

   3. AAA requests must either be evaluated at the AAA server queried or
      else parts of the request must be forwarded to another AAA server
      which can decide further on the request.  As such, it must be
      possible to build a network of AAA servers in which each makes the
      decisions it is authorized to make by the relationships among the
      entities, e.g., a request from the Educator to the Curriculum
      Commission may result in a request to the Student Administration.

   4. Transaction logs must be maintained to support non-repudiation for
      the grades of the students.  This recording should be time-stamped
      and allow signing by authorized entities.  A student should sign
      for taking an exam and this should be kept by the Educator's AAA





Vollbrecht, et al.           Informational                     [Page 46]

RFC 2905         AAA Authorization Application Examples      August 2000


      server.  After grading, the professor should be able to sign a
      grade and send it to the Student Administrator and the Student
      Administrator's AAA server should log and timestamp this event.

   5. Three types of AAA messages are required:

      -  authorization requests and responses for obtaining
         authorization,
      -  notification messages for accounting purposes, and
      -  information requests and responses for getting information
         regarding the correct construction of requests and for querying
         the database of notifications.

8.  Security Considerations

   The authorization applications discussed in this document are modeled
   on the framework presented in [2].  Security considerations relative
   to the authorization framework are discussed in [2].

   Specific security aspects of each authorization application presented
   in this document are discussed in the relevant section, above.

   Security aspects of the applications, themselves, are discussed in
   the references cited below.

Glossary

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

   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.




Vollbrecht, et al.           Informational                     [Page 47]

RFC 2905         AAA Authorization Application Examples      August 2000


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

   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
      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]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
        G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
        Authorization Framework", RFC 2904, August 2000.



Vollbrecht, et al.           Informational                     [Page 48]

RFC 2905         AAA Authorization Application Examples      August 2000


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

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
        Protocols", RFC 2477, January 1999.

   [6]  Beadles, Mark Anthony, and David Mitton, "Criteria for
        Evaluating Network Access Server Protocols", Work in Progress.

   [7]  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
        2486, January 1999.

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

   [9]  Calhoun, P. and G. Zorn, "Roamops Authentication/Authorization
        Requirements", Work in Progress.

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

   [11] Glass, Steven, et al, "Mobile IP Authentication, Authorization,
        and Accounting Requirements", Work in Progress.

   [12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for
        AAA", Work in Progress.

   [13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares,
        "A Discussion of Bandwidth Broker Requirements for Internet2
        Qbone Deployment", ver. 0.7, August 1999,
        http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf.

   [14] deBry, R., "Internet Printing Protocol/1.0: Model and
        Semantics", RFC 2566, April 1999.

   [15] Burdett, D., "Internet Open Trading Protocol - IOTP", RFC 2801,
        April 2000.

   [16] "SET Secure Electronic Transaction Specification Book 1:
        Business Description", Version 1.0, May 31, 1997,
        http://www.setco.org/download/set_bk1.pdf.






Vollbrecht, et al.           Informational                     [Page 49]

RFC 2905         AAA Authorization Application Examples      August 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
   EMail: 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


   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





Vollbrecht, et al.           Informational                     [Page 50]

RFC 2905         AAA Authorization Application Examples      August 2000


   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


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

   EMail: matt@ipverse.com












Vollbrecht, et al.           Informational                     [Page 51]

RFC 2905         AAA Authorization Application Examples      August 2000


   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 52]

RFC 2905         AAA Authorization Application Examples      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 53]