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

Versions: 00 01                                                         
ROAMOPS Working Group                                      Bernard Aboba
INTERNET-DRAFT                                                 Microsoft
Category: Best Current Practice
<draft-ietf-roamops-cert-01.txt>
1 April 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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

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


2.  Copyright Notice

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


3.  Abstract

This document describes how scalable, secure roaming can be supported
based on public key certificates, the Extensible Authentication Protocol
(EAP), and the RADIUS protocol.  The practices described in this
document eliminate the use of intermediate proxies, improving
scalability and security. They are compliant with the evaluation
criteria described in RFC 2477.







Aboba                        Standards Track                    [Page 1]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


4.  Introduction

As noted in [1], existing roaming implementations have largely been
based on the concept of proxy chaining, where packets are forwarded
between the NAS and home server through a series of proxies.

As described in [8], roaming implementations based on proxy chaining
typically provide only hop-by-hop authentication and integrity
protection.  These security weaknesses make proxy-based roaming
vulnerable to attack as well as susceptible to misconfiguration.
Security threats, described in [8] include theft of service as well as
misuse of hidden attributes (such as PAP passwords) by untrusted
proxies. Misconfiguration issues include policy implementation and
attribute editing, support for RADIUS extensions as described in [12],
shared secret maintenance and routing.

Note that providing end-to-end security within a proxying scheme further
increases the complexity of the system and introduces its own set of
issues. For example, in order to allow the end systems to verify message
authenticity and integrity, a keyed MAC such as that described in [6]
can be used. Alternatively, the packet may be digitally signed. Signing
each packet in a AAA exchange is computationally intensive, particularly
if EAP authentication is involved. On the other hand, a keyed MAC
requires an automated key-exchange mechanism in order to permit
deployment on a large scale, and introduces complications with respect
to policy implementation.

In order to implement policy, it is necessary to permit a proxy to send
an Accept-Reject to the NAS in cases where an Access-Accept has been
sent by the home server. As described in [8], the home server is
notified of this by having the proxy send an Accounting-Request to the
home server with Acct-Status=Proxy-Stop. However, with end-to-end
security, such policies cannot be implemented, since the NAS cannot
accept an Access-Reject that is not authenticated by the end-system
(home server). Similarly, the home accounting server cannot accept a
non-authenticated Accounting-Request from the proxy, notifying it of the
policy action.

In addition to security and policy issues, there are performance
problems with proxy-based roaming. The introduction of proxy forwarding
multiplies the number of packets that must be sent in order to
authenticate and authorize the user, increasing login time and
increasing the likelihood of a timeout.  This problem is particularly
severe when EAP authentication is used.

For these reasons, as noted in [8], proxy-based roaming is not
appropriate for wide-scale use on the Internet.




Aboba                        Standards Track                    [Page 2]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


This document describes an alternative to proxy-based roaming which is
based on the use of public key certificates and EAP authentication.
Since public key authentication allows the local RADIUS server to verify
the identity of the client without the need to proxy the authentication,
the use of proxies is eliminated while still permitting the local proxy
to implement policy. The result is that certificate-based roaming is
simpler and easier to implement operationally than proxy-based roaming,
as well as being more secure. As a result, certificate-based roaming is
ableto meet the criteria outlined in [2] without requiring the
development of a new AAA protocol.

In order to implement the practices described in this document, the NAS
MUST support EAP, described in [9], as well as RADIUS extensions,
described in [12]. The local RADIUS server MUST support EAP and RADIUS
extensions as well as a public-key authentication authentication method
such as EAP-TLS, described in [11]. The client MUST support EAP as well
as a public-key authentication method such as EAP-TLS. While there is no
requirement that the home server implement EAP, EAP-TLS or even RADIUS,
it is necessary for the local RADIUS server to determine that the
certificate presented by the client remains valid. As a result, the
entities involved in the trust chain MUST provide Certificate Revocation
Lists (CRLs).


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.  Overview

In certificate-based roaming, the client authenticates to the NAS using
a public-key certificate-based authentication protocol running over EAP,
such as EAP-TLS, described in [11]. In order to permit the NAS to handle
a variety of authentication protocols without understanding the details,
in EAP [9] the NAS acts as a "pass through" device, forwarding EAP
packets between the client and the local ISP RADIUS server, using the
RADIUS extensions documented in [12].

