rfc2194.txt

中、英文RFC文档大全打包下载完全版 .

   GRIC implements distributed authentication, utilizing the user's e-
   mail address as the userID (i.e. "[e-mail]") presented to the
   remote NAS device.

   After the initial PPP authentication exchange, the userID, domain,
   and pasword information (or in the case of CHAP, the challenge and
   the response) are then passed by the NAS to the AimTraveler
   Authentication Server which supports both TACACS+ and RADIUS.

   If the authentication request comes from a regular customer login,
   normal user id and password authentication is performed. If the user
   requesting authentication is a "roamer," (has a userID with an @ and
   domain name), the authentication server sends an query to the closest
   routing server. When AimTraveler Routing Server receives the
   authentication request, it first authenticates the AAS sending the
   request, and if this is successful, it checks its authentication
   server table.  If it is able to match the domain of the user to that
   of a "Home ISP", then the Home ISP authentication server's routing
   information are sent back to the local ISP's authentication server.
   Based on the information received from the routing server, the AAS
   makes an authentication request to the user's Home ISP AAS for user
   id and password verification.

   If the user is a valid user, the Home ISP authentication server sends
   a "permission granted" message back to the Local ISP authentication
   server. The Local ISP authentication server then requests the NAS to
   grant the user a dynamic IP address from its address pool. If the



Aboba, et. al.               Informational                      [Page 6]

RFC 2194           Review of Roaming Implementations      September 1997


   username or password is incorrect, the Home ISP AAS will send a
   rejection message to the Local ISP AAS, and the user will be dropped
   by the NAS.

   If multiple routing servers are installed, and the query to the first
   routing server does not result in a match, the query is forwarded to
   the next routing server. The server queries are cached on the routing
   servers, improving speed for repeated queries. The cache is sustained
   until a routing server table entry is updated or deleted.  Updating
   or deleting results in a message to all neighbor routing servers to
   delete their caches.

   The local authentication server also receives the accounting data
   from the NAS.  If the data is for a regular customer login, the data
   is written to the Local ISP AAS log file. If the data is for a
   "roamer," the data is written to three places: the Local ISP AAS log
   file, the Home ISP AAS log file, and the ARS log file.

   If the local ISP authentication server has caching turned on, then it
   will cache information on Home ISP authentication server
   configurations sent by the routing server. This means that if the
   same domain is queried again, the local authentication server does
   not need to query the routing server again. The local cache is
   cleared when the local authentication server receives an update
   message from the routing server or system manager.

4.7.  NAS Configuration/Authorization

   AimTraveler is comprised of two components, a Client(AAS) and a
   Server(ARS).

   The AimTraveler Client acts as the PPP dial-up authentication server.
   When it detects an '@' sign in the userID field, it queries the
   AimTraverler Server for routing information, then forwards the
   authentication request to user's home authentication server.  The
   AimTraveler Server, a centralized routing server, contains the
   authorized ISP's domain name, authentication servers and other
   information.

   The AimTraveler currently supports RADIUS and TACACS+, and could be
   extended to support other authentication protocols.  It also receives
   all the accounting records, which are subsequently used as input data
   for billing.

   Since ISPs' NAS devices may be configured differently, the attributes
   returned by the home ISP AAS are discarded.





Aboba, et. al.               Informational                      [Page 7]

RFC 2194           Review of Roaming Implementations      September 1997


4.8.  Address assignment and routing

   All addresses in GRIC are assigned dynamically from within the
   address pool of the local ISP.  Static addresses and routed LAN
   connections will be considered in the future, when GRIC offers
   corporate roaming service, with the implementation of tunneling
   protocols

4.9.  Security

   The user's password is hashed with MD5 before being sent from the
   Local ISP AAS to the Home ISP AAS.  An encryption key is shared
   between the AAS and ARS. The current version of AimTraveler AAS does
   not support token cards or tunneling protocols.

4.10.  Accounting

   The AimTraveler Authentication Server (AAS) software can act as
   either a RADIUS or TACACS+ accounting server.  When accounting
   information is received from the NAS, the local AimTraveler
   Authentication Server (AAS) sends accounting data (user name, domain
   name, login time) to both the Central Accounting Server (part of the
   ARS) and the user's Home ISP AimTraveler authentication server. In
   the case of GRIC, the Central Accounting Server is run by AimQuest.

   The data sent to the central accounting server and home ISP are
   identical except for the form of user id and time stamp.  For a
   traveler whose home ISP is in the US, but who is traveling in Japan,
   the Local (Japanese) ISP AimTraveler authentication server will
   receive an accounting record timestamped with Japan time while the
   Home (US) ISP AimTraveler authentication server will receive an
   accounting record timestamped with the appropriate US timezone.

   The accounting data includes 2 new attributes for settlement
   reporting:

     Attribute              Number   Type
     ---------              ------   ----

     Roaming-Server-ID       101     string
     Isp-ID                  102     string

   The Roaming-Server-ID attribute identifies the AAS sending the
   authentication request.  The Isp-ID attribute identifies the local
   ISP.  Using this information the home ISP can track the roaming
   activities of its users (where their users are logging in).





