Mobile security flaw delivers a punch

Backers of IPv6 - a long-anticipated upgrade to the Internet's main communications protocol - have suffered another setback, as security experts punched holes in their planned strategy for supporting mobile communications.

The discovery of security flaws in the proposed Mobile IPv6 protocol means the Internet Engineering Task Force (IETF) will have to develop a new method for authenticating roaming devices that use IPv6 addresses. This development means delays of months for Mobile IPv6, which was conceived a decade ago and thought to be in its final form.

The problems with Mobile IPv6 are frustrating for IPv6 proponents, who view wireless applications as the likely first adopters of IPv6. This frustration was evident at a meeting of the IETF's Mobile IP working group, which was held in Minneapolis on March 22.

"It's a setback for those who are eager to get IPv6 out there," says Steve Deering, a Cisco engineer who helped design IPv6 and serves on the IETF's Internet Architecture Board. "The Mobile IP working group has been working on this since 1991. It's been a long process."

Deering says the Mobile IP working group was blindsided by the security problems. "The IETF's security people were not paying close attention to Mobile IPv6, and then they discovered a significant problem," Deering says.

"This is a real kink in IPv6 deployment," adds Jim Bound, a principal software architect at Nokia Networks and chair of the IPv6 Forum's technical directorate. "We need a spec in the market."

Developed by the IETF, IPv6 solves the network address limitations of the current IPv4 protocol by replacing IPv4's 32-bit addresses with 128-bit addresses. Because of its longer addresses, IPv6 can support a virtually limitless number of individually identified systems on the 'Net - which is critical for wireless applications - while IPv4 can support only a few billion systems. Despite this advantage, IPv6 has been slow to catch on, and few commercial products are available.

On the bright side, Mobile IPv6 problems are not expected to delay the European wireless community's Third-Generation Partnership Project (3GPP), which plans to use IPv6 but has its own security architecture.

"3GPP mandates IPv6 but not Mobile IPv6," Deering says. "This will not slow down 3GPP."

Developed by the IETF, Mobile IPv6 adopts a new strategy for securing wireless devices that roam around the Internet. A roaming user needs to keep getting new local IP addresses and tell his home address that he's moved. With IPv4, a roaming device is authenticated through its home address, and all communications to that device pass through the home address before being sent to the temporary location.

Mobile IPv6 creates a new class of messages called binding updates that confirm the identity of a device as it moves to a new location. Binding updates are a shortcut designed to speed wireless communications that use IPv6. Once the binding update is authenticated, communications go straight to the new location without passing through the home address.

Originally, the Mobile IP working group planned to use the existing protocol IP Secur-ity (IPSec) to secure binding update messages. But the IETF's security experts recently announced that IPSec will not work for these messages for two reasons:

- IPSec depends on a public-key infrastructure that has not yet been deployed.

- The key management component of IPSec requires heavy processing by end devices.

Because of these findings, the IETF leadership asked the Mobile IP working group to find an alternate approach for securing binding updates.

One alternative being considered is Purpose-Built Keys (PBK), which are a lighter- weight method of authorizing binding update messages so they're more appropriate for wireless devices. However, PBKs offer less security than IPSec. Three IETF leaders developed the PBK approach: Security Area Co-Chair Jeff Schiller and Transport Area Co-Chairs Scott Bradner and Allison Mankin.

PBKs would generate a temporary public/private key pair to confirm that a roaming device was the same device that started a particular communication. A new key pair would be generated before each Mobile IPv6 session and discarded when the session was complete. These temporary keys would be used only by the parties in the communication and wouldn't need to be registered with a third party. Because the keys change regularly, user anonymity would be preserved.

However, PBKs can't confirm the actual identity of the user, only the identity of the device. Even proponents of the PBK approach admit that it does not provide stronger security than is currently available with mobile IPv4 communications.

Schiller confirms that using PBKs in Mobile IPv6 would still leave communications open to "man-in-the-middle" attacks possible with IPv4. Man-in-the-middle attacks happen when a person intercepts a communication at a router along its path.

"If I had my druthers, I'd want something stronger" to secure binding updates, Schiller says. "But I'm willing to compromise. . . . The key here is adding mobility to IPv6, not making the network more secure. [Security] just can't be any worse" than with mobile IPv4.

IPv6 proponents fear that if the Mobile IP working group goes with a PBK-style approach for binding updates instead of the more-secure IPSec approach, they will eliminate one of the key advantages of migrating to IPv6.

"The major difference between mobile communications in IPv4 and IPv6 is the improved efficiency in mobile routing with IPv6. Communications should be much faster," Deering says. "We also thought it was going to be more secure. But now it doesn't look like it's going to be more secure."

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about BradnerIETFInternet Architecture BoardInternet Engineering Task ForceNokiaNokia Networks

Show Comments
[]