ROAMOPS Working Group                                      Bernard Aboba
INTERNET-DRAFT                                                 Glen Zorn
Category: Standards Track                          Microsoft Corporation
<draft-ietf-roamops-roamreq-08.txt>                           March 1998


                          Roaming Requirements


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 working doc-
uments 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  material
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-roamreq-08.txt>,  and  expires  September 15, 1998.  Please send
comments  to  the  Roaming  Operations  Working   Group   mailing   list
(roamops@tdmx.rutgers.edu),  or  to  the authors (bernarda@microsoft.com
and glennz@microsoft.com).


2.  Abstract

This document describes requirements for the  provisioning  of  "roaming
capability"  for dialup Internet users.  "Roaming capability" is defined
as the ability to use multiple Internet service providers (ISPs),  while
maintaining a formal, customer-vendor relationship with only one.


3.  Introduction

As  described in [1], operational roaming services are currently provid-
ing worldwide roaming capabilities, and these services continue to  grow
in popularity.  Interested parties have included:

     Regional  Internet  Service  Providers  (ISPs)  operating  within a



Aboba & Zorn                                                    [Page 1]


INTERNET-DRAFT            Roaming Requirements                March 1998


     particular state or province, looking to combine their efforts with
     those  of  other  regional providers to offer services over a wider
     area.

     National ISPs wishing to combine their operations with those of one
     or  more  ISPs  in  another nation to provide greater coverage in a
     group of countries or on a continent.

     Businesses desiring to offer their employees a comprehensive  pack-
     age  of  dialup  services  on  a  global basis.  Those services can
     include Internet access as  well  as  secure  access  to  corporate
     intranets via a Virtual Private Network (VPN).

This  document  provides an architectural framework for the provisioning
of roaming capabilities, as well as  describing  the  requirements  that
must be met by elements of the architecture.


3.1.  Requirements language

This  document specifies a set of requirements for elements of the roam-
ing architecture, and uses the same words as [4] for defining  the  sig-
nificance 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  specifica-
          tion.

MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defini-
          tion 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  under-
          stood  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 accept-
          able or even useful,  but  the  full  implications  should  be
          understood  and the case carefully weighed before implementing
          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 item
          because a particular marketplace requires it  or  because  the
          vendor feels that it enhances the product while another vendor



Aboba & Zorn                                                    [Page 2]


INTERNET-DRAFT            Roaming Requirements                March 1998


          may omit the same item.   An  implementation  which  does  not
          include  a  particular option MUST be prepared to interoperate
          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 implementation which
          does not include the option (except, of course, for  the  fea-
          ture the option provides).

Please  note  that the requirements specified in this document are to be
used in evaluating protocol submissions.  As such, the requirements lan-
guage  refers to capabilities of these protocols; the protocol documents
will specify  whether  these  features  are  required,  recommended,  or
optional for use in roaming. For example, requiring that a protocol sup-
port confidentiality is NOT the same thing as requiring that all  proto-
col traffic be encrypted.

An  protocol  submission  is not compliant if it fails to satisfy one or
more of the must or must not requirements for the capabilities  that  it
implements.   A  protocol  submission  that satisfies all the must, must
not, should and should not requirements for its capabilities is said  to
be "unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not  requirements  for
its protocols is said to be "conditionally compliant."


3.2.  Terminology

This document frequently uses the following terms:

phone book
          This  is  a database or document containing data pertaining to
          dialup access, including  phone  numbers  and  any  associated
          attributes.

phone book server
          This  is  a  server  that  maintains the latest version of the
          phone book.  Clients communicate with phone  book  servers  in
          order to keep their phone books up to date.

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

Authentication server
          This is a server which provides for  authentication/authoriza-
          tion within the roaming architecture.




Aboba & Zorn                                                    [Page 3]


INTERNET-DRAFT            Roaming Requirements                March 1998


Accounting server
          This  is  a  server  which  provides for accounting within the
          roaming architecture.

