ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     Category: Best Current Practice                     John R. Vollbrecht
     <draft-ietf-roamops-auth-03.txt>                  Merit Networks, Inc.
     8 September 1997                                             Glen Zorn
                                                                  Microsoft
     
     
           Guidelines for the Operation of RADIUS Proxies in Roaming
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as "work in progress."
     
     To  learn  the  current status of any Internet-Draft, please check the
     "1id-abstracts.txt" listing contained in  the  Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-roamops-auth-03.txt>, and  expires March 1,  1998.   Please  send
     comments to the authors.
     
     
     2.  Abstract
     
     Today, while RADIUS proxy chaining is widely deployed for the purposes
     of providing roaming services, interoperation between roaming  systems
     is  difficult.  This document provides guidelines for the operation of
     RADIUS proxies within roaming systems.
     
     
     3.  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/autho-
               rization via the protocol described in [3], and for account-
               ing as described in [4].
     
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 1]


     INTERNET-DRAFT                                        8 September 1997
     
     
     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 subse-
               quent 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.
     
     Roaming relationships
               Roaming  relationships  include relationships between compa-
               nies and ISPs, relationships among peer ISPs within a  roam-
               ing  association,  and  relationships  between  an ISP and a
               roaming consortia. Together, the set of relationships  form-
               ing  a  path  between a local ISP's authentication proxy and
               the home authentication server is known as the roaming rela-
               tionship path.
     
     
     4.  Requirements language
     
     This specification uses the same words as [8] for defining the signif-
     icance of each particular requirement.  These words are:
     
     
     MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
               that the definition is an absolute requirement of the speci-
               fication.
     
     MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
               nition is an absolute prohibition of the specification.
     
     SHOULD    This  word, or the adjective "RECOMMENDED", means that there
               may exist  valid  reasons  in  particular  circumstances  to
               ignore  a particular item, but the full implications must be
               understood and carefully weighed before choosing a different
               course.
     
     SHOULD NOT
               This phrase means that there may exist valid reasons in par-
               ticular  circumstances  when  the  particular  behavior   is
               acceptable  or even useful, but the full implications should
               be understood and the case carefully weighed  before  imple-
               menting any behavior described with this label.
     
     MAY       This  word,  or the adjective "OPTIONAL", means that an item
               is truly optional.  One vendor may  choose  to  include  the
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 2]


     INTERNET-DRAFT                                        8 September 1997
     
     
               item because a particular marketplace requires it or because
               the vendor feels that it enhances the product while  another
               vendor may omit the same item.  An implementation which does
               not include a particular option MUST be prepared to interop-
               erate  with  another  implementation  which does include the
               option, though perhaps with reduced  functionality.  In  the
               same  vein an implementation which does include a particular
               option MUST be prepared to interoperate with another  imple-
               mentation  which  does  not  include  the option.(except, of
               course, for the feature the option provides)
     
     An implementation is not compliant if it fails to satisfy one or  more
     of  the must or must not requirements for the protocols it implements.
     An implementation that satisfies all the must, must  not,  should  and
     should  not requirements for its protocols is said to be "uncondition-
     ally compliant"; one that satisfies all the must and must not require-
     ments but not all the should or should not requirements for its proto-
     cols is said to be "conditionally compliant."
     
     
     5.  Introduction
     
     Today, as described in [1], RADIUS proxy chaining is  widely  deployed
     for  the  purposes  of  providing  roaming  services. In such systems,
     RADIUS authentication and accounting packets are routed between a  NAS
     device  and  a  home RADIUS server through a series of RADIUS proxies.
     The purpose of this document is to provide guidelines for  the  opera-
     tion of such systems.
     
     An example of a proxy chaining system is shown below.
     
           (request)          (request)          (request)
       NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS
           (reply)            (reply)            (reply)     Server
           <---------         <---------         <---------
     
     In  the above diagram, the NAS generates a RADIUS 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 matches
     the reply with the request it sent earlier and forwards a reply to the
     NAS.   This  model  applies  to  all RADIUS requests, including Access
     Requests and Accounting Requests. Except where policy is being  imple-
     mented (described below), a proxy server such as Proxy2 in the diagram
     below SHOULD NOT send a Reply packet to Proxy1  without  first  having
     received a Reply packet initiated by the home RADIUS server.
     
     While  the  RADIUS  protocol  described  in   [3] does not provide for
     authentication of Access-Requests,  such  authentication  is  possible
     using the Signature attribute described in [5]. Proxies SHOULD include
     the Signature attribute in Access-Requests. Since the RADIUS protocol,
     described in [3], does support authentication of Access-Reply packets,
     the Signature attribute is not required in an Access-Reply.
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 3]


     INTERNET-DRAFT                                        8 September 1997
     
     
     5.1.  Route determination
     
     In RADIUS proxy chaining, the forwarding function is carried out based
     on  the  realm portion of the Network Access Identifier (NAI), defined
     in [9]. While the mechanism by which the path is selected is implemen-
     tation  dependent,  existing implementations typically use static for-
     warding tables set in their configuration files.
     
     If source routing  is  desired,  a  local  proxy  may  use  the  Route
     attribute  described in [10] to define a loose or strict source route.
     Intermediate proxies that cannot honor  the  loose  or  strict  source
     route  request  SHOULD  send an Access-Reject to the upstream proxy or
     NAS and an Accounting message with Acct-Status-Type=Proxy-Stop to  the
     Home Server.
     
     If  a traceroute is desired, a local proxy may use the Route attribute
     described in [10] to request a traceroute be performed. Through use of
     multiple  Route attributes, a traceroute may be performed along with a
     loose source route request.
     
     Note that in forwarding an Access-Request, a proxy may choose to route
     a  request  through an alternate realm if the proxies for a downstream
     realm are not available. In the case where  alternate  routes  may  be
     chosen,  a  traceroute  request  SHOULD be included within the Access-
     Request. On receiving an Access-Request containing a  traceroute,  the
     home  server  SHOULD  respond with an Access-Reply containing a strict
     source-route request, with the strict source-route set  to  the  route
     contained  in  the  traceroute.  This ensures that the Access-Reply is
     sent back over the same  path  travelled  by  the  Access-Request.  On
     receiving  an  Access-Accept  containing a traceroute or source-route,
     the local proxy SHOULD  include  a  source-route  request  within  the
     Accounting-request  for  that  session.  This  will  ensure  that  the
     Accounting-request will follow the same realm path as did the  Access-
     Request and Access-Accept.
     
     
     5.2.  Policy implementation
     
     RADIUS proxies are frequently used to implement policy in roaming sit-
     uations. RADIUS 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 RADIUS 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  the  Access-
     Request. This situation is shown below:
     
     
           (request)          (request)
       NAS ----------> Proxy1 ----------> Proxy2             Home RADIUS
           (reply)            (reply)                        Server
           <---------         <---------
     
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 4]


     INTERNET-DRAFT                                        8 September 1997
     
     
     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 message  with  Acct-Status-
     Type=Proxy-Stop  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.
     
     
           (Access-Req)       (Access-Req)       (Access-Req)
       NAS ----------> Proxy1 ----------> Proxy2 ---------->     Home RADIUS
           (Access-Reject)    (Access-Accept)    (Access-Accept) Server
           <---------         <---------         <---------
                              (AcctPxStop)       (AcctPxStop)
                              ---------->        ---------->
     
     
     5.3.  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 ses-
     sions), 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 as did
     authentication/authorization packets,  machine  by  machine.  This  is
     because  it is conceivable that a RADIUS 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/autho-
     rization 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 Class attribute.  The  NAS  MUST  include  the  Class
     attribute  in  subsequent  requests,  in  particular  for  Accounting-
     Requests. The sequence of events is shown below:
     
     Authentication/Authorization
     
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 5]


     INTERNET-DRAFT                                        8 September 1997
     
     
           -------->         -------->          --------->
      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 RADIUS
           (Accounting-reply) (Accounting-reply)(Accounting-reply) Server
           <---------         <---------         <---------
     
     Since there is no need to implement policy  in  RADIUS  accounting,  a
     proxy  SHOULD  NOT  reply directly to Accounting-Requests, and a proxy
     server such as Proxy2 in the diagram below SHOULD NOT send an Account-
     ing-Reply  packet  to Proxy1 without first having received an Account-
     ing-Reply packet initiated by the home  RADIUS  server.  This  ensures
     when  a  NAS  receives an Accounting-Reply the Accounting-Request will
     have been received by all systems along the  authentication/authoriza-
     tion path.
     
     Note  that  there  are  cases  where  a  proxy  may 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 may need to send an Accounting-Request with  Acct-Sta-
     tus-Type=Accounting-Off  to  all  realms that it forwards to. In turn,
     these proxies will also flood the packet to their connected realms.
     
     
     6.  Allowable editing behavior
     
     One of the  biggest  obstacles  to  interoperation  of  proxies  today
     results  from  editing  behavior.  As  roaming  grows  in  popularity,
     attribute editing problems are becoming common.
     
     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
     network.  In  order  to  prevent  inappropriate modification of RADIUS
     attributes this document  describes  what  attributes  may  be  added,
     edited,  deleted,  or processed by authentication and accounting prox-
     ies.
     
     A local proxy (a proxy downstream from  a  NAS)  MAY  edit  or  delete
     attributes within Access-Requests, as described in the table below. An
     intermediate proxy (a proxy downstream from another proxy) SHOULD  NOT
     edit or delete attributes when forwarding Access-Requests.
     
     Local proxies MAY edit or delete attributes in an Access-Reply, if the
     downstream server is a  NAS  which  is  not  able  to  interpret  some
     attributes,  and if the attributes are marked with edit or delete per-
     mission in the table below. If edit or delete permission is not  indi-
     cated,  then  if a NAS is not able to interpret these attributes, then
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 6]


     INTERNET-DRAFT                                        8 September 1997
     
     
     the proxy SHOULD send an Access-Reject to the NAS  and  an  Accounting
     message  with Acct-Status-Type=Proxy-Stop to the home server. Interme-
     diate proxies SHOULD NOT edit or delete attributes in an Access-Reply.
     
     A  local  Proxy  may  need to translate some attributes in the Access-
     Accept to support a particular service. For example, translation could
     be  done  to support a common set of IP filters on NASs from different
     vendors. However, translation should be done only to support a  common
     service. Intermediate proxies SHOULD NOT translate attributes.
     
     Local  or  intermediate  proxies MAY interpret attributes they receive
     and MAY add attributes to Access-Request,  Access-Reply,  Access-Chal-
     lenge, and Accounting-Request messages, as noted in the table below. A
     Proxy that adds attributes MUST precede the additional attributes with
     a  "Proxy-State"  attribute  containing  as its leading string the IP-
     Address of the Proxy. This permits downstream  proxies  to  understand
     what  attributes  have  been added and aids in debugging. Proxies MUST
     maintain attribute order when forwarding.
     
     An intermediate proxy SHOULD NOT  edit  or  delete  attributes  within
     Accounting-Requests.  A  local  proxy  MAY  edit  or delete attributes
     within Accounting-Requests, as described in the table below.  However,
     since  proxies  will  already  have  had  the  opportunity to edit the
     attributes while forwarding authentication/authorization packets,  the
     attributes  sent  in the Accounting-Request reflect the actual parame-
     ters in effect for the session. As a result, the intermediate proxy or
     the  home  server MAY wish to match the attributes sent in the Access-
     Request, Access-Challenge,  or  Access-Accept  against  those  in  the
     Accounting-Request  in  order  to  generate  an  audit trail or aid in
     debugging. In order to support the auditing and debugging process, the
     scope  for editing or deletion of attributes in Accounting-Requests is
     reduced.
     
                  AUTHENTICATION
     
     Request   Accept   Reject   Challenge   #    Attribute
     E                           A            1   User-Name [note 1]
     PD                                       2   User-Password [note 2]
     A                                        3   CHAP-Password [note 2]
     AED                                      4   NAS-IP-Address [note 4]
     AE                                       5   NAS-Port
     AE        AE                             6   Service-Type
     AE        AE                             7   Framed-Protocol
     AE        AE                             8   Framed-IP-Address
     AE        AE                             9   Framed-IP-Netmask
               AED                           10   Framed-Routing
               AE                            11   Filter-Id [note 5]
               AE                            12   Framed-MTU
     AE        AE                            13   Framed-Compression
     AE        AE                            14   Login-IP-Host
               AE                            15   Login-Service
               AE                            16   Login-TCP-Port
               AE       AE       AE          18   Reply-Message
     AE        AE                            19   Callback-Number [note 3]
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 7]


     INTERNET-DRAFT                                        8 September 1997
     
     
               A                             20   Callback-Id
               AED                           22   Framed-Route
               AED                           23   Framed-IPX-Network
     AE        AE                AE          24   State
               AE                            25   Class
     AED       AED               AED         26   Vendor-Specific
               AE                AE          27   Session-Timeout
               AE                AE          28   Idle-Timeout
               AE                            29   Termination-Action
     AE                                      30   Called-Station-Id [note 3]
     AE                                      31   Calling-Station-Id [note 3]
     AE                                      32   NAS-Identifier [note 4]
     AP        AP       AP       AP          33   Proxy-State
     AE        AE                            34   Login-LAT-Service
     AE        AE                            35   Login-LAT-Node
     AE        AE                            36   Login-LAT-Group
               AE                            37   Framed-AppleTalk-Link
               AED                           38   Framed-AppleTalk-Network
               AED                           39   Framed-AppleTalk-Zone
                                             60   CHAP-Challenge
     AE                                      61   NAS-Port-Type
     AE        AE                            62   Port-Limit
     AE        AE                            63   Login-LAT-Port
                                             64   Tunnel-Type
                                             65   Tunnel-Medium-Type
                                             67   Tunnel-Server-Endpoint
               P                             69   Tunnel-Password
     AP                                      70   ARAP-Password
               AE                AE          71   ARAP-Features
               AE                            72   ARAP-Zone-Access
     A                           A           73   ARAP-Security
     A                           A           74   ARAP-Security-Data
                        ED                   75   Password-Retry
                                 AE          76   Prompt
                                             77   Connect-Info
               AED                           78   Configuration-Token
                                             79   EAP-Message
     AP                                      80   Signature
     P         P        P        P            ?   Route
               ED                             ?   Acct-Interim-Interval
     Request   Accept   Reject   Challenge   #    Attribute
     
     The following table defines the meaning of the entries above.
     
     A     This attribute MAY be added
     E     This attribute MAY be edited. Editing is defined as a change
           beyond that required in hop-by-hop processing as described
           in [3]-[5].
     D     This attribute MAY be deleted.
     P     This attribute MUST be processed as described in [3]-[5].
     
     Notes
     
     1. A proxy may strip the realm from the User-Name, so  as  to  provide
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 8]


     INTERNET-DRAFT                                        8 September 1997
     
     
     compatibility with proxies that cannot handle this.
     
     2.  Use of PAP is considered undesirable in roaming, since each RADIUS
     proxy handling the Access-Request will have access  to  the  cleartext
     password.  As  a result, if the user uses PAP to authenticate with the
     NAS, and the NAS sends the User-Password to the proxy (secure network)
     the  proxy MAY convert it to CHAP before sending it to the home server
     (insecure network). In some situations this would be desirable  (fewer
     proxies  would have access to the password), and in others it would be
     undesirable (the home NAS has no way to know that it was only PAP that
     was done).
     
     3.  A  proxy may edit these attributes in order to make them more spe-
     cific. For example, the proxy might need to change  Callback-Number  =
     "7771111" to Callback-Number = "5107771111".
     
     4.  A local proxy may replace the NAS-IP-Address attribute with a NAS-
     Identifier attribute in order to releave other proxies or  servers  of
     the need to understand the underlying network topology, making it eas-
     ier for those proxies to make a decision whether to permit the Access-
     Request.  For example, a local proxy might replace a NAS-IP-Address of
     128.10.13.1 with a NAS-Identifier of "BIG ISP NAS 1."
     
     5. Editing of the Filter-Id attribute may  be  undertaken  only  by  a
     local proxy, in order to provide a common filter service between NASes
     of different types.
     
            ACCOUNTING
     
     Request      Reply         #    Attribute
                                1   User-Name
                                2   User-Password
                                3   CHAP-Password
     AED                        4   NAS-IP-Address
     AE                         5   NAS-Port
     A                          6   Service-Type
     A                          7   Framed-Protocol
     A                          8   Framed-IP-Address
     A                          9   Framed-IP-Netmask
     A                         10   Framed-Routing
     A                         11   Filter-Id
     A                         12   Framed-MTU
     A                         13   Framed-Compression
     A                         14   Login-IP-Host
     A                         15   Login-Service
     A                         16   Login-TCP-Port
                               18   Reply-Message
     AE                        19   Callback-Number [note 3]
     A                         20   Callback-Id
     A                         22   Framed-Route
     A                         23   Framed-IPX-Network
                               24   State
     A                         25   Class
     A                         26   Vendor-Specific
     
     
     
     Aboba, Vollbrecht & Zorn                                      [Page 9]


     INTERNET-DRAFT                                        8 September 1997
     
     
     A                         27   Session-Timeout
     A                         28   Idle-Timeout
     A                         29   Termination-Action
     AE                        30   Called-Station-Id [note 3]
     AE                        31   Calling-Station-Id [note 3]
     AED                       32   NAS-Identifier
     AP                        33   Proxy-State
     A                         34   Login-LAT-Service
     A                         35   Login-LAT-Node
     A                         36   Login-LAT-Group
     A                         37   Framed-AppleTalk-Link
     A                         38   Framed-AppleTalk-Network
     A                         39   Framed-AppleTalk-Zone
                               40   Acct-Status-Type
                               41   Acct-Delay-Time [note 1]
                               42   Acct-Input-Octets
                               43   Acct-Output-Octets
     E                         44   Acct-Session-Id [note 2]
                               45   Acct-Authentic
                               46   Acct-Session-Time
                               47   Acct-Input-Packets
                               48   Acct-Output-Packets
                               49   Acct-Terminate-Cause
     E                         50   Acct-Multi-Session-Id [note 2]
                               51   Acct-Link-Count
                               60   CHAP-Challenge
     A                         61   NAS-Port-Type
     A                         62   Port-Limit
     A                         63   Login-LAT-Port
                               64   Tunnel-Type
                               65   Tunnel-Medium-Type
                               66   Acct-Tunnel-Client-Endpoint
                               67   Tunnel-Server-Endpoint
                               68   Acct-Tunnel-Connection-ID
                               69   Tunnel-Password
                               70   ARAP-Password
     A                         71   ARAP-Features
     A                         72   ARAP-Zone-Access
     A                         73   ARAP-Security
     A                         74   ARAP-Security-Data
                               75   Password-Retry
                               76   Prompt
                               77   Connect-Info
                               78   Configuration-Token
                               79   EAP-Message
     80 Signature
     P           P              ?   Route
     A                          ?   Acct-Interim-Interval
     Accounting  Accounting
     Request      Reply         #    Attribute
     
     1. If the proxy can calculate the additional delay it is  introducing,
     it should increment this.
     
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 10]


     INTERNET-DRAFT                                        8 September 1997
     
     
     2. The proxy may need to modify the NAS identification to hide private
     network information.  In that case, it may forward packets with itself
     as  the  NAS,  and  will  need to construct an Acct-Session-Id that is
     guaranteed to be unique. For example, if the proxy gets  packets  from
     16 NASs, session '3478617' on the 11th NAS might be given the new ses-
     sion ID 'A3478617'.
     
     3. A proxy may edit these attributes in order to make them  more  spe-
     cific.  For  example, the proxy might need to change Callback-Number =
     "7771111" to Callback-Number = "5107771111".
     
     
     
     7.  Security issues
     
     Since current roaming implementations operate in more than  150  coun-
     tries  and service millions of users, it is critical that RADIUS proxy
     chaining implementations be secure. In particular, protection must  be
     provided against the following attacks:
     
        Rogue proxies
        Theft of passwords
        Theft of accounting data
        Replay attacks
        Attribute editing
        Connection hijacking
        Authentication routing attacks
        Fraudulent accounting
     
     
     7.1.  Rogue proxies
     
     In  conventional  ISP  application,  the NAS, RADIUS proxy, and RADIUS
     server typically exist within a single  administrative  entity.  As  a
     result,  the  RADUS  proxy  and  RADIUS server may be considered to be
     trusted components.
     
     However, in a roaming system implemented with proxy chaining, the NAS,
     RADIUS proxies, and RADIUS server may be managed by different adminis-
     trative entities. Through the use of shared secrets it is possible for
     RADIUS  proxies  operating  in  different domains to establish a trust
     relationship. However, since RADIUS packets are only authenticated  on
     a hop-by-hop basis, proxy chaining systems deployed in roaming operate
     without end-to-end authentication. This means  that  in  such  systems
     security is only as strong as the weakest link in the proxy chain.
     
     Among  other  things,  this  implies  that it is advisable to keep the
     chain as short as possible. To date, as  described  in  [1],  existing
     roaming  implementations have been limited in scale, forwarding RADIUS
     packets over a maximum of two hops, or  implementing  star  configura-
     tions  with  all  systems  connecting to a single trusted entity. Such
     configurations minimize trust issues.
     
     
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 11]


     INTERNET-DRAFT                                        8 September 1997
     
     
     Through use of the Route attribute described above, it is possible for
     a RADIUS proxy or server to decide whether it wishes to trust a packet
     arriving via a particular route. Since it is the receiving proxy  that
     adds  the  previous  hop to the route, without collusion a rogue proxy
     cannot avoid having itself listed in the route, although it  can  add,
     delete, or alter prior entries.
     
     A  proxy  or server may decide not to trust any route including a par-
     ticular system or set of systems as an intermediate proxy,  or  as  an
     originating or terminating system.
     
     
     7.2.  Theft of passwords
     
     In  the  case  where clients authenticate using PAP, each RADIUS proxy
     along the path between the local NAS and the home RADIUS  server  will
     have  access  to  the  cleartext password. In many circumstances, this
     represents an unacceptable security risk, and as a result, it is  rec-
     ommended  that PAP SHOULD NOT be used in roaming. A possible exception
     to this recommendation occurs in situations where PAP is used in order
     to pass a one time password or token.
     
     
     7.3.  Theft of accounting data
     
     Since  RADIUS accounting does not provide for encryption of accounting
     data, when real-time accounting is used, it is possible for an  inter-
     mediate  system  to gain access to accounting information passing over
     the wire. Such access may or may not be possible when  session  record
     accounting  is  used,  depending  on whether encryption is used in the
     accounting record transfer.
     
     
     7.4.  Replay attacks
     
     In this attack, a man in the middle or  rogue  RADIUS  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 to
     the accounting agent for payment.  The system  performing  the  replay
     need not necessarily be the one that initially captured the CHAP Chal-
     lenge/Response pair.
     
     While such an attack has always been  possible,  without  roaming  the
     threat  is restricted to RADIUS proxies operating in the home server's
     domain. With roaming, such an attack can  be  mounted  by  any  RADIUS
     proxy capable of reaching the home RADIUS server.
     
     In  order  to  detect  replay  attacks, RADIUS servers used in roaming
     SHOULD keep a log of CHAP challenges, so as to allow  the  log  to  be
     checked for replays.
     
     CHAP  replay  attacks  can be defeated by means of an end-to-end chal-
     lenge-response exchange.  For  example,  if  the  home  RADIUS  server
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 12]


     INTERNET-DRAFT                                        8 September 1997
     
     
     returns   an   Access-Challenge  packet  containing  a  CHAP-Challenge
     attribute and maintains state with respect to outstanding  challenges,
     replay attacks will not work.
     
     However,  it should also be noted that end-to-end challenges (as prac-
     ticed within the EAP MD5 authentication method, or in  the  CHAP-Chal-
     lenge  method  described above) are subject to attacks by rogue RADIUS
     proxies. In such an attack a RADIUS proxy substitutes a  static  chal-
     lenge for the challenge sent by the home RADIUS server, and on receiv-
     ing the response, checks it against  a  databases  of  hashes  applied
     against a dictionary.
     
     Use of the CHAP and PAP authentication methods may be avoided entirely
     by instructing the PPP authenticating peer to refuse these authentica-
     tion methods if offered.
     
     
     7.5.  Attribute editing
     
     In  this  attack, a RADIUS proxy modifies an Access-Accept sent by the
     RADIUS server so as to lessen the security obtained by the client. 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 provided to
     the client.
     
     Since RADIUS only provides for hop-by-hop authentication,  it  is  not
     possible  to provide end-to-end integrity checks within proxy chaining
     systems. However, in order to provide for detection  of  inappropriate
     attribute editing, local RADIUS proxies and home RADIUS servers SHOULD
     implement auditing functionality.
     
     For example, the local RADIUS proxy SHOULD include  RADIUS  attributes
     received in the Access-Accept within the session record or Accounting-
     Start message for the session.  Similarly, home RADIUS servers  SHOULD
     log  the  contents  of RADIUS Access-Replies sent, and SHOULD periodi-
     cally check  for  discrepancies  between  attributes  sent  in  RADIUS
     Access-Replies, and attributes received by local proxies.
     
     Proxy Servers that modify or add attributes in any RADIUS Request MUST
     log the Request as received and as modified in order to make it possi-
     ble to audit requests in both directions.
     
     In  order to allow for detection of modification of accounting packets
     by intermediate proxies, roaming consortia may  implement  both  real-
     time  and  session  record  accounting.  In this case, session records
     SHOULD NOT travel the same path taken by  RADIUS  accounting  packets.
     Instead,  session  records  SHOULD  be sent directly between the local
     proxy and the systems requiring copies of the session records.
     
     
     
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 13]


     INTERNET-DRAFT                                        8 September 1997
     
     
     7.6.  Connection hijacking
     
     In this form of attack, the attacker attempts to inject  packets  into
     the conversation between the NAS and the home RADIUS server. RADIUS as
     described in [3] is vulnerable to such attacks since only Access-Reply
     and Access-Challenge packets are authenticated.
     
     In  order  to  provide  for  authentication of Access-Request packets,
     RADIUS proxies operating in roaming systems MUST support the Signature
     attribute,  as  decribed in [9]. RADIUS proxies used in roaming imple-
     mentations MUST check for the presence of the Signature  attribute  in
     Access-Requests  forwarded  to  them  from  other  proxies,  and  MUST
     silently  discard  Access-Request  packets   missing   the   Signature
     attribute or failing authentication. RADIUS proxies operating in roam-
     ing systems also MUST include a Signature attribute in  all  forwarded
     Access-Request packets.
     
     
     7.7.  Authentication routing attacks
     
     In  roaming,  one  of  the  functions  of the RADIUS proxy is to route
     authentications  between  domains.   Authentication  routing   attacks
     affect  the core of a roaming system by modifying authentication rout-
     ing information, thus disabling the system or causing  RADIUS  packets
     to be routed inappropriately.
     
     Since  to  date  roaming  has  been  implemented on a relatively small
     scale, existing implementations perform authentication  routing  based
     on  local  knowledge  expressed  in proxy configuration files. To date
     implementations have not found a need for dynamic  routing  protocols,
     or propagation of global routing information.
     
     Since  authentication routing information is fundamental to the opera-
     tional of a roaming system, routing information SHOULD  be  propagated
     using  an  transfer  method  supporting mutual authentication, such as
     Kerberized rcp, SSH or TLS.
     
     Since all RADIUS packets used in  roaming  are  secured  by  a  shared
     secret,  such attacks will not rsult in more than a denial of service,
     as long as the attacker did not also obtain the shared secrets.
     
     As with attribute editing, it is expected that most problems  of  this
     type  will result from misconfiguration of RADIUS proxies. In order to
     detect such misconfigurations, RADIUS proxies participating in roaming
     MUST   implement  the  Route  attribute  described  below.  The  Route
     attribute provides trace route and/or source route capabilities.  This
     allows  a  local  RADIUS  proxy  to  specify  a route through which an
     Access-Request must travel, or for a home RADIUS server  to  determine
     whether  to  authorize Access-Requests routed on a given roaming rela-
     tionship path.
     
     A RADIUS proxy receiving a Route attribute with the Trace  option  set
     MUST append the domain of the system from which it received the packet
     to the end of the Route attribute prior to forwarding it.
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 14]


     INTERNET-DRAFT                                        8 September 1997
     
     
     7.8.  Fraudulent accounting
     
     In this form of attack, a  local  RADIUS  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, or submission of exagger-
     ated session times for actual sessions.  Such behavior  will  only  be
     easily  detectable  in  the event that roaming users are making use of
     voluntary or compulsory tunneling, in which  case  the  tunnel  server
     (presumed  to exist at BIGCO) will generate its own accounting record,
     which may be compared to that generated by  the  local  ISP.  However,
     tunneling  is expected to represent only a small percentage of roaming
     use.
     
     In order to detect submission of fraudulent accounting packets or ses-
     sion records, the the accounting gateway SHOULD send copies of session
     records to all parties with a financial interest in the session.  Par-
     ties  receiving  copies of these session records SHOULD reconcile them
     with logs of proxied authentications.
     
     In order to make it easier to match RADIUS  authentication  logs  with
     accounting  records, RADIUS servers involved in roaming SHOULD include
     a Class attribute in the Access-Accept.  The  Class  attribute  should
     uniquely  identify  a  session,  so  as to allow an authentication log
     entry to be matched with a corresponding accounting log.
     
     In order to be able to  match accounting logs  with  logs  of  proxied
     RADIUS authentications, accounting agents SHOULD require that they act
     as an authentication proxy for all sessions for  which  an  accounting
     record will subsequently be submitted.
     
     
     8.  Acknowledgments
     
     Thanks  to  Pat  Calhoun  of  3COM,  Mark Beadles of CompuServe, Aydin
     Edguer of Morningstar, and Steven P. Crain  of  Shore.Net  for  useful
     discussions of this problem space.
     
     
     9.  References
     
     [1]   B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of Roaming
     Implementations."  Internet  draft  (work  in  progress),  draft-ietf-
     roamops-imprev-04.txt,  Microsoft,  Aimnet, i-Pass Alliance, Asiainfo,
     Merit, June, 1997.
     
     [2]  B. Aboba, G.  Zorn.   "Dialing  Roaming  Requirements."  Internet
     draft    (work    in   progress),   draft-ietf-roamops-roamreq-04.txt,
     Microsoft, June, 1997.
     
     [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
     cation  Dial  In  User Service (RADIUS)." RFC 2138, Livingston, Merit,
     Daydreamer, April, 1997.
     
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 15]


     INTERNET-DRAFT                                        8 September 1997
     
     
     [4]  C. Rigney.  "RADIUS Accounting."  RFC  2139,  Livingston,  April,
     1997.
     
     [5]  C. Rigney, W. Willats.  "RADIUS Extensions." Internet draft (work
     in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
     
     [6] R. Fielding, et al.  "Hypertext Transfer Protocol - HTTP/1.1." RFC
     2068, UC Irvine, January, 1997.
     
     [7] R. Rivest, S. Dusse.   "The  MD5  Message-Digest  Algorithm",  RFC
     1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
     April 1992.
     
     [8] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
     Levels."  RFC 2119, Harvard University, March, 1997.
     
     [9]   B. Aboba.  "The Network Access Identifier." Internet draft (work
     in progress), draft-ietf-roamops-nai-06.txt, Microsoft, July 1997.
     
     [10]  B. Aboba and J.R. Vollbrecht.  "RADIUS Extensions for  Roaming."
     Internet  draft  (work in progress), draft-ietf-roamops-radius-00.txt,
     Microsoft, Merit Networks, September 1997.
     
     
     
     
     10.  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
     
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     Aboba, Vollbrecht & Zorn                                     [Page 16]