NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Bill Sommerfeld <firstname.lastname@example.org>
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Jeffrey Schiller <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe ietf-ssh
The goal of the working group is to update and standardize the popular SSH protocol. SSH provides support for secure remote login, secure file transfer, and secure TCP/IP and X11 forwardings. It can automatically encrypt, authenticate, and compress transmitted data. The working group will attempt to assure that the SSH protocol
o provides strong security against cryptanalysis and protocol attacks,
o can work reasonably well without a global key management or certificate infrastructure,
o can utilize existing certificate infrastructures (e.g., DNSSEC, SPKI, X.509) when available,
o can be made easy to deploy and take into use,
o requires minimum or no manual interaction from users,
o is reasonably clean and simple to implement.
The resulting protocol will operate over TCP/IP or other reliable but insecure transport. It is intended to be implemented at the application level.
Submit Internet-Draft on SSH-2.0 protocol
Decide on Transport Layer protocol at Memphis IETF.
Post revised core secsh drafts
Submit core drafts to IESG for publication as proposed standard
Post extensions drafts for review
Start sending extensions drafts to Last Call
Minutes of the IETF Secure Shell (secsh) working group
Monday March 19, 2001
Minutes from notes taken by Ken Hornstein
Working Group chair: Bill Sommerfeld
We started with two announcements from folks organizing interoperability events -- Darren Moffat announced that SSH will be one of the technologies tested at the next Connectathon; see www.connectathon.org for more details. Rodney Thayer announced that he would be organizing interop tests for SSH in conjunction with an OpenPGP interop event.
Niels Provos has been doing surveys of random internet addresses looking for what versions of SSH are out there; he has found a gradual increase in the number of v2-capable and v2-only servers over time, with a significant acceleration since February of this year. Tatu Ylonen pointed out that there are at least 5 million licensed copies of clients with v2 support out there.
We then moved on to discussion of the technical issues raised during the last-call of the core documents. Most issues were uncontroversial and did not receive much discussion; some of the issues open before the meeting appear to have been resolved. Notably:
- language tags should be included on all messages, even if apparently redundant (it's simpler that way); the document should be clarified to indicate this.
- subsystems and clean channels
There appears to be consensus on the following:
- a server MUST provide a clean channel to subsystems (i.e., no crud inserted/deleted/etc. at the beginning or middle)
- exactly how a server cooperates with a subsystem to implement this is a local issue.
- exactly what protocol a subsystem uses is up to the subsystem.
There is less clear consensus on whether or not to recommend anything on this subject to subsystem protocol designers.
Two new security issues were raised on the list by Niels Provos shortly before the meeting and were briefly discussed at the meeting. Both issues can be corrected without wire protocol changes.
First, another SSH security advisory has been issued relating to some traffic-analysis issues (in short, an eavesdropper can determine the length of the user's password, and use this to both select targets of opportunity and also reduce the work factor with certain hashed password schemes if they also have a hash of the password).
See http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt for details. Niels will be supplying suggested text for the documents.
Niels also pointed out that the document does not provide recommendations for appropriate exponent sizes for use with the Diffie-Hellman exchange; the general rule of thumb is that the exponent should be roughly twice the size of the desired key. Niels also volunteered to supply suggested text for the document.
Several additional work items were suggested during last-call:
1) Server key fingerprints.
There was a very short draft by Markus Friedl sent to the list after the deadline. There is one outstanding issue -- the choice of hash function (MD5 vs SHA1).
There are strong arguments for both -- MD5 is what the installed base uses; however, SSHv2 only requires implementations to have SHA1 for the wire protocol.
2) Port forwarding of anonymous ports
The consensus of those present was that this would better be handled as a new request lest it cause interop problems with existing applications.
3) Improve error messages from port forwarding
There were no objections to this happening; someone in favor of this should supply specific text.
4) UDP forwarding (new channel type)
Seems like a reasonable idea; proponents should supply a draft. (due to lack of implementation experience, let's keep this separate for now).
1) File Transfer
This has been talked about a fair bit on the list.
One question was asked about UTF8 and filenames; Tatu pointed out that filenames are binary currently; it's hard to deal with different character sets properly (they can be negotiated later) and this shouldn't hold up the draft.
2) Public key file format
A suggestion was made that the document should contain an example or two. Consensus of those present is that (aside from this) it's essentially done and should be last-called.
3) DH Group Exchange - (a new WG item)
The purpose is to avoid precomputation group attacks against DH exchange; solution is to avoid too many people from using the same group.
Concern was brought up that you may open yourself up to other attacks by group exchange; there was also a question of lower and upper bounds on group size since some clients may not implement support for unbounded modulus size (a lower bound and upper bound on group size may be enough).
Assertion was made that there were no problems with the protocol.
Last call time?
There is now a unified GSSAPI key exchange draft (from all of the previous GSSAPI drafts).
The current unified draft is for key exchange only; current plans are for the next version to include user authentication.
Biggest change is that everything is now shuffled around to deal better with all mechanisms; handling of mechanism names is now clearer. There's now a paragraph describing how NOT to use channel bindings. Jeff is inclined to out-and-out prohibit it.
Simon Wilkinson implemented it, found some problems, and gave feedback to the authors, which is rolled into the new draft.
One open issue is what happens when credentials expire? With the current draft, the renegotiatiation fails and you get booted out. Is that correct? Jeff points out that a) right now we're using GSS for server-to-client authentication, and b) this is really annoying in practice. One possible resolution is to rekey using the "traditional" SSH key exchange mechanism since the server has already been authenticated.
- SSH host keys in DNS
DNS with DNSSEC appears to have the potential to be a great key distribution system.
The main purpose of the current draft is to get a protocol number from IANA for SSH keys; a second document is needed to give guidance on how/when to use/trust keys found in DNS.
Wes is implementing this in a version of OpenSSH. Consensus is that the encoding document is not controversial, and is "worthy of a last call".
- Niels Moeller's SRP draft (expired)
Is it appropriate to make this a WG item? Will bring this to the list.
Protocol Naming Discussion.
The working group has received a request from Tatu Ylonen to rename the protocol.
There was an extended discussion of the name for the working group's protocol which was led/moderated by Jeff Schiller, security AD.
The discussion started with Tatu repeating his request; an extended discussion followed.
While the sentiment was by no means unanimous, there was clear evidence that there is substantial opposition to renaming the protocol at this time, outweighing any interest in favor of renaming. This evidence comes both from pre-meeting comments on the list and to the WG chair, comments at the meeting itself, and a non-binding straw poll conducted at the end of the meeting. Therefore, the working group will not act on Tatu's request; the documents will proceed under their existing names.