A diagram of the authentication, authorization and accounting process is
shown below:

     +------------+
     |            |
     |   Client   |
     |            |



Aboba                        Standards Track                    [Page 3]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


     +------------+
           |
     PPP   |
     EAP   |
           V
     +------------+        +------------+        +------------+
     |            | RADIUS | Local ISP  |        | Certificate|
     |    NAS     |<------>| Auth       |<------>| Revocation |
     |            |        | Server     |        | List       |
     +------------+        +------------+        +------------+
           |
    RADIUS |
           |
           V
     +------------+                              +------------+
     |   Local    |                              | Roaming    |
     |   ISP      |      Accounting              | Consortium |
     | Accounting |----------------------------->| Billing    |
     |   Server   |      Data                    | Server     |
     +------------+                              +------------+

Through use of certificate-based authentication, it is possible for the
local ISP RADIUS server to verify the user's identity without the need
to proxy the authentication to the home server.  The use of public key
certificates makes this possible, since the local ISP server is capable
of verifying that the user has access to the private key corresponding
to the public key included on the user's certificate. Note however, that
as part of the authentication process, the local ISP server will need to
check for revocation of the certificates in the trust chain.  Depending
on the trust model, one or more Certificate Revocation List (CRL)
servers may be contacted.These may include CRL server within the home
domain or that of the roaming consortium.

Since the home server is not involved in the RADIUS
authentication/authorization conversation, the authorization attributes
are determined by the local ISP, based on information provided in the
authentication process.  For example, the local ISP could determine the
authorization profile based on the realm included in the Network Access
Identifer (NAI) described in [3], or based on the Certifying Authority
(CA) included in the user certificate.  Today, the most frequently
provided roaming service is PPP access to the Internet, so that realm or
CA-based authorization is adequate in most cases. Note that per-user
authorizations can be supported within certificate-based roaming without
requiring the local RADIUS server to proxy the request back to the home
server. This can be acomplished via use of attribute certificates.

In certificate-based roaming, accounting services can be provided either
via session records or in real time via RADIUS Accounting, described in



Aboba                        Standards Track                    [Page 4]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


[5]. Note that since the home server is not involved in the
authentication and authorization process, the local ISP MAY wish to
provide the roaming consortia or home organization a means to audit the
accounting information. One possible means of demonstrating the
authenticity of the accounting data is to include credentials supplied
by the user.


6.1.  Authentication



6.1.1.  Authentication conversation

As noted in [9], the EAP conversation between the client and NAS
typically begins with the NAS sending an EAP-Request/Identity message to
the client.  The NAS then sends a RADIUS Access-Request to the local ISP
RADIUS server, containing an EAP-Message attribute. Based on the Access-
Request, the local ISP RADIUS server determines the EAP method to be
used, and sends an Access-Challenge containing an EAP-Response attribute
to the NAS.  Since certificate-based roaming does not involve proxies,
the determination of the client's EAP type MUST be made based on the
Network Access Identifier (NAI) supplied by the client, as described in
[3]. For example, the local ISP RADIUS server MAY be configured to use a
given EAP authentication type for all members of a given realm, or it
MAY implement a default type.  However, since the client certificate has
not yet been presented to the local RADIUS server, information on the
certificate such as the certificate authority, or other attributes
cannot be taken into account in determining the EAP authentication
method to be used to authenticate the client.

The EAP conversation between the local ISP RADIUS server and the client
continues as described in [12] with the NAS serving as a passthrough
device until the NAS receives an EAP-Success or EAP-Failure message.

In order to implement certificate-based roaming, the client MUST support
a certificate-based EAP authentication method such as EAP-TLS, described
in [11]. EAP-TLS, which is based on the TLS protocol described in [10],
supports mutual authentication as well as key derivation. As a result,
it permits the client to authenticate the RADIUS server as well as for
the RADIUS server to authenticate the client. Note that since the client
is not yet online, it is not possible for it to check for revocation of
the server's certificate.  However, the client MAY check for server
certificate revocation after access has been granted.  Since the RADIUS
server has Internet connectivity, it MUST check whether the client's
certificate has been revoked prior to granting access.





Aboba                        Standards Track                    [Page 5]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


6.1.2.  Trust models

