High Expectations for 3G-But What About the 3 As?

As we move toward 3G, wireless products increasingly will enable true mobile computing. The expectation will be that devices communicate securely, constantly, and from whatever network they are attached to.

With hundreds of millions of mobile devices expected to dwarf even the Internet population of computers, remote user authentication for each device will become an increasingly daunting dilemma.

One of the biggest concerns involves existing protocols for authorization, authentication and accounting (AAA) between network access servers (NASs) and central authentication and authorization servers (ASs).

AAA of emerging tunnel endpoints will require ever-more remote user authentication and complex relationships among users and their organizational application servers. Today, user authentication has to take place at the application server, especially now that there can be multiple NASs used by an ISP.

However, most agree end-to-end security cannot be offered by the existing de facto standard, RADIUS (remote authentication dial-in user service), used among NAS and RADIUS server vendors since the early 1990s.

The Rise and Fall of RADIUS

RADIUS was originally designed as a “lightweight protocol,” according to Carl Rigney, who worked with Livingston Enterprises, which originally wrote RADIUS. “RADIUS was originally designed because NAS memory was small and dialing into ISPs hadn’t reached the scale it has today.”

RADIUS was invented with a “hop-by-hop” security model, created for cases when a NAS would check with a central AS (authentication server). Thus, the trust model was essentially point-to-point.

The user authenticated himself or herself to the NAS, and the NAS authenticated itself with the AS.

“Equipment that is commonly referred to as a NAS is the result of an evolutionary change in the usage of a device known as a terminal server,” notes Mark L. Stevens of Ellacoya Networks, a company focused on creating software-based equipment platforms that enable the delivery of value-added broadband application and content services through its Service Generation System™. He explains that early on, these terminal servers enabled remote terminals and remote computers running terminal emulator programs to connect to larger, centralized host computers by relieving the host of the work involved in interacting with multiple modems. “Terminal servers handled modem operations and the reception of incoming calls, but simply passed the resulting connections through to the host computer system,” he adds. Authentication and authorization, therefore, remained the responsibility of the host computer systems.

But as the Internet increased in popularity and TCP/IP implementations became available for personal computers, there came a desire to connect large numbers of remote systems directly to the Internet via modem. “Terminal servers began to evolve into NASs,” Stevens continues.

To accomplish this transition, new protocols had to be developed. SLIP and subsequently PPP were developed to simulate a direct connection to the Internet over a serial connection provided by two modems. “In initial implementations,” notes Stevens, “authorization and authentication responsibilities remained within the host computer to which the terminal server was attached, and the client’s TCP/IP traffic continued to flow through the host computer system before it could be injected into the network.”

To improve scaling and performance, vendors added ports to the terminal server, which enabled the terminal server to be directly connected to a network, and renamed the devices network access servers.

Using SLIP or PPP to make the connection between the modems and the direct connection to the network, NASs could handle dozens of calls and provide direct connectivity to the Internet. “But the devices continued to have no built-in ability to authorize and authenticate the incoming calls,” Stevens says. As a result, RADIUS emerged to define communication between NASs and a host responsible for authorizing and authenticating incoming connection requests.

As RADIUS usage began to expand, it also was used for applications where a single organization did not control both the NAS and the AS.

Trust Me

Under RADIUS, everyone implicitly has to accept “transitive trust”—which makes the model very weak, explains Erik Guttman, senior staff engineer with Sun Microsystems.

“If A and B both trust the roaming consortium, A can send a message to the roaming consortium broker, and the broker can forward it to B. Say a roaming user dials into ISP A on the East Coast, which is part of a roaming consortium with the user’s ISP B on the West coast. ISP A has to access the AS from ISP B, even if A and B do not trust each other, except insofar as they are members of the roaming consortium!” proclaims Guttman, who believes the existing model inherently puts all the trust into a single point of potential failure—the roaming consortium broker.

Additionally, he says, “it makes it impossible to establish ‘nuanced trust relationships’ among different parties, and allows, even encourages the broker to manipulate the messages sent by A before forwarding them to B—not to mention the session is ‘visible’ to all parties along the way.”

When more than one broker is involved, the situation becomes even more complicated and less secure. As architectures have to scale to support more active users and accounts, which is inevitable, as dialing into ISPs will reach a much greater scale than that of today.

The Metamorphosis

There is no question the requirements for a protocol today are much different from the early 1990s, when access servers supported less than 100 ports. Today, these same access routers support many tens of thousands of ports. The RADIUS protocol, by design, only supports 255 outstanding requests, notes Sun Microsystems’ Pat R. Calhoun, the principal coordinator and editor of DIAMETER, which promises to be the next-generation protocol for authentication and authorization (see “Next-Gen Protocol”).