Authentication proxy
          Authentication proxies may  be  deployed  within  the  roaming
          architecture  for  several  purposes, including authentication
          forwarding, policy implementation, shared  secret  management,
          and  attribute  editing.  To the NAS, the authentication proxy
          appears to act as an authentication server, and to the authen-
          tication server, the proxy appears to act as an authentication
          client.

Accounting proxy
          Accounting proxies may be deployed within the  roaming  archi-
          tecture for several purposes, including accounting forwarding,
          reliability improvement, auditing, and  "pseudo-transactional"
          capability. To the NAS, the accounting proxy appears to act as
          an accounting server, and to the accounting server, the  proxy
          appears to act as an accounting client.

Network Access Identifier
          In  order  to  provide  for  the routing of authentication and
          accounting packets, the userID field used in PPP (known as the
          Network  Access Identifier or NAI) may contain structure. This
          structure provides a means  by  which  the  authentication  or
          accounting  proxies will locate the authentication or account-
          ing server that is to receive the request.


4.  Architectural framework

The roaming architecture consists of three major subsystems:

     Phone book Subsystem
     Authentication Subsystem
     Accounting Subsystem

The phone book subsystem is concerned with the maintenance and  updating
of  the  user phone book. The phone book provides the user with informa-
tion on the location and phone numbers of Points of Presence (POPs) that
are  roaming enabled. The function of the authentication subsystem is to
provide authorized users with access to the POPs in the  phonebook,  and
to deny access to unauthorized users. The goal of the accounting subsys-
tem is to provide information  on  the  resources  utilized  during  the
user's session.





Aboba & Zorn                                                    [Page 4]


INTERNET-DRAFT            Roaming Requirements                March 1998


4.1.  Phone Book Subsystem

The phone book subsystem provides for the following:

     Phone number presentation
     Phone number exchange
     Phone book compilation
     Phone book update

Phone number presentation
     Phone  number  presentation involves the display of available phone
     numbers to the user, and culminates in the choosing  of  a  number.
     Since  the  user interface and sequence of events involved in phone
     number presentation is a  function  of  the  connection  management
     software  that  Fred is using, it is likely that individual vendors
     will take different approaches to the problem.   These  differences
     can  include  variances  in  the  format of the client phone books,
     varying approaches to presentation,  etc.   There  is  no  inherent
     problem  with this. As a result, phone number presentation need not
     be standardized.

Phone number exchange
     Phone number exchange involves propagation of phone number  changes
     between providers in a roaming association. As described in [1], no
     current roaming implementations provide for complete automation  of
     the  phone  number  exchange  process.  As  a  result, phone number
     exchange need not be standardized at this time.

Phone book compilation
     Once an ISP's phone book server has received its updates  it  needs
     to  compile  a  new phone book and propagate this phone book to all
     the phone book servers operated by that ISP. Given that the  compi-
     lation  process  does not affect protocol interoperability, it need
     not be standardized.

Phone book update
     Once the phone book is compiled, it needs to be propagated to  cus-
     tomers. Standardization of the phone book update process allows for
     providers to update the phone books of users, independent of  their
     client and operating system.


4.2.  Authentication Subsystem

The authentication subsystem provides for the following:

     Connection management
     Authentication



Aboba & Zorn                                                    [Page 5]


INTERNET-DRAFT            Roaming Requirements                March 1998


     NAS Configuration/Authorization
     Address Assignment/Routing
     Security

Connection management
     In  order  to  be able to use the POPs of the local provider, it is
     first necessary to bring up a connection.

Identification
     Authentication consists of two parts: the  claim  of  identity  (or
     identification)  and  the proof of the claim (or verification).  As
     part of the authentication process, users  identify  themselves  to
     the Network Access Server (NAS) in a manner that allows the authen-
     tication request to be routed its home destination.

Authentication
     Authentication is typically required prior to  allowing  access  to
     the  network.   CHAP  and  PAP are the two authentication protocols
     used within the PPP framework today.   Some  groups  of  users  are
     requiring  different  forms  of  proof  of identity (e.g., token or
     smart cards, Kerberos credentials, etc.) for special purposes (such
     as  acquiring  access  to  corporate  intranets).   The  Extensible
     Authentication Protocol (EAP) was created in  order  to  provide  a
     general mechanism for support of these methods.