Aboba, et. al.               Informational                      [Page 8]

RFC 2194           Review of Roaming Implementations      September 1997


   The AimTraveler Server running at AimQuest keeps a record of all
   roaming transactions, which are used as input to the settlement and
   billing process.  At the end of each month, AimQuest provides a
   roaming transaction summary to GRIC members using AIMS. The AIMS
   software is configurable so that it takes into account the settlement
   rules agreed to by GRIC members.

5.  i-Pass implementation

5.1.  Overview

   i-Pass Alliance Inc., based in Mountain View, California, has
   developed and operates a commercial authentication and settlement
   clearinghouse service which provides global roaming between Internet
   service providers.  The service is fully operational.

   i-Pass Alliance Inc. has additional offices in Toronto, Singapore,
   and London.  More information on i-Pass can be obtained from
   http://www.ipass.com.

   The i-Pass network consists of a number of servers that provide
   real-time authentication services to partner ISPs.  Authentication
   requests and accounting records for roaming users are encrypted and
   sent to an i-Pass serverwhere they are logged, and then forwarded to
   a home ISP for authentication and/or logging.

   Periodically, i-Pass reconciles all accounting records, generates
   billing statements, and acts as a single point for collecting and
   remitting payments.

   i-Pass provides its service only to ISPs and channel partners.  It
   does not attempt to establish a business relationship with
   individual-user customers of an ISP.

5.2.  Access Point Database (APD)

   i-Pass maintains a list of roaming access points in an Oracle
   database.  This list is searchable by geographical region using a Web
   browser, and may be downloaded in its entirety using FTP. The
   information stored for each access point includes:

      Name of service provider
      Country
      State or Province
      City or Region
      Telephone number
      Technical support phone number
      Service types available



Aboba, et. al.               Informational                      [Page 9]

RFC 2194           Review of Roaming Implementations      September 1997


      Technical information (help file)
      Service pricing information

   The Access Point Database is maintained by i-Pass staff, based on
   input from i-Pass partners.

5.3.  Phone number presentation

   ni-Pass has developed a Windows application wth a simple point and
   click interface called the "i-Pass Dial Wizard", which assists end-
   users in selecting and connecting to a local Internet access point.

   The Dial Wizard allows users to first select the country in which
   they are roaming.  A list of states, provinces, or other regions in
   the selected country is then presented.  Finally a list of access
   points within the state or province is presented.  The Dial Wizard
   displays the city name, modem phone number, and price information for
   each access point within the state or region.

   When the user selects the desired access point, a Windows 95 "DialUp
   Networking" icon is created for that access point.  If there is a
   login script associated with the access point, the DialUp Scripting
   tool is automatically configured.  This means that end-users never
   have to configure any login scripting requirements.

   The Dial Wizard has a built-in phonebook containing all the i-Pass
   access points.  The phonebook may be automatically refreshed from a
   master copy located onISPs web site.

   The Dial Wizard is provided free of charge to i-Pass partners.  i-
   Pass also provides the i-Pass Dial Wizard Customization Kit which
   allows ISP partners to generate customized versions of the Dial
   Wizard with their own logo, etc.

5.4.  Authentication

   There are three entities involved in servicing an authentication
   request:


   Local ISP  At the local ISP, the authentication server is modified to
          recognize user IDs of the form username@auth_domain as being
          remote authentication requests.  These requests are forwarded
          to an i-Pass server.







Aboba, et. al.               Informational                     [Page 10]

RFC 2194           Review of Roaming Implementations      September 1997


   i-Pass Server
          The i-Pass server receives the authentication request, logs
          it, and forwards it to the home ISP identified by the
          auth_domain portion of the user ID.

   Home ISP The home ISP receives the authentication request, performs
          authentication using its normal authentication method, and
          returns a YES/NO response to the i-Pass server, which in turn
          forwards the reply to the originating ISP.

   i-Pass provides software components which run on the authentication
   servers of the local and home ISPs.  Each member ISP must integrate
   these components with the native authentication method being used by
   the ISP.  To simplify this task, i-Pass has developed "drop-in"
   interfaces for the most commonly used authentication methods.  At the
   date of writing, the following interfaces are supported:

      Livingston RADIUS
      Ascend RADIUS
      Merit RADIUS
      TACACS+
      Xylogics erpcd (Versions 10 and 11)

   A generic interface is also provided which authenticates based on the
   standard UNIX password file.  This is intended as a starting point
   for ISPs using authentication methods other than those listed above.

   The software integration effort for a typical ISP is on the order of
   2-5 man-days including testing.  Platforms currently supported
   include:

      Solaris 2.5 (Sparc).LI
      Solaris 2.5 (Intel)
      BSDI
      Digital Unix
      Linux
      FreeBSD
      HP/UX

   ISPs may chooe to provide authentication for their end-users roaming
   elsewhere, but not to provide access points to the i-Pass network.
   In this case the software integration effort is greatly reduced and
   can be as little as 1/2 a man-day.

5.5.  Accounting