File: rfc2607.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 (843 lines) | stat: -rw-r--r-- 33,271 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






Network Working Group                                           B. Aboba
Request for Comments: 2607                         Microsoft Corporation
Category: Informational                                    J. Vollbrecht
                                                    Merit Networks, Inc.
                                                               June 1999


          Proxy Chaining and Policy Implementation in Roaming

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 (1999).  All Rights Reserved.

1.  Abstract

   This document describes how proxy chaining and policy implementation
   can be supported in roaming systems. The mechanisms described in this
   document are in current use.

   However, as noted in the security considerations section, the
   techniques outlined in this document are vulnerable to attack from
   external parties as well as susceptible to fraud perpetrated by the
   roaming partners themselves. As a result, such methods are not
   suitable for wide-scale deployment on the Internet.

2.  Terminology

   This document frequently uses the following terms:

   Network Access Server
      The Network Access Server (NAS) is the device that clients contact
      in order to get access to the network.

   RADIUS server
      This is a server which provides for authentication/authorization
      via the protocol described in [3], and for accounting as described
      in [4].








Aboba & Vollbrecht           Informational                      [Page 1]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


   RADIUS proxy
      In order to provide for the routing of RADIUS authentication and
      accounting requests, a RADIUS proxy can be employed. To the NAS,
      the RADIUS proxy appears to act as a RADIUS server, and to the
      RADIUS server, the proxy appears to act as a RADIUS client.

   Network Access Identifier
      In order to provide for the routing of RADIUS authentication and
      accounting requests, the userID field used in PPP (known as the
      Network Access Identifier or NAI) and in the subsequent RADIUS
      authentication and accounting requests, can contain structure.
      This structure provides a means by which the RADIUS proxy will
      locate the RADIUS server that is to receive the request. The NAI
      is defined in [6].

   Roaming relationships
      Roaming relationships include relationships between companies and
      ISPs, relationships among peer ISPs within a roaming association,
      and relationships between an ISP and a roaming consortia.
      Together, the set of relationships forming a path between a local
      ISP's authentication proxy and the home authentication server is
      known as the roaming relationship path.

3.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [5].

4.  Introduction

   Today, as described in [1], proxy chaining is widely deployed for the
   purposes of providing roaming services. In such systems,
   authentication/authorization and accounting packets are routed
   between a NAS device and a home server through a series of proxies.
   Consultation of the home server is required for password-based
   authentication, since the home server maintains the password database
   and thus it is necessary for the NAS to communicate with the home
   authentication server in order to verify the user's identity.












Aboba & Vollbrecht           Informational                      [Page 2]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


4.1.  Advantages of proxy chaining

   Proxies serve a number of functions in roaming, including:

   Scalability improvement
   Authentication forwarding
   Capabilities adjustment
   Policy implementation
   Accounting reliability improvement
   Atomic operation

   Scalability improvement
      In large scale roaming systems, it is necessary to provide for
      scalable management of keys used for integrity protection and
      authentication.

      Proxy chaining enables implementation of hierarchical
      forwarding within roaming systems, which improves scalability
      in roaming consortia based on authentication protocols without
      automated key management.  Since RADIUS as described in [3]
      requires a shared secret for each client-server pair, a
      consortium of 100 roaming partners would require 4950 shared
      secrets if each partner were to contact each other directly,
      one for each partner pair.  However, were the partners to
      route authentication requests through a central proxy, only
      100 shared secrets would be needed, one for each partner. The
      reduction in the number of partner pairs also brings with it
      other benefits, such as a reduction in the number of bilateral
      agreements and accounting and auditing overhead.  Thus,
      hierarchical routing might be desirable even if an
      authentiation protocol supporting automated key exchange were
      available.

   Capabilities adjustment
      As part of the authentication exchange with the home server,
      the NAS receives authorization parameters describing the
      service to be provided to the roaming user.  Since RADIUS,
      described in [3], does not support capabilities negotiation,
      it is possible that the authorization parameters sent by the
      home server will not match those required by the NAS. For
      example, a static IP address could be specified that would not
      be routable by the NAS. As a result, capbilities adjustment is
      performed by proxies in order to enable communication between
      NASes and home servers with very different feature sets.