NAS configuration/authorization
     In order to set up the session, authorization parameters need to be
     sent to from the home authentication server to the local ISP's NAS.

Address assignment/routing
     If it is desired that the user be able to communicate with the rest
     of the Internet, then the session MUST be assigned  a  routable  IP
     address.


Security
     In the process of authenticating and authorizing Fred's session, it
     may be desirable to provide protection against a variety  of  secu-
     rity threats.


4.3.  Accounting Subsystem

The  function  of the accounting subsystem is to enable the participants
in the roaming consortium to keep track of what resources are used  dur-
ing  a session. Relevant information includes how long the user was con-
nected to the service, what speed he connected at, the  port  type  con-
nected to, etc.



Aboba & Zorn                                                    [Page 6]


INTERNET-DRAFT            Roaming Requirements                March 1998


5.  Roaming Requirements


5.1.  Phonebook requirements


5.1.1.  Phone book update protocol


Portability
     The  update  protocol MUST allow for updating of clients on a range
     of platforms and operating systems. Therefore the update  mechanism
     MUST not impose any operating system-specific requirements.

Authentication
     The client MUST be able to determine the authenticity of the server
     sending the phone book update.  The server  MAY  also  be  able  to
     authenticate the client.

Versioning
     The  update  protocol  MUST  provide for updating of the phone book
     from an arbitrary previous version to the latest available version.

Integrity Checking
     The  client MUST be able to determine the integrity of the received
     update before applying it, as well as the integrity  of  the  newly
     produced phone book after updating it.

Lightweight transfers
     Since  the  client machine can be a low-end PC, the update protocol
     SHOULD be lightweight.

Language support
     The phone book update mechanism MUST support the ability to request
     that  the  phone  book  be transmitted in a particular language and
     character set.  For example, if the customer has a Russian language
     software  package,  then  the propagation and update protocols MUST
     provide a mechanism for the user  to  request  a  Russian  language
     phone book.


5.1.2.  Phone book format


Phone number attributes
     The phone book format MUST support phone number attributes commonly
     used by Internet service providers. These attributes  are  required
     in  order  to provide users with information on the capabilities of



Aboba & Zorn                                                    [Page 7]


INTERNET-DRAFT            Roaming Requirements                March 1998


     the available phone numbers.

Provider attributes
     In addition to providing information relating to a given phone num-
     ber,  the  phone  book  MUST  provide information on the individual
     roaming consortium members. These attributes are required in  order
     to provide users with information about the individual providers in
     the roaming consortium.

Service attributes
     In addition to providing information relating to a given phone num-
     ber,  and service provider, the phone book MUST provide information
     relevant to configuration of the service. These attributes are nec-
     essary to provide the client with information relating to the oper-
     ation of the service.

Extensibility
     Since it will frequently be necessary to add phone book attributes,
     the  phone  book  format MUST support the addition of phone number,
     provider and service attributes without modification to the  update
     protocol. Registration of new phone book attributes will be handled
     by IANA. The attribute space MUST be sufficiently large to  accomo-
     date growth.

Compactness
     Since  phone  book  will typically be frequently updated, the phone
     book format MUST be compact so as to minimize the bandwidth used in
     updating it.


5.2.  Authentication requirements


5.2.1.  Connection Management

Given  the  current popularity and near ubiquity of PPP, a roaming stan-
dard MUST provide support for PPP and IP. A roaming standard MAY provide
support  for other framing protocols such as SLIP, However, SLIP support
is expected to prove difficult since SLIP does not  support  negotiation
of  connection parameters and lacks support for protocols other than IP.
A roaming standard MAY provide support for non-IP protocols  (e.g.,  IPX
or  AppleTalk) since these will be useful for the provision of corporate
intranet access via the Internet.  Since it is intended that the  client
will  begin  PPP  negotiation  immediately  on  connection,  support for
scripting will not be part of a roaming standard.






Aboba & Zorn                                                    [Page 8]


INTERNET-DRAFT            Roaming Requirements                March 1998


5.2.2.  Identification

