ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-ietf-roamops-auth-00.txt >
26 March 1997
The Authentication and Authorization Problem in Roaming
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-roamops-auth-00.txt>, and expires October 1, 1997. Please send
comments to the authors.
2. Abstract
This document describes the authentication and authorization problems
that arise in the provisioning of dialup roaming capabilities. These
include issues relating to authentication routing as well as non-repu-
diation of Access-Accepts.
3. Introduction
As detailed in [2], solution of the authentication and authorization
problem in roaming requires several elements to be put in place:
1. A method must be provided for authentications to be routed
between the local ISP and the home authentication server. If RADIUS
as described in [3] is used for authentication, then hierarchical
authentication routing must be used in order to provide for scala-
bility, as described below.
2. A mechanism must be put in place to allow local ISP RADIUS
proxies to edit authorization attributes so as to allow these
attributes to relate to the local network.
Aboba [Page 1]
INTERNET-DRAFT 26 March 1997
3. A mechanisms must be employed to deter fraud and allow for
auditing. Such mechanisms may include non-repudiation for Access-
Accepts.
This document describes a proposed architecture for roaming authenti-
cation and authorization. Issues relevant to hierarchical authentica-
tion routing and non-repudiation are discussed.
3.1. Terminology
This document frequently uses the following terms:
Network Access Server
The Network Access Server (NAS) is the device that clients
contact in order to get access to the network.
RADIUS server
This is a server which provides for authentication/autho-
rization via the protocol described in [3], and for account-
ing as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
and accounting requests, a RADIUS proxy can be employed. To
the NAS, the RADIUS proxy appears to act as a RADIUS server,
and to the RADIUS server, the proxy appears to act as a
RADIUS client.
Network Access Identifier
In order to provide for the routing of RADIUS authentication
and accounting requests, the userID field used in PPP (known
as the Network Access Identifier or NAI) and in the subse-
quent RADIUS authentication and accounting requests, can
contain structure. This structure provides a means by which
the RADIUS proxy will locate the RADIUS server that is to
receive the request.
Roaming relationships
Roaming relationships include relationships between compa-
nies and ISPs, relationships among peer ISPs within a roam-
ing association, and relationships between an ISP and a
roaming consortia. Together, the set of relationships form-
ing a path between a local ISP's authentication proxy and
the home authentication server is known as the roaming rela-
tionship path.
4. Overview of the roaming authentication and authorization architec-
ture
The goal of the roaming authentication and authorization architecture
is to enable roaming users to be authenticated and authorized when
dialing phone numbers belonging to ISPs other than their home ISP. The
Aboba [Page 2]
INTERNET-DRAFT 26 March 1997
authentication and authorization architecture, which is shown below,
involves interactions between network devices such as NASes and
routers, authentication proxies, and authentication servers.
In this architecture, authentication proxies are used to relay authen-
tication requests from the local ISP to the home authentication
server. While the local ISP authentication proxy may edit authoriza-
tion attributes returned by the home authentication server, so as to
make them compatible with the local network, intermediate proxies MUST
NOT edit the attribute set passed to it by another proxy or the home
authentication server. This is necessary in order to ensure that crit-
ical attributes relating to security (such as tunnel attributes or
EAP-Message attributes) are not modified along the way.
In the discussion that follows, we assume that BIGCO has contracted
with ISPA to provide roaming services. In turn ISPA has joined a roam-
ing consortia ISPGROUP. User Fred then travels to another part of the
world and dials into a NAS device operated by ISPB, who has also
joined roaming consortia ISPGROUP. Fred attempts to authenticate to
the NAS device as fred@bigco.com, using the PPP protocol and an
authentication protocol such as PAP, CHAP, or EAP.
+------------+ +------------+ +------------+
| | | | | |
| ISPB | | BIGCO | | ISPA |
| Router | | RADIUS |<---------| RADIUS |
| | | Server | | Proxy |
| | | | | |
+------------+ +------------+ +------------+
| ^
| |
RADIUS | |
Protocol | Inter-organizational |
| Authentication Events |
| |
| |
V V
+------------+ +------------+
| | | |
| ISPB | Inter-organizational | ISPGROUP |
| RADIUS |<----------------------------->| RADIUS |
| Proxy |\ Authentication Events | Proxy |
| | \ | |
| | \ | |
+------------+ \ +------------+
^ \
| \ Intra-organizational
RADIUS | \ Authentication Events
Protocol | \
| \
| \
| \
| \
+------------+ +------------+
Aboba [Page 3]
INTERNET-DRAFT 26 March 1997
| | | |
| ISPB | | ISPB |
| NAS | | RADIUS |
| | | Server |
| | | |
+------------+ +------------+
^
|
PPP |
Protocol |
|
V
+------------+
| |
| |
| Fred |
| |
| |
+------------+
5. Authentication and authorization recommendations
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. How the authentication is routed
depends on the security mechanisms employed by the protocols used to
communicate between the NAS and the home ISP's authentication server,
as well the roaming relationships established between the parties.
5.1. Hierarchical authentication routing and RADIUS
Use of proxy RADIUS and hierarchical authentication routing is pro-
posed for use in situations where the members of the roaming consortia
desire to use RADIUS as described in [3] as their authentication pro-
tocol. In these cirumstances, authentication traffic will be secured
via shared secrets, and hierarchical authentication routing must be
employed to enhance scalability. In order to support hierarchical
authentication routing, it is recommended that a Roaming Relationship
(REL) record be added to the DNS, as described in [8].
Note that direct contact between the local NAS and the home RADIUS
server is not necessarily desirable, regardless of whether public key
authentication technology is available. Direct contact between the
local NAS and the home RADIUS server 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 RADIUS server must be able to return configuration
attributes that the remote NAS understands. Thus authentication prox-
ies are useful for more than just authentication routing.
Aboba [Page 4]
INTERNET-DRAFT 26 March 1997
5.2. Use of RADIUS over IPSEC
In situations where members of the roaming consortia are able to sup-
port public key authentication as well as DNS Security, IPSEC and
ISAKMP, it is recommended that the working group consider optional
support for RADIUS running over IPSEC. Where RADIUS is run over IPSEC,
the RADIUS authenticator field will not be utilized, and the Signature
attribute will not be processed. Where RADIUS over IPSEC is used, the
local ISP's RADIUS proxy may be able to contact the home ISP server
directly, and negotiate a session key without the need for a shared
secret.
However, in order for direct contact to be feasible between the local
ISP proxy and the home authentication server, the home authentication
server must be prepared to return its roaming credentials to the local
ISP proxy. This is required in order for the local ISP proxy to be
able to verify the roaming relationship path. As a result, it will not
be necessary for the authentication to traverse this path in order to
verify it.
Roaming credentials consist of a series of tokens testifying to the
validity of the roaming relationship path stretching between the local
ISP and the home authentication server. For example, if BIGCO has del-
egated roaming authority to ISPA, then its roaming credentials will
include a token signed by ISPA testifying to the validity of the roam-
ing relationship between BIGCO and ISPA. The tokens returned by the
home authentication server would include the following:
{PK_BIGCO, Expiration date}^SK_ISPA
{PK_ISPA, Expiration date}^SK_ISPGROUP1
5.3. Non-repudiation of Access-Accepts
In situations where members of the roaming consortia are able to sup-
port public key authentication, it may be desirable to support non-
repudiation of Access-Accepts as an optional capability. This capabil-
ity is supported via inclusion of a token by the home authentication
server within the Access-Accept. This token consists of a message
digest, signed by the home authentication server. The message digest
is computed over the Access-Accept, with the portions of the packet
which may be acceptably modified (such as the authenticator field) set
to zero. In order to proof of a user login, it has been suggested that
the signature also be applied to a transcript of the authentication
conversation between the NAS and the authenticating peer.
Please note that support for non-repudiation in Access-Accepts is only
valuable as an integrity-checking mechanism when the local ISP proxy
cannot contact the home authentication server directly, and thus there
is concern over modification of the Access-Accept by intermediate
proxies. However, in addition, it may be desirable to include the non-
repudiation token with the accounting record in order to demonstrate
its authenticity.
Aboba [Page 5]
INTERNET-DRAFT 26 March 1997
6. Hierarchical authentication routing architecture
6.1. Justification for hierarchical authentication routing
Since the RADIUS protocol is commonly implemented both by NAS vendors
as well as by ISPs, RADIUS is today commonly used as a mechanism for
roaming authentication and authorization.
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 either in proxy configuration
files or via DNS as described in [8]. Note that even if DNS is used,
configuration files are still necessary in cases where proxy RADIUS is
employed, since they provide the RADIUS proxy with the list of shared
secrets. This list of shared secrets is also a list of systems whose
owners have a Roaming relationship with the configuring ISP.
Hierarchical authentication routing is implemented via a multi-tier
RADIUS proxy system. This allows ISPs to maintain shared secrets only
with the roaming consortia itself or other consortium members, as well
as with customers who have delegated roaming responsibilities to them.
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 500 roaming consortia members, each with 500
corporate customers, this translates to 250499 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
Aboba [Page 6]
INTERNET-DRAFT 26 March 1997
the case of 500 roaming consortia members, each with 500 corporate
customers, this translates to 999 shared secrets per ISP, a dramatic
reduction.
If the RADIUS proxies of each ISP contact a consortium proxy, the num-
ber of shared secrets is further reduced. In this case, a given proxy
needs to maintain m+1 shared secrets, while the consortium proxy needs
to maintain n shared secrets, one for each consortium member.
6.2. Details of hierarchical authentication routing
As described in [8], Roaming Relationship (REL) RRs in the DNS are
used in order to construct the roaming relationship path. Please note
that while DNS Security may be used to verify the integrity and
authenticity of the REL RRs, it does not vouch for the validity of the
roaming relationships themselves. As a result, where it is not possi-
ble for the local ISP proxy to contact the home authentication server
directly and retrieve roaming credentials, it is necessary for the
local ISP to route the authentication over the roaming relationship
path in order to verify it.
As a result, in cases where hierarchical authentication routing is
required, the roaming relationship path is used as the authentication
route. The route is typically constructed by the local ISP proxy,
which includes it within the Authentication-Route attribute included
in the RADIUS Access-Request. In order to ensure that the accounting
agent, who will subsequently receive an accounting record has also had
the opportunity to vouchsafe for the validity of the roaming relation-
ship path, the accounting agent is typically included as the first hop
in the roaming relationship path.
In order to construct the roaming relationship path, the local ISP
proxy begins by checking whether the home authentication domain is
listed in its configuration files as an accounting agent. If so, then
the authentication request (and the subsequent accounting record) is
routed to the home authentication server directly; if not, then the
local ISP queries for the REL RR of the home authentication domain.
Typically such a query will return one or more ISPs or roaming consor-
tia to whom the home authentication domain has delegated roaming
authority. Once again, the local ISP proxy checks whether one of these
domains is listed within its configuration files as a valid accounting
agent. If so, then it routes the authentication (and subsequently the
accounting record) to the accounting agent. If not, then it queries
the DNS for the REL RRs for these ISPs and/or roaming consortia. The
process typically results in a roaming relationship path within a max-
imum of two hops.
Once the roaming relationship path has been constructed by the local
ISP, it is included in an Authentication-Route attribute within the
Access-Request. Intermediate proxies MUST forward the authentication
along the requested Authentication-Route if it is possible to do so.
Aboba [Page 7]
INTERNET-DRAFT 26 March 1997
7. Proposed RADIUS attributes for roaming
7.1. Authentication-Route
Description
This attribute allows an authentication route to be included within
a RADIUS Access-Request or Access-Reply sent between RADIUS prox-
ies. RADIUS proxies receiving a message with an Authentication-
Route attribute MUST honor the attribute if it is possible to do
so.
A summary of the Authentication-Route attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
73 for Authentication-Route
Length
>=3
String
The String field includes the authentication route, which is
represented as a series of domains separated by /. For example,
a valid authentication route is ispb.com/isp-
group.com/ispa.com/bigco.com/
7.2. Authentication-Token
Description
This attribute allows an authentication server to include a signed
token within a RADIUS Access-Accept, in order to provide for non-
repudiation.
A summary of the Authentication-Token attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
Aboba [Page 8]
INTERNET-DRAFT 26 March 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
74 for Authentication-Token
Length
?
String
The String field includes the authentication token.
7.3. Roaming-Credentials
Description
This attribute allows a home authentication server to include its
roaming credentials within a RADIUS Access-Accept, thus enabling
direct contact between the local ISP proxy and the home authentica-
tion server. More than one Roaming-Credentials attribute may be
included within an Access-Accept, in order to allow the home
authentication server to present sufficient credentials to validate
the roaming relationship path between itself and the local ISP.
A summary of the Roaming-Credentials attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
75 for Roaming-Credentials
Length
?
String
The String field includes the roaming credentials, which consist
of tokens with the following structure:
Aboba [Page 9]
INTERNET-DRAFT 26 March 1997
{PK_DelegatingEntity, Expiration date}^SK_SigningEntity
8. Security Concerns
8.1. Attacks on the DNS servers
In the absence of DNS security, an attacker were to gain control of
the DNS server hosting the BIGCO zone files, they could change the REL
and SRV records to route roaming authentication and accounting
requests to bogus servers.
However, since RADIUS is secured by a shared secret, this attack would
not result in more than a denial of service, as long as the attacker
did not also obtain the shared secrets which would allow the bogus
RADIUS server's Access-Reply message to be accepted. This is why it is
important that roaming relationship paths be verified either via roam-
ing credentials or via hierarchical authenticaton routing.
8.2. Attacks against RADIUS proxies
Without non-repudiation of Access-Accepts, it is possible that a prox-
ied authentication may be modified in transit between the home authen-
tication server and the local ISP proxy. Thus, it is possible for a
compromised RADIUS proxy to modify security attributes returned by the
home ISP, or even to change a NAK to an ACK.
Without non-repudiation, it is also not possible for an accounting
agent to confirm that the home ISP authentication server authorized a
session. This may present problems if a dispute should arise over the
home ISP's roaming charges.
Note that even with public key authentication facilities, there is no
guarantee that the local ISP proxy will not modify security
attributes. In order to guarantee that the authorization attributes
will be compatible with the local network, the local ISP proxy will
typically edit the authorization attributes returned by the home ISP's
authentication server.
9. Acknowledgments
Thanks to Glen Zorn of Microsoft and Pat Calhoun of USR for useful
discussions of this problem space.
10. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen-
tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass
Aboba [Page 10]
INTERNET-DRAFT 26 March 1997
Alliance, Asiainfo, January, 1997.
[2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf-
roamops-roamreq-03.txt, Microsoft, March, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
1997.
[5] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1."
draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
[6] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location
of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter-
prises, October 1996.
[7] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security
Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August,
1996.
[8] B. Aboba. "The Roaming Relationships (REL) Record in the DNS. "
draft-ietf-roamops-dnsrr-03.txt, Microsoft, March, 1997.
[9] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius-
ext-00.txt, Livingston, January, 1997.
[10] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[11] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." draft-bradner-key-words-02.txt, Harvard University, August,
1996.
[12] B. Aboba. "The Network Access Identifier (NAI)." draft-ietf-
roamops-nai-02.txt, Microsoft, March, 1997.
11. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 11]
Datatracker
draft-ietf-roamops-auth-00
This is an older version of an Internet-Draft that was ultimately published as RFC 2607.
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2607.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |