One document matched: draft-ietf-roamops-roamreq-08.txt
Differences from draft-ietf-roamops-roamreq-07.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-21 19:10:39 |