In proxy-based roaming, the home server demonstrates willingness to pay
by responding to the proxied Access-Request with an Access-Accept. In
certificate-based roaming, the home server is not involved in the
authentication/authorization conversation, so that another approach is
needed.

In order for the local ISP to be willing to grant the client access to a
Point of Presence (POP), it is necessary for a chain of trust to be
established between the client and the local ISP. In the simplest case
this can be accomplished by having the client present 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 client
certificate remains valid, the local authentication server MUST check
the Certificate Revocation List (CRL) maintained by the certificate
authority.  For the simple case, this implies that the roaming
association would issue and revoke roaming certificates itself.

However, rather than dealing with end-users, the roaming association may
prefer to only issue roaming certificates to participating ISPs or
customers such as BIGCO.  This allows the roaming association to
delegate roaming certificate issuance and maintenance to other trusted
entities. In this case, it is necessary for the client to submit a
certificate chain, providing not only the roaming certificate issued by
an ISP or company, but also the company or ISP roaming certificate
issued by the roaming association. The combination of these roaming
certificates then establishes the required chain of trust.

Note that the local ISP RADIUS server MUST check for revocation of each
certificate presented in the certificate chain. Thus, the local ISP
needs to check not only that the user certificate has not been revoked
by the home ISP or company, but also that the home ISP or company's
certificate has not been revoked by the roaming association.


6.2.  Authorization and policy

Once the client has authenticated, it is necessary for the local RADIUS
server to formulate the authorization attributes to be returned to the
NAS. These attributes can be determined by information provided during
the authentication, such from the NAI realm or the certificate
authority, as well as by policy. For example, the local ISP could
provide a default set of attributes for all non-local realms, or for all
users whose chain of trust includes a given roaming association. It is
also possible for the local RADIUS server to modify the attribute set
based on policy, i.e. to return a smaller Session-Time when twenty or
more users are logged in from a given realm.



Aboba                        Standards Track                    [Page 6]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


Note that without attribute certificates it is not possible to support
per-user authorizations. For example, if Bob and Jane have certificates
signed by the same CA, and if it is desired to treat bob@bigco.com and
jane@bigco.com differently, then this cannot be accomplished based
solely on the NAI and the certifying authority. Some other information
must be brought into play. Since in certificate-based roaming proxying
back to the home server is not acceptable, the required input is
supplied as part of the user's certificate.


6.3.  Accounting

Once the client has been authenticated and authorized, the local ISP
will be interested in obtaining compensation for the use of network
resources. In order to accomplish this, the local ISP can use either
real-time or batch accounting.

When batch accounting is used, the local ISP will transmit session
record batches to the settlement agent. In real-time accounting, an
Accounting-Request is sent to the settlement agent. As discussed in [8],
the settlement agent MAY respond to the request directly, or MAY proxy
it to other parties on the roaming relationship path.

Note that with certificate-based roaming, the situation differs from the
proxy approach in that the systems along the roaming relationship path
have not previously participated in a proxied
authentication/authorization conversation prior to receiving accounting
data.

This has several implications. Firstly, the systems receiving the
accounting data do not have a means to correlate the accounting
information received with a previous authentication event. In the proxy
approach, the use of a unique session-ID allows accounting records to be
matched up with the corresponding authentication/authorization request.
While in certificate-based roaming the local ISP will have contacted the
relevant Certificate Revocation List (CRL) servers in order to check for
certificate revocation, no session-ID is generated in this conversation
that would allow linking to the relevant accounting record.

Secondly, using the session-ID, in proxy roaming a home server receiving
an accounting record is able to link this back to an authentication
conversation in which the user credentials were verified. As a result,
barring replay attacks, it is possible to audit whether the accounting
data corresponds to an Access-Accept sent by the home server. This
provides some degree of protection against fraudulent submission of
accounting data on non-existent sessions.





Aboba                        Standards Track                    [Page 7]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


To provide equivalent protection in certificate-based roaming, it is
necessary for the local ISP to supply user credentials in the accounting
data. This permits parties on the roaming relationship path to verify
that a valid authentication occurred. In the case of EAP-TLS, this can
be accomplished by including the Nonce sent by the server, along with
the signed response sent by the client, using the private key. Given
these two pieces of information, and access to the client certificate,
it is possible for a third party to verify that the client was
authenticated.


7.  RFC 2477 Compliance

