ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-nai-00.txt>
The Network Access Identifier
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-nai.txt> and expires June 1, 1997. Please send comments
to the authors.
2. Abstract
This document describes issues relating to user identification in pro-
vision of "roaming capability" for dialup Internet users. "Roaming
capability" may be loosely defined as the ability to use any one of
multiple Internet service providers (ISPs), while maintaining a for-
mal, customer-vendor relationship with only one. Examples of cases
where roaming capability might be required include ISP "confedera-
tions" and ISP-provided corporate network access support.
3. Introduction
Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for dialup
Internet users. Interested parties have included:
Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service
over a wider area.
National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
Aboba [Page 1]
INTERNET-DRAFT 26 November 1996
dialup service in a group of countries or on a continent.
Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services may
include Internet access as well as secure access to corporate
intranets via a Virtual Private Network (VPN), enabled by tunnel-
ing protocols such as PPTP and L2TP.
This document focuses on issues of user identification for use in
roaming services. However, since roaming and tunneling are closely
related, it is believed that the considerations described here will
also be of interest to those working on tunneling.
3.1. Terminology
This document frequently uses the following terms:
Network Access Identifier
The Network Access Identifier (NAI) is the userID submitted
by the client during the PPP negotiation. In roaming, the
purpose of the NAI is to identify the user as well as to
assist in the routing of the authentication request. As
such, the NAI may be presented either in the form of an
authentication route, or a pointer to such a route. Please
note that the NAI may not necessarily be the same as the
user's e-mail address or the userID submitted in an applica-
tion layer authentication (i.e. HTTP authentication). In
order to avoid confusion on this point, a new term was
coined.
Network Access Server
The Network Access Server (NAS) is the device that clients
dial in order to get access to the network. In PPTP termi-
nology this is referred to as the PPTP Access Concentrator
(PAC), and in L2TP terminology, it is referred to as the
L2TP Access Concentrator (LAC).
RADIUS server
This is a server which provides for authentica-
tion/authorization via the protocol described in [3], and
for accounting as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
and accounting requests, a RADIUS proxy may employed. To the
NAS, the RADIUS proxy acts as a RADIUS server, and to the
RADIUS server, the proxy acts as a RADIUS client.
3.2. Purpose
As described in reference [1], there are now at least four services
implementing dialup roaming, and the number of Internet Service
Aboba [Page 2]
INTERNET-DRAFT 26 November 1996
Providers involved in roaming consortia is increasing rapidly.
In order to be able to offer roaming capability, one of the require-
ments is to be able to identify the user and route the authentication
request to the user's home RADIUS server. These functions are accom-
plished via the NAI submitted by the user to the NAS in the initial
PPP authentication.
This document proposes syntax and semantics for the NAI. It is
expected that this will be of interest for support of roaming as well
as tunneling. For example, references [5] and [6] refer to use of the
NAI in determining the tunnel endpoint. However, these references do
not provide guidelines for how RADIUS or tunnel routing is to be
accomplished. In order to avoid the possibility of conflicting and
non-interoperable implementations, references [7] and [8] describe how
RADIUS and tunneling protocols may be integrated. This document pro-
vides guidance in the use of the NAI that is relevant to both the
roaming and tunneling communities.
4. Requirements for roaming authentication
What requirements must a roaming authentication scheme satisfy to be
successful? These include:
Scalability requirements
As described in [2], it is highly desirable that a roaming
implementation be scalable so as to accommodate at least 40
members within a roaming consortia, each serving at least 10
corporate clients. It is also desired than a roaming imple-
mentation be able to handle an unlimited number of users.
Ease of administration
It is desirable that the chosen NAI approach be easy to
administer. This means that the number of table entries or
zone files maintained by service providers or corporations
should be kept to a minimum. It also means that users should
be forced to change their NAIs only on very rare occasions.
Security The NAI approach taken must be secure, in that it must guard
against attacks which could result in theft of service, or
submission of fraudulent charges. In particular, the NAI
approach must provide for secure determination of the loca-
tion of the settlement agent.
Chain of trust
A successful roaming authentication scheme must be able to
establish a chain of trust between remote NAS devices and
home ISP servers. This can be accomplished via a variety of
methods, including (in the case of RADIUS) hierarchical
authentication routing, or (in the case of certificates) a
Web of trust. In either case, it is necessary that it be
possible to construct the hierarchical authentication route
Aboba [Page 3]
INTERNET-DRAFT 26 November 1996
or trust Web based on the NAI. This does not necessarily
imply that the NAI is itself a representation of an authen-
tication route or trust web.
4.1. Alternatives for authentication of roaming users
In order to authenticate roaming users, it is necessary to be able to
route the authentication requests from the NAS of the remote ISP to a
server maintained by the home ISP. Since the RADIUS protocol is com-
monly implemented both by NAS vendors as well as by ISPs, it is pro-
posed that RADIUS be used as the mechanism for roaming authentication.
Although the choice of RADIUS is expedient, it has significant draw-
backs. In particular, routing of RADIUS authentication/authorization
messages is complicated by the security architecture of the RADIUS
protocol. The RADIUS protocol requires the maintenance of a shared
secret between the NAS and the RADIUS server or proxy. Therefore, were
RADIUS authentication requests to be routed directly, the result would
be a requirement for maintenance of shared secrets between every NAS
device and every RADIUS server. This would get out of hand very
quickly. As a result, hierarchical authentication routing is a
requirement for scalable authentication of roaming users via RADIUS.
Authentication routes can be maintained by a number of means, includ-
ing propagation of configuration files, and as described in this docu-
ment, use of DNS. Note that even if DNS is used, configuration files
are still necessary, since they provide the RADIUS proxy with the list
of shared secrets. This list of shared secrets is also a list of sys-
tems whose owners have a business relationship with the configuring
ISP.
Note that hierarchical authentication routing would not necessarily be
required if an authentication protocol supporting certificates were
used. This is because shared secrets would no longer be necessary in
order for the two authentication endpoints to engage in a secure con-
versation. Thus a NAS server would be able to contact the home ISP
server directly.
This is not necessarily as desirable as it seems at first glance. For
one thing, direct contact between the NAS and the home ISP has the
potential to exacerbate interoperability problems since it implies,
for example, that the two end systems must be running the same
accounting protocol and that the home ISP's server must be able to
return configuration attributes that the remote NAS understands. Thus
RADIUS proxies are useful for more than just authentication routing.
Moreover, even with certificates it is still necessary for the two
parties to determine whether they have a business relationship with
each other. This is equivalent to verifying the validity of the cer-
tificate within the web or hierarchy of trust used by the roaming con-
sortium.
Aboba [Page 4]
INTERNET-DRAFT 26 November 1996
Thus while certificates may provide a way of automating the configura-
tion process, they do not eliminate it entirely. In effect, use of
certificates substitute verification of the chain of trust for routing
of RADIUS authentication requests.
Since certificates are not a panacea and we do not yet have a certifi-
cate infrastructure in place, it is recommended that in the short to
medium term, RADIUS authentication forwarding be used for authentica-
tion of roaming users.
4.2. Hierarchical authentication routing
Hierarchical authentication routing is implemented via a multi-tier
RADIUS proxy system, with individual ISPs running their own proxies,
and allowing authentication requests to be routed directly only to
other members of the roaming consortium. This allows ISPs to maintain
shared secrets only with the other consortium members, as well as with
customers with whom they have a direct business relationship.
For example, let us assume that we have n members of a roaming consor-
tia, each of which have m distinct corporate customers whom they wish
to provide access for. These corporate customers wish to maintain
their own RADIUS servers so as to be able to manage their users more
efficiently. Thus we have n * m corporate entities that wish to allow
their users to have access to the facilities of the roaming consor-
tium.
If the RADIUS proxy of a given ISP were to contact each RADIUS server
directly, each RADIUS proxy would need to maintain n * m + n - 1
shared proxy secrets. This is a shared secret for each corporate
entity, plus a shared secret for each member of the roaming consor-
tium. For the case of 40 roaming consortia members, each with 10 cor-
porate customers, this translates to 439 shared secrets per ISP. This
would be unmanageable.
On the other hand, let us assume that we implement hierarchical
authentication routing. In this case, the RADIUS proxy of a given ISP
would only need to contact the RADIUS proxies of the other ISPs in
ISPGROUP as well as the RADIUS servers of its own corporate customers.
To do this, it would only need to maintain n-1+m shared secrets. For
the case of 40 roaming consortia members, each with 10 corporate cus-
tomers, this translates to 49 shared secrets per ISP, a dramatic
reduction.
5. Authentication routing
Given that hierarchical authentication routing appears to be a
requirement, how can this be implemented? Several approaches have been
suggested. These include:
Hierarchical naming
Authentication and Accounting Route (AR) records
Aboba [Page 5]
INTERNET-DRAFT 26 November 1996
We will explore each of these alternatives in turn.
5.1. Hierarchical naming
In hierarchical naming, a combination of the authentication route and
the username is used as the NAI. As a result, a RADIUS proxy acquiring
an NAI will be able to determine the next hop by examination of the
authentication route. Since an authentication route may have an arbi-
trary number of hops, the syntax for description of such routes must
not be limited in the number of hops it can represent.
While many syntaxes may be used to used to denote an authentication
route, in this document it is proposed that the the "/" separator
character be used to separate the elements of an authentication route.
Therefore, an authentication route that passed from the roaming con-
sortium ISPGROUP1 to ISPA to BIGCO would be represented as ISP-
GROUP1.COM/ISPA.COM/BIGCO.COM/, and the full NAI would be ISP-
GROUP1.COM/ISPA.COM/BIGCO.COM/fred.
This approach has the advantage of being simple. Since the authentica-
tion route is embedded within the NAI, no indirection is needed to
retrieve the route. Since such indirection typically depends on propa-
gation of a file or a lookup in the DNS, it is likely that use of
indirection will increase code complexity, as well as introduce sev-
eral new error conditions.
This approach also has several disadvantages. The first of these is
that if BIGCO changes their ISP relationships, then it will need to
change the NAIs of its users. In practice it is to be expected that
corporations will reevaluate their ISP relationships on a periodic
basis, and that ISPs will join and leave roaming consortia, so that
this is likely to be a considerable problem, particularly for ISPs and
corporations with large numbers of users.
The second disadvantage is that this representation of the NAI is sub-
stantially different from a typical e-mail address, which is of the
form fred@bigco.com. It also may be possible that BIGCO has multiple
ISP relationships. This may occur for example, if the ISPGROUP1 roam-
ing consortia does not cover all of the countries that BIGCO's employ-
ees wish to visit. In this case, BIGCO may also establish a relation-
ship with another ISP that is a member of a consortia ISPGROUP2 that
covers the desired countries. As a result, a single authentication
route embedded in the NAI is not adequate to describe the ISP rela-
tionships of BIGCO.
In addition, the embedding of a route within the NAI may not provide
information on the settlement agent to use for a given route. For
example, it may be possible that ISPA and ISPB are members of two
roaming consortia. In this case, the route ISPA.COM/BIGCO.COM/ does
not identify which consortia's billing policies are to be in effect
for the length of the call, and which settlement server to submit the
accounting record to when the session is complete.
Aboba [Page 6]
INTERNET-DRAFT 26 November 1996
As a result, it is believed that the hierarchical naming approach is
not sufficient to handle all the requirements.
5.2. Authentication and Accounting Route (AR) records
One way to support hierarchical routing as well as to provide addi-
tional flexibility, is to allow for indirection in the determination
of authentication and accounting routes. When this approach is taken,
the NAI is used to embed a pointer to an authentication and accounting
route, rather than embedding the route itself. For the purposes of
this specification, the convention user@domain syntax is used, with
the domain portion of the NAI being used to retrieve the authentica-
tion and accounting route via DNS.
5.2.1. Definition of the Authentication and Accounting Route (AR)
record
The Authentication and Accounting Route (AR) record uses semantics
similar to that of the Mail Exchange (MX) record, in that it includes
a priority as well as the authentication route. The AR record is of
the form:
bigco.com. IN AR 10 ispgroup1.com/ispa.com/bigco.com/ ispgroup1.com.
Here 10 refers to the priority of the AR record, isp-
group1.com/ispa.com/bigco.com/ is the authentication route, and isp-
group1.com. represents the domain of the settlement agent. The use of
a priority field allows multiple relationships to be represented, with
authenticating ISPs checking the relationships in ascending order of
priority. Thus, an AR record of priority 10 would be checked before a
record of priority 20.
Routes for a given domain SHOULD be given different priorities, so as
to allow for predictable behavior. Since routes at the same priority
will be round-robined, this will result in alternation of routes.
Unless there is a good reason for balancing the load this way, this
approach should be avoided.
5.2.2. Example One
Let us say Fred is an employee of BIGCO, who has established account
relationships with ISPA and ISPC, both of which are members of roaming
consortia ISPGROUP. BIGCO also has a relationship with clearing houses
ISPGROUP1 and ISPGROUP2.
Fred is now traveling, and logs into ISPB as fred@bigco.com. The ISPB
RADIUS proxy receives this NAI. ISPB then checks bigco.com in its list
of firms with whom it has a direct business relationship. This check
will fail since BIGCO is not a direct customer of ISPB, and is not an
ISP or roaming consortia.
Aboba [Page 7]
INTERNET-DRAFT 26 November 1996
ISPB now looks up the Authentication and Accounting Route Record for
bigco.com, and receives the following reply:
bigco.com. IN AR 10 ispa.com/bigco.com/ ispgroup.com.
bigco.com. IN AR 20 ispc.com/bigco.com/ ispgroup.com.
bigco.com. IN AR 30 ispgroup2.com/bigco.com/ ispgroup2.com.
bigco.com. IN AR 40 ispgroup1.com/bigco.com/ ispgroup1.com.
The ISPB RADIUS proxy now checks the AR records in order of priority
so as to determine whether it has a business relationship with any of
the domains listed in the returned AR records. The RADIUS proxy will
select the first record in which there is a valid business relation-
ship.
In this case, ISPB's RADIUS proxy discovers that ISPA is a member of
the ISPGROUP roaming consortia. As a result, the authentication
request is forwarded to the authentication proxy operated by ISPA.COM.
The method by which this authentication server is determined, and the
method by which ISPB verifies ISPA's membership in ISPGROUP is
described in a subsequent section.
If ISPA was not a member of the ISPGROUP roaming consortia, ISPB's
proxy would continue down the list. For example, if ISPC were a member
of ISPGROUP, then it would forward the authentication request to
ISPC's RADIUS proxy. If ISPB had no relationship with ISPC, then it
would check to see if it had a business relationship with ISPGROUP2.
In the case where a business relationship existed, the authentication
would be forwarded to the authentication proxy within the isp-
group2.com domain. If no business relationship existed with ISPGROUP2,
then ISPB's proxy would check for a relationship with ISPGROUP1, and
failing that, would send a RADIUS Access-Reject message.
Let us assume that ISPA has received the forwarded authentication
request. It will then check the domain portion of the NAI (bigco.com)
to see if there is a direct business relationship. Since this is the
case, ISPA will then retrieve the location of BIGCO's authentication
server and forward the authentication request to that server. After
the session is over, ISPB's RADIUS proxy will route the accounting
record to the settlement agent identified in the AR record.
5.2.3. Example Two
Let us assume that BIGCO has branch offices in multiple locations. The
BIGCO branch office in Illinois has a contract with ISPA, which is a
member of ISPGROUP1 while the branch office in Israel has a contract
with ISPC, which is a member of ISPGROUP2. As a result, it is desired
that Fred be able to login either from Illinois or from Israel, with
the authentication being done by the appropriate ISP.
In this case, the AR records for BIGCO will appear as follows:
bigco.com. IN AR 10 ispa.com/bigco.com/ ispgroup1.com.
bigco.com. IN AR 20 ispc.com/bigco.com/ ispgroup2.com.
Aboba [Page 8]
INTERNET-DRAFT 26 November 1996
As a result, when Fred attempts to authenticate with ISPB while in the
United States, the authentication request will be routed to ISPA,
assuming that ISPB has a business relationship with ISPA. In this
case, the accounting record will be submitted to ISPGROUP1 for settle-
ment. When Fred travels to Israel, and dials into ISPD, it will also
check the authentication routes, and presumably will find that it has
a relationship with ISPC, but not with ISPA. As a result, the authen-
tication request will be forwarded to ISPC rather than ISPA, and the
accounting record will be submitted to ISPGROUP2 for settlement.
6. Accounting Issues
Since billing rates may differ between roaming consortia, it is neces-
sary that the accounting records include the relevant authentication
route and settlement agent. Since it is possible that ISPB and ISPA
may both be members of more than one roaming consortia, an authentica-
tion route of ispa.com/bigcom.com/ does not uniquely determine the
consortia to whom the accounting record should be submitted for set-
tlement.
In the case of hierarchical naming, including the authentication route
in the accounting record is as simple as including the NAI within the
accounting record, since in this case the route is embedded within the
NAI. However, using the hierarchical naming approach, information on
the settlement agent is not available. As a result, ISPs using this
naming approach will need to ensure that their RADIUS proxies are con-
figured with information on the relevant settlement agents.
For the case where a DNS AR record is used, the situation is more com-
plicated. In this case, the RADIUS proxy needs to keep a forwarding
table mapping RADIUS domains to authentication routes and settlement
agents. When the proxy receives a RADIUS Accounting-Request message
(START or STOP), it will find the authentication route and settlement
agent corresponding to the NAI in the forwarding table, and will
insert this in the accounting record for the session.
The forwarding table is filled in as DNS AR records are received.
Ordinarily an AR record is kept in the forwarding table until it times
out. This implies that the forwarding table will typically remain con-
stant between the time that the authentication is processed and when
the accounting records are generated.
The possible exceptions to this behavior are when the TTL expires in
mid-session or if the RADIUS proxy server is restarted, causing a
rebuilding of the forwarding table. In these cases if the AR record
has changed it is possible that the existing sessions may be accounted
for incorrectly. To avoid this, the RADIUS proxy MUST NOT modify the
forwarding table entry for a domain with a session in progress.
Aboba [Page 9]
INTERNET-DRAFT 26 November 1996
7. Security issues
So far, we have not described how ISPB determines whether it has a
valid business relationship with ISPA, ISPC, ISPGROUP1, or ISPGROUP2.
We also have not discussed how ISPB verifies the authenticity of the
authentication route or settlement agent domain that it obtains from
the DNS.
7.1. Verification of business relationships
RADIUS proxies typically require a configuration file listing the sys-
tems with which they can communicate, and the shared secrets used in
that communication. Proxies will typically check this list in order to
make choices among the routes included in the DNS response.
7.2. Verification of authentication and accounting routes
Were an attack on the DNS to be successful, it would be possible to
insert authentication and accounting route records, to change the pri-
ority of existing authentication and accounting route records, or to
change SRV records. We discuss the effects of each of these attacks in
turn.
7.2.1. Insertion of authentication and accounting route records
By insertion of authentication and accounting route records, it would
be possible for an attacker to deny service. However, as long as the
RADIUS proxy performed a proper check on the business relationships
between itself and the domains indicated in the AR record, it would
not forward authentications to the indicated domains. In addition, the
use of mutual authentication in the accounting record transfer process
means that the attacker would also have to steal the appropriate
shared secrets or private keys in order to be able to masquerade as a
legitimate settlement agent.
7.2.2. Changing the priority of existing authentication and account-
ing route records
Since changing the priority of existing records does not result in
denial of service, or require the theft of shared secrets or private
keys, it is the subtlest form of attack. The result of this attack
would be a shift in business toward the ISPs or consortia that would
be moved up in priority. This constitutes a theft, but would not be
detectable without the use of secure DNS.
7.2.3. Changing of SRV records
Were an attacker to change the RADIUS SRV records, it would be possi-
ble to divert forwarded authentications to a bogus server. However,
Aboba [Page 10]
INTERNET-DRAFT 26 November 1996
unless the attacker had also stolen the shared secrets, the result
would be denial rather than theft of service.
8. Formal Definition of the NAI
As proposed in this specification, the Network Access Identifer may
represent either an authentication route, or a pointer to such a
route. In order to clearly distinguish the two formats, the route form
of the NAI uses the "/" character as a separator, while the pointer
form of the NAI uses a user@domain or user:domain format, where the
domain is a fully qualified domain name (FQDN). Where a pointer is
used, the domain portion of the NAI is then used to retrieve the route
via DNS lookup. A new DNS record, the Authentication and Accounting
Route (AR) record is used for this purpose.
8.1. BNF for the NAI
The grammar for the NAI is given below, using the augmented BNF nota-
tion described in reference [9].
NAI = (ROUTE [REALM "/"] USERNAME) | (USERNAME ("@" | ":") FQDN)
ROUTE = *[FQDN "/"]
FQDN = token "." token *[ "." token ]
REALM = token
USERNAME = token
As defined above, the route may consist of zero or more fully quali-
fied domain names (FQDNs), separated by a "/" character. Examples of
valid routes include:
ispgroup2.com/ispa.com/bigco.com/
ispa.com/bigco.com/
Examples of invalid routes include:
ispgroup2.com/ispa/bigco.com/
ispa.com/bigco/
Examples of valid embedded-route NAIs include:
ispgroup2.com/ispa.com/bigco.com/fred
ispa.com/bigco/fred
ispa.com/bigco.com/fred
Examples of valid Authentication and Acounting Route (AR) records
include:
bigco.com. IN AR 10 ispgroup2.com/ispa.com/bigco.com/ ispgroup2.com.
bigco.com. IN AR 10 ispa.com/bigco.com/ ispgroup.com.
eng.bigco.com. IN AR 10 ispa.com/eng.bigco.com/ ispgroup2.com.
Aboba [Page 11]
INTERNET-DRAFT 26 November 1996
9. Resolution of authentication server addresses
In order to make use of the authentication routes, it is necessary to
be able to resolve the location of a domain's RADIUS authentication
server, given the fully qualified domain name. The DNS SRV record,
defined in [10] is used for this purpose. This SRV record uses type
33.
When used to provide information on the location of the RADIUS server
within a given domain, the SRV records will be of the following form:
radiusauth.udp.bigco.com. IN SRV 10 0 1645 rad1.bigco.com.
radiusauth.udp.bigco.com. IN SRV 20 0 1645 rad2.bigco.com.
radiusacct.udp.bigco.com. IN SRV 10 0 1646 rad1.bigco.com.
radiusacct.udp.bigco.com. IN SRV 20 0 1646 rad2.bigco.com.
Here radiusauth denotes the RADIUS authentication service, while
radiusacct denotes RADIUS accounting. Since the authentication service
typically runs on port 1645 while the accounting service typically
runs on port 1646, two SRV records are required to allow them to be
resolved. Within each service, two records are used so as to provide
backup capabilities. Thus if the server rad1.bigcom.com is not avail-
able (priority 10), the server rad2.bigco.com. should be used (prior-
ity 20). The weight is used in load balancing records of the same pri-
ority level, and is set to zero when there is only one record at a
given priority level. Further details on the SRV record format are
available in [10].
10. Resolution of settlement agent addresses
SRV records will also be used for resolution of the settlement domain
(included in the AR record) to an IP address and port number. When
used to provide information on the location of the settlement server
within a given domain, the SRV records will be of the following form:
roamacct.tcp.ispgroup.com. IN SRV 10 0 1648 acct1.ispgroup.com.
roamacct.tcp.ispgroup.com. IN SRV 20 0 1648 acct2.ispgroup.com.
Here roamacct denotes the roaming accounting service. The port of
1648, as well as the TCP transfer method are used purely for illustra-
tion, since we do not yet have a proposal for the accounting transfer
protocol.
11. Acknowledgements
Thanks to Glen Zorn and Gurdeep Singh Pall of Microsoft, Richard Perl-
man of Pacific Bell, Pat Calhoun of USR, Michael Robinson of Asiainfo,
and Ian Duncan of Newbridge Networks, for many useful discussions of
this problem space.
Aboba [Page 12]
INTERNET-DRAFT 26 November 1996
12. References
[1] B. Aboba, L. Liu, J. Alsop, J. Ding. "Review of Roaming Imple-
mentations." draft-ietf-roamops-imprev-00.txt, Microsoft, Aimnet, i-
Pass Alliance, Asiainfo, September, 1996.
[2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf-
roamops-roamreq-00.txt, Microsoft, October, 1996.
[3] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authen-
tication Dial In User Service (RADIUS)." draft-ietf-radius-
radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
[4] C. Rigney. "RADIUS Accounting." draft-ietf-radius-
accounting-05.txt, Livingston, July 1996.
[5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft-
ietf-pppext-l2tp-00.txt, Ascend Communications, August, 1996.
[6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little.
"Point-to-Point Tunneling Protocol -- PPTP." draft-ietf-pppext-
pptp-00.txt, Ascend Communications, June, 1996.
[7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft-
zorn-radius-tunnel-auth-00.txt, Microsoft Corporation, October, 1996.
[8] B. Aboba. "Implementation of Mandatory Tunneling via RADIUS."
draft-aboba-radius-tunnel-imp-01.txt, Microsoft Corporation, October,
1996.
[9] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1."
draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
[10] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location
of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter-
prises, October 1996.
13. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 13]