A roaming standard MUST provide a standardized format for the userID and
realm  presented  to  the NAS. This userID is also commonly known as the
Network Access Identifier (NAI).


5.2.3.  Verification of Identity


Authentication types
     A roaming standard MUST support CHAP, and SHOULD support EAP.   Due
     to  security  concerns, PAP authentication SHOULD NOT be supported.
     A possible exception is where PAP is used to  support  a  one  time
     password or token.

Scalability
     A roaming standard, once available, is likely to be widely deployed
     on the Internet. A roaming standard MUST therefore  provide  suffi-
     cient  scalability  to  allow for the formation of roaming associa-
     tions with thousands of ISP members.

RADIUS Support
     Given the current popularity and near  ubiquity  of  RADIUS  as  an
     authentication,  authorization  and  accounting solution, a roaming
     standard MUST be able to incorporate RADIUS-enabled devices  within
     the  roaming  architecture. It is expected that this will be accom-
     plished by development of gateways between RADIUS and  the  roaming
     standard authentication, authorization, and accounting protocol.


5.2.4.  NAS Configuration/Authorization

In  order  to ensure compatibility with the parameters of the NAS or the
local network, an authentication proxies often will add, delete, or mod-
ify  attributes returned by the home authentication server. In addition,
an authentication proxy will often need to performance resource  manage-
ment functions. As a result, a roaming standard MUST support the ability
of proxies to perform attribute editing and implement policy.


5.2.5.  Address assignment/routing

A roaming standard MUST  support  dynamic  address  assignment.   Static
address  assignment MAY be supported, most likely via layer 2 or layer 3
tunneling.





Aboba & Zorn                                                    [Page 9]


INTERNET-DRAFT            Roaming Requirements                March 1998


Layer 2 tunneling protocols
     Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold great
     promise  for  the  implementation  of Virtual Private Networks as a
     means for inexpensive access to remote  networks.  Therefore  proxy
     implementations MUST NOT preclude use of layer 2 tunneling.

Layer 3 tunneling protocols
     Layer-3  tunneling protocols as embodied in Mobile IP, described in
     [8], hold great promise for providing "live", transparent  mobility
     on  the  part  of  mobile  nodes on the Internet.  Therefore, proxy
     implementations MUST NOT preclude the provision of Mobile  IP  For-
     eign Agents or other Mobile IP functionality on the part of service
     providers.


5.2.6.  Security


Security analysis
     A roaming standard  must  include  a  thorough  security  analysis,
     including  a  description  of security threats and countermeasures.
     This includes specification of mechanisms for fraud prevention  and
     detection.

Hop by hop security
     A roaming standard MUST provide for hop-by-hop integrity protection
     and confidentiality. This can be accomplished  through  support  of
     network layer (IPSEC) or transport layer security (TLS).

End-to-end security
     As  policy implementation and attribute editing are common in roam-
     ing systems, it is often necessary for proxies to modify packets in
     transit between a local NAS and the home server. In order to permit
     authorized modifications while at the same  time  guarding  against
     attacks by rogue proxies, it is necessary for a roaming standard to
     support data object security. As a result, a roaming standard  MUST
     provide  end-to-end  confidentiality and integrity protection on an
     attribute-by-attribute basis. However,  non-repudiation  is  NOT  a
     requirement for a roaming standard.


5.3.  Accounting requirements


Real-time accounting
     In today's roaming implementations, real-time accounting is a prac-
     tical necessity in order to support fraud detection and  risk  man-
     agement.  As  a result, a roaming standard MUST provide support for



Aboba & Zorn                                                   [Page 10]


INTERNET-DRAFT            Roaming Requirements                March 1998


     real-time accounting.

End-to-end security
     Proxies in a roaming system SHOULD NOT  modify  accounting  packets
     before  forwarding them; however, modifications may be necessary in
     some situations.  In order to permit authorized modifications while
     at  the  same time guarding against attacks by rogue proxies, it is
     necessary for a roaming standard to support data  object  security.
     As  a  result, a roaming standard MUST provide end-to-end confiden-
     tiality  and  integrity  protection  on  an  attribute-by-attribute
     basis.  However, non-repudiation is NOT a requirement for a roaming
     standard.