Aboba & Vollbrecht           Informational                      [Page 3]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


      As part of capabilities adjustment, proxies can edit
      attributes within the Access-Accept in order to ensure
      compatibility with the NAS.  Such editing may include
      addition, deletion, or modification of attributes. In
      addition, in some cases it may be desirable for a proxy to
      edit attributes within an Access-Request in order to clean up
      or even hide information destined for the home server.  Note
      that if the proxy edits attributes within the Access-Accept,
      then it is possible that the service provided to the user may
      not be the same as that requested by the home server. This
      creates the possibility of disputes arising from inappropriate
      capabilities adjustment.

      Note that were roaming to be implemented based on an
      authentication/authorization protocol with built-in capability
      negotiation, proxy-based capabilities adjustment would
      probably not be necessary.

   Authentication forwarding
      Since roaming associations frequently implement hierarchical
      forwarding in order to improve scalability, in order for a NAS
      and home server to communicate, authentication and accounting
      packets are forwarded by one or more proxies. The path
      travelled by these packets, known as the roaming relationship
      path, is determined from the Network Access Identifier (NAI),
      described in [6]. Since most NAS devices do not implement
      forwarding logic, a proxy is needed to enable forwarding of
      authentication and accounting packets. For reasons that are
      described in the security section, in proxy systems it is
      desirable for accounting and authentication packets to follow
      the same path.

      Note: The way a proxy learns the mapping between NAI and the
      home server is  beyond  the  scope  of this document. This
      mapping can be accomplished by static configuration in the
      proxy, or by some currently undefined protocol that provides
      for dynamic mapping. For the purposes of this document, it is
      assumed that such a mapping capability exists in the proxy.

   Policy implementation
      In roaming systems it is often desirable to be able to
      implement policy. For example, a given partner may only be
      entitled to use of a given NAS during certain times of the
      day. In order to implement such policies, proxies may be
      implemented at the interface between administrative domains
      and programmed to modify authentication/authorization packets
      forwarded between the NAS and the home server. As a result,
      from a security point of view, a proxy implementing policy



Aboba & Vollbrecht           Informational                      [Page 4]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


      operates as a "man in the middle."

   Accounting reliability improvement
      In roaming systems based on proxy chaining, it is necessary
      for accounting information to be forwarded between the NAS and
      the home server. Thus roaming is inherently an interdomain
      application.

      This represents a problem since the RADIUS accounting
      protocol, described in [4] is not designed for use on an
      Internet scale.  Given that in roaming accounting packets
      travel between administrative domains, packets will often pass
      through network access points (NAPs) where packet loss may be
      substantial. This can result in unacceptable rates of
      accounting data loss.

      For example, in a proxy chaining system involving four
      systems, a one percent failure rate on each hop can result in
      loss of 3.9 percent of all accounting transactions. Placement
      of an accounting proxy near the NAS may improve reliability by
      enabling enabling persistent storage of accounting records and
      long duration retry.

   Atomic operation
      In order to ensure consistency among all parties required to
      process accounting data, it can be desirable to assure that
      transmission of accounting data is handled as an atomic
      operation. This implies that all parties on the roaming
      relationship path will receive and acknowledge the receipt of
      the accounting data for the operation to complete. Proxies can
      be used to ensure atomic delivery of accounting data by
      arranging for delivery of the accounting data in a serial
      fashion, as discussed in section 5.2.

5.  Proxy chaining

   An example of a proxy chaining system is shown below.

         (request)          (request)          (request)
     NAS ----------> Proxy1 ----------> Proxy2 ----------> Home
         (reply)            (reply)            (reply)     Server
         <---------         <---------         <---------

   In the above diagram, the NAS generates a request and sends it to
   Proxy1.  Proxy1 forwards the request to Proxy2 and Proxy2 forwards
   the request to the Home Server.  The Home Server generates a reply
   and sends it to Proxy2.  Proxy2 receives the reply, matches it with
   the request it had sent, and forwards a reply to Proxy1. Proxy1



Aboba & Vollbrecht           Informational                      [Page 5]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


   matches the reply with the request it sent earlier and forwards a
   reply to the NAS.  This model applies to all requests, including
   Access Requests and Accounting Requests.

   Except for the two cases described below, a proxy server such as
   Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1
   without first having received a Reply packet initiated by the Home
   Server.  The two exceptions are when the proxy is enforcing policy as
   described in section 5.1 and when the proxy is acting as an
   accounting store (as in store and forward), as described in section
   5.2.

   The RADIUS protocol described in [3] does not provide for end-to-end
   security services, including integrity or replay protection,
   authentication or confidentiality. As noted in the security
   considerations section, this omission results in several security
   problems within proxy chaining systems.

5.1.  Policy implementation

   Proxies are frequently used to implement policy in roaming
   situations.  Proxies implementing policy MAY reply directly to
   Access-Requests without forwarding the request. When replying
   directly to an Access-Request, the proxy MUST reply either with an
   Access-Reject or an Access-Challenge packet. A proxy MUST NOT reply
   directly with an Access-Accept.  An example of this would be when the
   proxy refuses all connections from a particular realm during prime
   time. In this case the home server will never receive th Access-
   Request.  This situation is shown below:

         (request)          (request)
     NAS ----------> Proxy1 ----------> Proxy2             Home
         (reply)            (reply)                        Server
         <---------         <---------

   A proxy MAY also decide to Reject a Request that has been accepted by
   the home server.  This could be based on the set of attributes
   returned by the home server.  In this case the Proxy SHOULD send an
   Access-Reject to the NAS and an Accounting-Request with Acct-Status-
   Type=Proxy-Stop (6) to the home server.  This lets the home server
   know that the session it approved has been denied downstream by the
   proxy.  However, a proxy MUST NOT send an Access-Accept after
   receiving an Access-Reject from a proxy or from the home server.








Aboba & Vollbrecht           Informational                      [Page 6]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


         (Access-Req)       (Access-Req)       (Access-Req)
     NAS ----------> Proxy1 ----------> Proxy2 ---------->     Home
         (Access-Reject)    (Access-Accept)    (Access-Accept) Server
         <---------         <---------         <---------
                            (AcctPxStop)       (AcctPxStop)
                            ---------->        ---------->

5.2.  Accounting behavior

   As described above, a proxy MUST NOT reply directly with an Access-
   Accept, and MUST NOT reply with an Access-Accept when it has received
   an Access-Reject from another proxy or Home Server. As a result, in
   all cases where an accounting record is to be generated (accepted
   sessions), no direct replies have occurred, and the Access-Request
   and Access-Accept have passed through the same set of systems.

   In order to allow proxies to match incoming Accounting-Requests with
   previously handled Access-Requests and Access-Accepts, a proxy SHOULD
   route the Accounting-Request along the same realm path travelled in
   authentication/authorization.  Note that this does not imply that
   accounting packets will necessarily travel the identical path,
   machine by machine, as did authentication/authorization packets.
   This is because it is conceivable that a proxy may have gone down,
   and as a result the Accounting-request may need to be forwarded to an
   alternate server. It is also conceivable that
   authentication/authorization and accounting may be handled by
   different servers within a realm.

   The Class attribute can be used to match Accounting Requests with
   prior Access Requests.  It can also be used to match session log
   records between the home Server, proxies, and NAS. This matching can
   be accomplished either in real-time (in the case that authentication
   and accounting packets follow the same path, machine by machine), or
   after the fact.

   Home servers SHOULD insert a unique session identifier in the Class
   attribute in an Access-Accept and Access-Challenge.  Proxies and
   NASes MUST forward the unmodified Class attribute.  The NAS MUST
   include the Class attribute in subsequent requests, in particular for
   Accounting-Requests. The sequence of events is shown below:











Aboba & Vollbrecht           Informational                      [Page 7]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


                      Authentication/Authorization

      -------->         -------->          --------->
 NAS            Proxy1              Proxy2             Home (add class)
     <-class--          <-class-           <-class--


                               Accounting

     (Accounting-req)   (Accounting-req)  (Accounting-req)
         w/class           w/class            w/class
  NAS ----------> Proxy1 ----------> Proxy2 ---------->       Home
      (Accounting-reply) (Accounting-reply)(Accounting-reply) Server
      <---------         <---------         <---------

   Since there is no need to implement policy in accounting, a proxy
   MUST forward all Accounting Requests to the next server on the path.
   The proxy MUST guarantee that the Accounting Request is received by
   the End Server and all intermediate servers.  The proxy may do this
   either by: 1) forwarding the Accounting Request and not sending a
   Reply until it receives the matching Reply from the upstream server,
   or 2) acting as a store point which takes responsibility for
   reforwarding the Accounting Request until it receives a Reply.

   Note that when the proxy does not send a reply until it receives a
   matching reply, this ensures that Accounting Start and Stop messages
   are received and can be logged by all servers along the roaming
   relationship path. If one of the servers is not available, then the
   operation will fail. As a result the entire accounting transaction
   will either succeed or fail as a unit, and thus can be said to be
   atomic.

   Where store and forward is implemented, it is possible that one or
   more servers along the roaming relationship path will not receive the
   accounting data while others will. The accounting operation will not
   succeed or fail as a unit, and is therefore not atomic.  As a result,
   it may not be possible for the roaming partners to reconcile their
   audit logs, opening new opportunities for fraud.  Where store and
   forward is implemented, forwarding of Accounting Requests SHOULD be
   done as they are received so the downstream servers will receive them
   in a timely way.

   Note that there are cases where a proxy will need to forward an
   Accounting packet to more than one system. For example, in order to
   allow for proper accounting in the case of a NAS that is shutting
   down, the proxy can send an Accounting-Request with Acct-Status-
   Type=Accounting-Off (8) to all realms that it forwards to.  In turn,
   these proxies will also flood the packet to their connected realms.



Aboba & Vollbrecht           Informational                      [Page 8]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


6.  References

   [1]  Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
        Roaming Implementations", RFC 2194, September 1997.

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

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

   [4]  Rigney, C., "RADIUS  Accounting", RFC 2139, April 1997.

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

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

7.  Security Considerations

   The RADIUS protocol described in [3] was designed for intra-domain
   use, where the NAS, proxy, and home server exist within a single
   administrative domain, and proxies may be considered a trusted
   component. However, in roaming the NAS, proxies, and home server will
   typically be managed by different administrative entities. As a
   result, roaming is inherently an inter-domain application, and
   proxies cannot necessarily be trusted.  This results in a number of
   security threats, including:

      Message editing
      Attribute editing
      Theft of passwords
      Theft and modification of accounting data
      Replay attacks
      Connection hijacking
      Fraudulent accounting

7.1.  Message editing

   Through the use of shared secrets it is possible for proxies
   operating in different domains to establish a trust relationship.
   However, if only hop-by-hop security is available then untrusted
   proxies are capable of perpetrating a number of man-in-the-middle
   attacks.  These include modification of messages.