Over time, patches to RADIUS have been made public to allow it to scale better; however, the market and the technology have changed significantly enough that the RADIUS protocol cannot support the new access technologies and business needs.

“We are no longer dealing with just dial-in user authentication in European/Asian as well as North American standards-based wireless data and communications products,” says Guttman. “Roaming will no longer be a simple matter of attaching once to initiate a session from an arbitrary place. Roaming will require mobility during a session—a factor with which RADIUS was not designed to cope.”

Although proxy RADIUS is available, which enables roaming authentication, “there are aspects to wireless that need more service definitions than possible with RADIUS,” contends Guttman.

Although more dimensions and definitions have been added to RADIUS, Rigney at Livingston Enterprises concedes that “it’s inevitable we will move to the next generation of protocol.”

A comparison between RADIUS and DIAMETER can be found in an evaluation published by the Internet Engineering Task Force (IETF) Authentication, Authorization, and Accounting (AAA) Working Group at http://www.ietf.org/internet-drafts/draft-ietf-aaa-proto-eval-01.txt.

Next-Gen Protocol

DIAMETER (http://www.diameter.org) is the name for the next-generation base protocol expected to support m-commerce, Internet growth and 3G wireless access. DIAMETER is being developed under the auspices of the AAA Working Group to correct many of the problems experienced with RADIUS.

The DIAMETER base protocol, it is expected, will provide an authentication and authorization framework for mobile IP.

“Because we are no longer dealing solely with dial-in user authentication, wireless requires an entirely new architecture—one that provides hierarchical authentication and cryptographic configuration distribution mechanisms,” says Sun Microsystems’ Calhoun, the chief designer of DIAMETER.

He contends end-to-end security is provided in DIAMETER through strong cryptography, “which allows individual components of a DIAMETER message to be encrypted using the S/MIME cryptographic message syntax.” This, he says, allows endpoints to send messages protecting both the integrity and confidentiality of the message. “The broker function can then redirect A to B, supplying A with enough cryptographic configuration parameters [keys, certificates, etc.] so that A uses S/MIME protected message components to communicate with B.”

Although DIAMETER is designed to be more secure, it is still not highly available on a commercial level.

“Currently, those of us in the AAA WG are working on ensuring that DIAMETER does not have any perceived weaknesses,” notes Nortel’s Haseeb Akhtar, an active member of the working group. “Towards that end, a design team was formed and tasked to propose solutions that will ensure that DIAMETER is an airtight protocol.”

In Akhtar’s opinion, DIAMETER will become commercially available as soon as the IETF approves the drafts. “The current objective is to submit all DIAMETER drafts to the IETF April 1,” says Akhtar, noting that there have been several “bakeoffs” to test interoperability.

By June 2001, the AAA WG expects there to be a standards track AAA protocol available for use by ISPs and mobile phone operators.

As of December 2000, the IETF agreed there were a couple issues to resolve in the upcoming month, before a final version of the protocol is submitted for peer review and eventual standardization. While peer review in the IETF can take a long time, Akhtar does not expect fundamental problems, “since we have gone through so much formal processing.”

On DIAMETER, RADIUS, or RADIUS++ flexibility…

While DIAMETER may be accepted as the protocol to replace RADIUS, it is wise to note that it has broadened significantly since its inception. “It is entirely possible that it cannot be made to solve the current AAA problems,” says Stevens. The AAA problem may, therefore, not be solved by a single protocol. “It is probably reasonable to expect that a suite of protocols will be deployed to solve the problems of AAA, even though the AAA WG is only entertaining DIAMETER at the moment.”

Proponents of these protocols maintain that each is ultimately flexible because each accommodates the addition of new messages. “If you need a new message type, just define it and ask IANA [the Internet Assigned Numbers Authority] to record and post the assignment,” recommends Stevens. “The problem comes when implementers try to reuse message types, making it easy to misuse existing messages in entirely new contexts, as well as duplicate existing messages with new ones.”

Some fear that over time the “vocabulary” of a DIAMETER, RADIUS, or RADIUS++ AAA server could grow so unwieldy that cross-vendor interoperability becomes impossible.

For the time being, DIAMETER is backward-compatible with RADIUS, so that a DIAMETER server (if it were so implemented) could handle both DIAMETER and RADIUS clients.

“The point is that this migration doesn’t have to be a flag day,” says Calhoun. “On the contrary, the large installed base of RADIUS clients can continue to operate with a drop in new infrastructure.”

(For technical details, refer to ftp://ftp.ietf.org/internet-drafts. Go to draft-ietf-aaa-issues-04.txt, section 7 for known issues regarding compatibility. Also look at the framework document draft-calhoun-diameter-framework-08.txt, and the implementer’s guide to show how compatibility is actually achieved in draft-calhoun-diameter-impl-guide-04.txt.)