[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
ROAMOPS Working Group                                      Bernard Aboba
INTERNET-DRAFT                                                 Microsoft
Category: Standards Track
11 February 1999

                       Certificate-Based roaming

1.  Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working 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 material or to cite
them other than as "work in progress."

To view the list Internet-Draft Shadow Directories, see

The distribution of this memo is unlimited.  It is filed as <draft-ietf-
roamops-cert-00.txt>, and  expires August 1, 1999.  Please send comments
to the authors.

2.  Copyright Notice

Copyright (C) The Internet Society (1999).  All Rights Reserved.

3.  Abstract

To date, roaming implementations have been based on the concept of proxy
chaining, where packets are routed between the NAS and home server
through a series of proxies.  While commonly used, proxy chaining
introduces difficult security problems that have prevented its
implementation on a wide scale.

This document describes a new approach to roaming based on certificates
that eliminates the need for proxy chaining. As described, this approach
provides improved security as well as scalability.

Aboba                        Standards Track                    [Page 1]

INTERNET-DRAFT          Certificate-Based Roaming       11 February 1999

4.  Introduction

As noted in [1], roaming implementations have been based on the concept
of proxy chaining, where packets are routed between the NAS and home
server through a series of proxies.  Current roaming implementations
based on proxy chaining as described in [8] provide only hop-by-hop
security, guarding only against modification of packets in transit
between hops.  This makes it possible for untrusted proxies to modify
packets sent between a NAS and a home server without detection, as well
as to decrypt PAP passwords, Tunnel passwords, and other hidden
attributes which are available to proxies in cleartext.  These security
issues have to date prevented the implementation of roaming on a wide

This document describes a new approach to roaming based on certificates
that eliminates the need for proxy chaining. As described, this approach
provides improved security as well as scalability.

5.  Requirements language

In this document, the key words "MAY", "MUST,  "MUST  NOT",  "optional",
"recommended",  "SHOULD",  and  "SHOULD  NOT", are to be interpreted as
described in [7].

6.  Certificate-based roaming

In certificate-based roaming, the user utilizes a public-key based
smartcard or other certificate in order to authenticate to the local
ISP. This is accomplished through use of an EAP-based certificate
authentication protocol such as EAP-TLS, described in [11].

Through use of certificate-based authentication, it is possible for the
local ISP authentication server to verify the user's identity without
the need to proxy the authentication to the home server.  In order to
achieve proxy-less authorization, the authorization parameters are
derived from the certificate. This can be achieved either by embedding
the authorization parameters directly, or by deriving them from
certificate parameters such as the Network Access Identifier, described
in [3].

In this model, it is necessary for a chain of trust to be established
between the user and the local ISP. In the simplest case this can be
accomplished by presenting a certificate signed by a trusted third
party, such as a roaming association to which the local ISP belongs.
Note that in order to verify that the user certificate remains valid,
the local authentication server will typically need to check the

Aboba                        Standards Track                    [Page 2]

INTERNET-DRAFT          Certificate-Based Roaming       11 February 1999

Certificate Revocation List (CRL).

Since certificate-based roaming eliminates the use of proxy
authentication and authorization, the home server no longer receives
authentication and authorization requests from the local ISP. As a
result, a mechanism must be provided for verification of the resulting
charges. In particular, it is desirable to be able to prove that the
user requested service at the date, time and place claimed by the local

This can be achieved as part of the EAP-based certificate authentication
protocol. For example, if the user were to use a smartcard or
certificate in order to sign a ticket providing information on the
number called, NAI used, time of day, date, etc. then this ticket could
be included in the local ISP accounting packet and would represent proof
of the user access attempt. Since the time of day and NAI are embedded
in the ticket, it would not be possible to replay the ticket in order to
commit fraud.

7.  Security issues

The following security threats have been identified in roaming systems:

   Rogue proxies
   Theft of passwords
   Theft of accounting data
   Replay attacks
   Connection hijacking
   Fraudulent accounting

Certificate-based roaming reduces or eliminates each of these threats.

7.1.  Rogue proxies

In certificate-based roaming, authentication and authorization need not
be proxied from the local ISP to the home server. As a result, where the
local ISP is operating a dedicated network, the authentication request
never leaves the local ISP domain and the risk of rogue authentication
proxies is eliminated.

The risk of rogue accounting proxies is also reduced, since it is no
longer necessary to proxy the accounting packets back to the home server
in order to provide proof of usage. Since the user signs a ticket
certifying the access attempt as part of authentication, it is only
necessary to send the accounting packet to the settlement agent. If
audited, the settlement agent can then produce the ticket to provide

Aboba                        Standards Track                    [Page 3]

INTERNET-DRAFT          Certificate-Based Roaming       11 February 1999


7.2.  Theft of passwords or keys

In certificate-based roaming, no passwords are sent in the clear, and it
is not necessary to derive a session key unless PPP encryption is
desired. Avoiding key derivation reduces the need to transmit the
derived key between the authentication server and the local ISP NAS
handling the user, this eliminating the risk of key compromise.

7.3.  Integrity and confidentiality of accounting data

While certificate-based roaming does not provide for confidentiality in
accounting data, it does provide for integrity protection through use of
a digital signature.

7.4.  Replay attacks

By signing a ticket including the time of day, NAI and called phone
number, certificate-based roaming eliminates the risk of replay attacks.

7.5.  Connection hijacking

Since certificate-based roaming avoids proxying of authentication and
authorization, the risk of connection hijacking is reduced.  This risk
can be further minimized via integrity protection during the user
authentication process, thereby preventing modification of the packets
in transit.

7.6.  Fraudulent accounting

Through use of a signed ticket, certificate-based roaming prevents
accounting for non-existent sessions. It does not however prevent
submission of exaggereated session times for actual sessions.

8.  References

[1]  Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming
     Implementations", RFC 2194, September 1997.

Aboba                        Standards Track                    [Page 4]

INTERNET-DRAFT          Certificate-Based Roaming       11 February 1999

[2]  Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming
     Protocols",  RFC 2477, January 1999.

[3]  Aboba,  B.,  and  M.  Beadles,  "The Network Access Identifier",
     RFC 2486, January 1999.

[4]  Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote
     Authentication Dial In User Service (RADIUS)", RFC  2138, April,

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

[6]  Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC
     1321, April 1992.

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

[8]  Aboba, B., Vollbrecht, J.R., "Proxy Chaining and Policy
     Implementation in Roaming", Internet draft (work in progress),
     draft-ietf-roamops-auth-09.txt, December 1998.

[9]  Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol
     (EAP)", RFC 2284, March 1998.

[10] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246,
     November 1998.

[11] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", draft-
     ietf-pppext-eaptls-05.txt, Internet Draft (work in progress),
     January 1999.

9.  Acknowledgments

Thanks to Glen Zorn of Microsoft for useful discussions of this problem

Aboba                        Standards Track                    [Page 5]

INTERNET-DRAFT          Certificate-Based Roaming       11 February 1999

10.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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

11.  Full Copyright Statement

Copyright (C) The Internet Society (1999).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE

12.  Expiration Date

This memo is filed as <draft-ietf-roamops-cert-00.txt>, and  expires
August 1, 1999.

Aboba                        Standards Track                    [Page 6]