New spec will help secure LANs

For network managers, authenticating remote access users is a simple process: The user dials in to the enterprise, the call is diverted to a RADIUS server, the server fires off a password challenge and, if it receives the correct response, it lets the user into the LAN.

But for users already inside the firewall - those working from their desktop PCs - few authentication methods exist.

However, a proposal is before the IEEE that would extend the benefits of remote authentication to internal LAN users. And because it makes use of existing standard technologies, the new Extensible Authentication Protocol Over Ethernet (EAPOE) specification promises to do the job without adding new client software to typical desktop PCs.

The EAP part comes from the ubiquitous Point-to-Point Protocol (PPP), which activates the modems of most of today's remote users. An IETF standard, PPP is typically called on to establish peer-to-peer links.

A PPP option also allows for user authentication via either Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), either of which consults with a company's central Remote Authentication Dial-In User Service server to validate employee passwords.

One of the key features of PPP is its extensibility, and one of PPP's little-known extensions is Extensible Authentication Protocol (EAP). But where PPP offers only simple peer-peer authentication using PAP or CHAP, EAP makes it possible to use a wider range of authentication protocols.

Roots of EAPOE

EAPOE swings into action as soon as a new connection is detected by a LAN switch's Ethernet port. The switch challenges the new arrival by sending an EAPOE packet with a Request Identity message. The new device, such as a user PC, embeds its user ID into the EAPOE data field and sends the packet back to the switch.

The switch then transmits this information within an EAP Access Request message to the RADIUS server.

For communicating with RADIUS servers, the EAP packet does not have to be encapsulated in Ethernet because, as with PPP, EAP is able to use the RADIUS protocol as its transport mechanism.

The RADIUS server responds by sending an Access Challenge message back to the switch, effectively asking to see the password for that user ID. The switch encapsulates this within EAPOE and sends it to the requesting PC.

The PC then enters its password and sends it via EAPOE back to the switch. Typically, passwords are sent in encrypted format - compatibility with encryption software is another feature of EAP and, therefore, of EAPOE. The switch turns this into an Access Response EAP packet, encapsulating it in the RADIUS protocol for transmission to the RADIUS server.

Once the RADIUS server finds the user ID/password match in its database, it sends a final "success" message to the switch, which now activates the user port connection.

In a topology without I/O bottlenecks - and with reasonably fast database-search facilities - this entire process should take less than one second.

As simple as the process seems, EAPOE offers a sophisticated mechanism for securing LANs with different security topologies and with various security methods.

Also, thanks largely to a variable-length data field in EAP that can accommodate a range of security technologies, the standard is open for use with virtually any current or future security method, including MD5 challenge, token cards or even biometrics.

An IEEE working group will soon be assigned to EAPOE. Vendors backing the specification include 3Com, Cabletron, Extreme Networks, FORE Systems, Hewlett-Packard, Intel and Merit Network.

Karimi is a technology marketing manager at 3Com, and Jain is a consulting architect for 3Com. They can be reached at Hamid_Karimi @3Com.com and vipin @cmetric.com.

New spec plugs LAN security gap
Vendors get behind EAPOE. Network World, 8/23/99.

RFC 2284
The IETF's EAP standard.

EAP support in RADIUS
From the IETF.

A white paper from Microsoft
Outlining EAP support in RRAS.