Accounting record formats
     Today there is no proposed standard for NAS accounting,  and  there
     is wide variation in the protocols used by providers to communicate
     accounting information within their own organizations. As a result,
     a  roaming  standard  MUST  prescribe  a  standardized  format  for
     accounting records.  For the sake of efficiency, the record  format
     MUST be compact.

Extensibility
     A  standard accounting record format MUST be able to encode metrics
     commonly used by Internet Service Providers to determine the user's
     bill.   Since these metrics change over time, the accounting record
     format MUST be extensible so as to be able to add future metrics as
     they  come along. The record format MUST support both standard met-
     rics as well as vendor-specific metrics.


6.  Evaluation of the RADIUS protocol

As noted below, the RADIUS protocol does  not  satisfy  several  of  the
requirements  for  a roaming standard authentication, authorization, and
accounting protocol. These include lack of support for hop-by-hop confi-
dentiality,  as  well  as  end-to-end confidentiality and integrity ser-
vices.

As a result, in order to satisfy the roaming requirements, a new  proto-
col will be required.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Requirement   |    Level    |   RADIUS    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   PPP           |    MUST     |     YES     |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Aboba & Zorn                                                   [Page 11]


INTERNET-DRAFT            Roaming Requirements                March 1998


|                 |             |             |
|   CHAP          |    MUST     |     YES     |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   EAP           |    SHOULD   |     YES     |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   RADIUS        |    MUST     |     YES     |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   Tunnels       |    MUST     |     YES     |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   H-H           |             |             |
| Integrity       |    MUST     |     YES     |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   H-H           |             |             |
| Confidentiality |    MUST     |     NO      |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   E-E           |             |             |
| Integrity       |    MUST     |     NO      |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 |             |             |
|   E-E           |             |             |
| Confidentiality |    MUST     |     NO      |
|                 |             |             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


7.  Security Considerations

Security issues are discussed throughout this document.


8.  Acknowledgements

Thanks   to   Pat  Calhoun  (pcalhoun@toast.net),  Dr.  Thomas  Pfenning
(thomaspf@microsoft.com), and Don Dumitru (dondu@microsoft.com) for many
useful discussions of this problem space.



Aboba & Zorn                                                   [Page 12]


INTERNET-DRAFT            Roaming Requirements                March 1998


9.  References


[1]  Aboba,  B., et. al., "Review of Roaming Implementations", RFC 2194,
     September 1997

[2]  Rigney, C., et. al., "Remote Authentication Dial  In  User  Service
     (RADIUS)", RFC 2138, April 1997

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

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

[5]  Zorn, G., "RADIUS Attributes for Tunnel Protocol  Support",  draft-
     ietf-radius-tunnel-auth-04.txt (work in progress), November 1997

[6]  Aboba, B. and Zorn, G., "Implementation of PPTP/L2TP Mandatory Tun-
     neling via RADIUS",  draft-ietf-radius-tunnel-imp-03.txt  (work  in
     progress), September 1997

[7]  Rigney, C. and Willats, W., "RADIUS Extensions", draft-ietf-radius-
     ext-01.txt (work in progress), December 1997

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


10.  Acknowledgements

Thanks  to  Pat  Calhoun  (pcalhoun@toast.net),  Dr.   Thomas   Pfenning
(thomaspf@microsoft.com), and Don Dumitru (dondu@microsoft.com) for many
useful discussions of this problem space.


11.  Chairs' Addresses

The Roaming Operations Working Group can be contacted  via  the  current
chairs:

   Pat Calhoun
   Sun Microsystems
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: +1 650 960 1300
   Email: pcalhoun@toast.net





Aboba & Zorn                                                   [Page 13]


INTERNET-DRAFT            Roaming Requirements                March 1998


   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 425-703-1559
   EMail: glennz@microsoft.com


12.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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


Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-703-1559
EMail: glennz@microsoft.com


13.  Expiration Date

This memo is filed as <draft-ietf-roamops-roamreq-08.txt> and expires on
September 15, 1998.


















Aboba & Zorn                                                   [Page 14]