Certificate-based roaming complies with the evaluation criteria
specified in RFC 2477.


Connection Management
     Certificate-based roaming supports PPP, as well as IP and non-IP
     protocols.

Identification
     Certificate-based roaming supports the NAI as described in [3].

Authentication types
     Certificate-based roaming is based on EAP and certificate-based
     authentication protocols such as EAP-TLS. PAP and CHAP are not
     supported.

Scalability
     Certificate-based roaming is sufficiently scalable to allow the
     formation of roaming associations with thousands of ISP members.

RADIUS Support
     Certificate-based roaming is compatible with RADIUS-enabled devices
     implementing EAP [9] and RADIUS extensions [12].

NAS Configuration/Authorization
     Since in certificate-based roaming authorization parameters are
     determined by the local RADIUS server, a wide range of
     authorization profiles and policies may be implemented.

Address assignment/routing
     Certificate-based roaming supports dynamic address assignment.
     Static address assignment may also be supported via layer 2 or
     layer 3 tunneling.





Aboba                        Standards Track                    [Page 8]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


Layer 2 tunneling protocols
     Certificate-based roaming is compatible with layer-2 tunneling.
     Note that without attribute certificates, per-user tunneling cannot
     be supported. Thus compulsory tunnels may only be brought up based
     on on information obtained in the authentication, i.e.  realm or
     CA-based tunneling.

Layer 3 tunneling protocols
     Certificate-based roaming is compatible with Mobile IP.

Security analysis
     Certificate-based roaming addresses fraud prevention and detection
     issues through inclusion of credentials within the accounting
     packet.

Hop by hop security
     Certificate-based roaming supports hop-by-hop integrity protection
     and confidentiality via use of IPSEC.

End-to-end security
     As certificate-based roaming does not involve proxies, the
     authentication conversation occurs solely between the local NAS and
     the RADIUS server.  As a result, policy implementation is supported
     while eliminating attacks by rogue proxies.


8.  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.


8.1.  Rogue proxies

In certificate-based roaming, authentication and authorization
terminates at the local ISP RADIUS server. As a result, the risk of
rogue proxies is eliminated.






Aboba                        Standards Track                    [Page 9]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


8.2.  Theft of passwords or keys

Since certificate-based roaming only supports certificate-based
authentication without proxies, in no circumstance will the local ISP
proxy have access to PAP passwords.

While a key is generated as part of the EAP-TLS authentication, this can
be communicated between the local RADIUS server and the NAS without
passing through a proxy. In order to protect the key, IPSEC ESP SHOULD
be used between the RADIUS server and the NAS.


8.3.  Integrity and confidentiality of accounting data

Since certificate-based roaming does not involve proxies, integrity and
confidentiality of accounting data can be provided via IPSEC.


8.4.  Connection hijacking

Since certificate-based roaming avoids proxying of authentication and
authorization, the risk of connection hijacking is reduced.


8.5.  Fraudulent accounting and replay attacks

In order to prevent the local ISP from requesting payment for non-
existent sessions, it is desirable for the accounting record to include
proof of authentication. This can be provided by including the
credentials supplied by the client within the accounting record. For
example, in the case of EAP-TLS, the accounting record can include the
Nonce supplied by the server, as well as the signature returned by the
client that proves the client's possession of the private key
corresponding to the client certificate.

Since the Nonce will vary with each authentication, it is not possible
for the local ISP to replay the authentication.  This therefore limits
the local ISP's ability to fraudulently claim payment for non-existent
sessions.

Through use of a signed Nonce, certificate-based roaming prevents
accounting for non-existent sessions. Note that as with proxy roaming,
no protection is provided against submission of exaggerated session
times for actual sessions.







Aboba                        Standards Track                   [Page 10]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


9.  References


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


[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,
     1997.


[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-10.txt, February 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.




Aboba                        Standards Track                   [Page 11]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


[12] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft-
     ietf-radius-ext-03.txt, Internet Draft (work in progress), January
     1999.


10.  Acknowledgments

Thanks to Ashwin Palekar of Microsoft for useful discussions of this
problem space.


11.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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


12.  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
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."







Aboba                        Standards Track                   [Page 12]


INTERNET-DRAFT          Certificate-Based Roaming           1 April 1999


13.  Expiration Date

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















































Aboba                        Standards Track                   [Page 13]