Aboba & Vollbrecht           Informational                      [Page 9]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


   For example, an Access-Accept could be substituted for an Access-
   Reject, and without end-to-end integrity protection, there is no way
   for the NAS to detect this. On the home server, this will result in
   an accounting log entry for a session that was not authorized.
   However, if the proxy does not forward accounting packets or session
   records to the home server, then the home server will not be able to
   detect the discrepancy until a bill is received and audited.

   Note that a proxy can also send an Access-Reject to the NAS after
   receiving an Access-Accept from the home server. This will result in
   an authentication log entry without a corresponding accounting log
   entry.  Without the proxy sending an Accounting-Request with Acct-
   Status-Type=Proxy-Stop (6) to the home server, then there will be no
   way for the home server to determine whether the discrepancy is due
   to policy implementation or loss of accounting packets.  Thus the use
   of Acct-Status-Type=Proxy-Stop can be of value in debugging roaming
   systems.

   It should be noted that even if end-to-end security were to be
   available, a number of sticky questions would remain. While the end-
   points would be able to detect that the message from the home server
   had been modified by an intermediary, the question arises as to what
   action should be taken. While the modified packet could be silently
   discarded, this could affect the ability of the home server to .
   accept an Acct-Status-Type=Proxy-Stop message from an intermediate
   proxy. Since this message would not be signed by the NAS, it may need
   to be dropped by the home server.

   This is similar to the problem that IPSEC-capable systems face in
   making use of ICMP messages from systems with whom they do not have a
   security association. The problem is more difficult here, since in
   RADIUS retransmission is driven by the NAS.  Therefore the home
   server does not receive acknowledgement for Access-Accepts and thus
   would have no way of knowing that its response has not been honored.

7.2.  Attribute editing

   RADIUS as defined in [3] does not provide for end-to-end security or
   capabilities negotiation. As a result there is no way for a home
   server to securely negotiate a mutually acceptable configuration with
   the NAS or proxies. As a result, a number of attribute editing
   attacks are possible.

   For example, EAP attributes might be removed or modified so as to
   cause a client to authenticate with EAP MD5 or PAP, instead of a
   stronger authentication method. Alternatively, tunnel attributes
   might be removed or modified so as to remove encryption, redirect the
   tunnel to a rogue tunnel server, or otherwise lessen the security



Aboba & Vollbrecht           Informational                     [Page 10]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


   provided to the client.  The mismatch between requested and received
   services may only be detectable after the fact by comparing the
   Access-Accept attributes against the attributes included in the
   Accounting-Request. However, without end-to-end security services, it
   is possible for a rogue proxy to cover its tracks.

   Due to the complexity of proxy configuration, such attacks need not
   involve malice, but can occur due to mis-configuration or
   implementation deficiencies.  Today several proxy implementations
   remove attributes that they do not understand, or can be set up to
   replace attribute sets sent in the Access-Accept with sets of
   attributes appropriate for a particular NAS.

   In practice, it is not possible to define a set of guidelines for
   attribute editing, since the requirements are very often
   implementation-specific. At the same time, protection against
   inappropriate attribute editing is necessary to guard against attacks
   and provide assurance that users are provisioned as directed by the
   home server.

   Since it is not possible to determine beforehand whether a given
   attribute is editable or not, a mechanism needs to be provided to
   allow senders to indicate which attributes are editable and which are
   not, and for the receivers to detect modifications of "non-editable"
   attributes.  Through implementation of end-to-end security it may be
   possible to detect unauthorized addition, deletion, or modification
   of integrity-protected attributes. However, it would still possible
   for a rogue proxy to add, delete or modify attributes that are not
   integrity-protected. If such attributes influence subsequent charges,
   then the possibility of fraud would remain.

7.3.  Theft of passwords

   RADIUS as defined in [3] does not provide for end-to-end
   confidentiality. As a result, where clients authenticate using PAP,
   each proxy along the path between the local NAS and the home server
   will have access to the cleartext password. In many circumstances,
   this represents an unacceptable security risk.

7.4.  Theft and modification of accounting data

   Typically in roaming systems, accounting packets are provided to all
   the participants along the roaming relationship path, in order to
   allow them to audit subsequent invoices. RADIUS as described in [3]
   does not provide for end-to-end security services, including
   integrity protection or confidentiality. Without end-to-end integrity
   protection, it is possible for proxies to modify accounting packets
   or session records.  Without end-to-end confidentiality, accounting



Aboba & Vollbrecht           Informational                     [Page 11]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


   data will be accessible to proxies.  However, if the objective is
   merely to prevent snooping of accounting data on the wire, then IPSEC
   ESP can be used.

7.5.  Replay attacks

   In this attack, a man in the middle or rogue proxy collects CHAP-
   Challenge and CHAP-Response attributes, and later replays them. If
   this attack is performed in collaboration with an unscrupulous ISP,
   it can be used to subsequently submit fraudulent accounting records
   for payment.  The system performing the replay need not necessarily
   be the one that initially captured the CHAP Challenge/Response pair.

   While RADIUS as described in [3] is vulnerable to replay attacks,
   without roaming the threat is restricted to proxies operating in the
   home server's domain. With roaming, such an attack can be mounted by
   any proxy capable of reaching the home server.

7.6.  Connection hijacking

   In this form of attack, the attacker attempts to inject packets into
   the conversation between the NAS and the home server. RADIUS as
   described in [3] is vulnerable to such attacks since only Access-
   Reply and Access-Challenge packets are authenticated.

7.7.  Fraudulent accounting

   In this form of attack, a local proxy transmits fraudulent accounting
   packets or session records in an effort to collect fees to which they
   are not entitled. This includes submission of packets or session
   records for non-existent sessions. Since in RADIUS as described in
   [3], there is no end-to-end security, a rogue proxy may insert or
   edit packets without fear of detection.

   In order to detect submissions of accounting packets or session
   records for non-existent sessions, parties receiving accounting
   packets or session records would be prudent to reconcile them with
   the authentication logs. Such reconciliation is only typically
   possible when the party acts as an authentication proxy for all
   sessions for which an accounting record will subsequently be
   submitted.

   In order to make reconciliation easier, home servers involved in
   roaming include a Class attribute in the Access-Accept.  The Class
   attribute uniquely identifies a session, so as to allow an
   authentication log entry to be matched with a corresponding
   accounting packet or session record.




Aboba & Vollbrecht           Informational                     [Page 12]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


   If reconciliation is put in place and all accounting log entries
   without a corresponding authentication are rejected, then the
   attacker will need to have obtained a valid user password prior to
   submitting accounting packets or session records on non-existent
   sessions. While use of end-to-end security can defeat unauthorized
   injection or editing of accounting or authentication packets by
   intermediate proxies, other attacks remain feasible. For example,
   unless replay protection is put in place, it is still feasible for an
   intermediate proxy to resubmit authentication or accounting packets
   or session records. In addition, end-to-end security does not provide
   protection against attacks by the local proxy, since this is
   typically where end-to-end security will be initiated. To detect such
   attacks, other measures need to be put in place, such as systems for
   detecting unusual activity of ISP or user accounts, or for
   determining whether a user or ISP account is within their credit
   limit.

   Note that implementation of the store and forward approach to proxy
   accounting makes it possible for some systems in the roaming
   relationship path to receive accounting records that other systems do
   not get. This can result in audit discrepancies. About the best that
   is achievable in such cases is to verify that the accounting data is
   missing by checking against the authentication logs.

8.  Acknowledgments

   Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of
   CompuServe, Aydin Edguer of Morningstar, Bill Bulley of Merit, and
   Steven P. Crain of Shore.Net for useful discussions of this problem
   space.





















Aboba & Vollbrecht           Informational                     [Page 13]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


9.  Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 425-936-6605
   EMail: bernarda@microsoft.com


   John R. Vollbrecht
   Merit Network, Inc.
   4251 Plymouth Rd.
   Ann Arbor, MI 48105-2785

   Phone: 313-763-1206
   EMail: jrv@merit.edu

































Aboba & Vollbrecht           Informational                     [Page 14]

RFC 2607          Proxy Chaining and Policy in Roaming         June 1999


10.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.



















Aboba & Vollbrecht           Informational                     [Page 15]