Secure Shell standard moving forward

12

Author: Joe 'Zonker' Brockmeier

The Secure Shell protocol is one step closer to becoming an Internet Engineering Task Force (IETF) standard. Earlier this month SSH Communications Security Corp. announced that the Secure Shell protocol specifications have reached Proposed Standard status.

Various implementations of the Secure Shell protocol are already in widespread usage, so one might wonder whether this new status will have any impact — particularly for the OpenSSH project, which is widely used on Linux and BSD-based systems.

IETF standards define a number of protocols that make the Internet what it is today. For example, TCP/IP, the Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Hypertext Transfer Protocol (HTTP) are all standards that most users depend on every day. Without adherence to these standards it would be difficult for users and devices to communicated effectively using different mail clients and servers, Web browsers, and network adapters.

The proposed standards documents for SSH, RFCs 4250 through 4256, cover SSH authentication, transport layer, connection protocol, using DNS to publish SSH key fingerprints, and other protocol information required to allow multiple implementations of SSH to communicate.

A long time in the making

According to Timo Rinne, CTO of SSH Communications Security, the standards process for SSH has been going on for about seven years, subsequent to the establishment of the IETF’s Secure Shell working group in February 1997. Rinne said that it is not unusual for a standard to take a long time to jell, and some working groups never get to the point of finishing an IETF standard.

However, if this is business as usual, then the IETF process may require some renovation. OpenSSH developer Damien Miller said that SSH’s experience demonstrates “how the IETF process fails to work effectively: despite having back in 2000 a set of Internet drafts sufficient for implementors to create interoperable SSH implementations (OpenSSH is one who worked off these drafts), and despite SSH being widely deployed and the de facto standard for remote Unix logins, the process took five years to make relatively minor tweaks to these documents and publish them as RFCs.

“If there were substantive changes or deep arguments over the protocol architecture, then this would be fair enough, but there weren’t — the working group became a talk-fest. That is not good enough for such a critical protocol.”

Rinne couldn’t give a specific date when the proposed standard might pass to the next stage. However, he did say that “the time for that to happen is much shorter.”

Interoperability

Many Linux users will wonder whether the draft standard is compatible with OpenSSH. OpenSSH is the default SSH implementation for virtually all Linux distributions and flavors of BSD, including Mac OS X, and seems to be the dominant implementation of SSH in use today.

According to Miller, the OpenSSH project performs regular surveys, similar to Netcraft’s Web server surveys, to determine the number of servers using OpenSSH and other implementations of SSH. The results indicate that OpenSSH is far and away the leading implementation. The most recent results published were from September 2004, but Miller said that a new set should be published shortly, and will show OpenSSH having more than 85% of the server market.

In practice, Miller said that he didn’t recall significant problems “between OpenSSH and other free implementations,” but noted that a few problems had been reported between OpenSSH and SSH Communications’ implementation. “We don’t have licenses for their software and we can’t afford to contaminate our free development work by having their code anywhere near our systems.”

The OpenSSH team is interested in maintaining compatibility with other implementations of the SSH protocol. Miller said that the OpenSSH team would look at fixing any violations of the SSH specification, so long as they didn’t compromise security. In addition, he said that the team wouldn’t “blindly chase conformance or features if they required patented methods, a high degree of complexity, or they are just plain dumb.”

Unfortunately, the IETF does permit patented methods in its standards. Rinne said he was not aware of any patents in the core SSH standards, though he said he was aware of “some patents or patent applications used in conjunction” with the standards.

If any of the workgroup members held patents related to the core standards, Rinne said they should be disclosed in an intellectual property rights (IPR) statement. “The only IPR statement is that SSH is our trademark, and that is mentioned because the IETF says that if someone claims a trademark, it has to be mentioned.”

What difference does it make?

Since SSH is already a well-established protocol, one might wonder whether the IETF standard really matters. Miller said that it’s important for SSH to be standardized, but “I don’t expect to see any immediate changes as the result of the publication of the standards as RFCs.

“Over the last couple of years there have been only one or two real changes to the SSH protocol made by the working group — most of the activity has been fiddling with wording. So any implementation written to conform to the draft protocol over the last couple of years is already conformant to the RFCs.”

However, the fact that the SSH core protocols are becoming “official” may be of great interest to some organizations. Rinne pointed out that, as an administrative issue, many government organizations require that a product conform to a published standard. “That is actually more relevant than one might imagine.”