Current Meeting Report

2.5.10 Secure Shell (secsh)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 15-Nov-01
Bill Sommerfeld <>
Security Area Director(s):
Jeffrey Schiller <>
Marcus Leech <>
Security Area Advisor:
Jeffrey Schiller <>
Mailing Lists:
To Subscribe:
In Body: subscribe ietf-ssh
Description of Working Group:
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.

Goals and Milestones:
Done   Submit Internet-Draft on SSH-2.0 protocol
Done   Decide on Transport Layer protocol at Memphis IETF.
Done   Post revised core secsh drafts
Feb 01   Submit core drafts to IESG for publication as proposed standard
Feb 01   Post extensions drafts for review
Feb 01   Start sending extensions drafts to Last Call
No Request For Comments

Current Meeting Report

Minutes of IETF52 Secure Shell (secsh) meeting.

[Notes taken by Michael Richardson and Jun-ichiro "itojun" Hagino ]

Minutes from Secure Shell (secsh) meeting of IETF 52 in Salt Lake City:

- Agenda bashing/WG status
- last call, core drafts

WG Status
Last call started on core drafts.
One issue remaining, which is a typo.


Core issue
- formatting errors in transport draft.
- some references have been added.
- no need to repeat last-call for this.
- more text for @domain extensions.
- clarification for advice for setting environment variables.
- client to bind to port 0 to let server decide on port #.

New issue - multiple outstanding userauth requests.

- problem with multiple outstanding userauth requests.
- comes from GSSAPI, where successful authentication requires multiple round trips.
- if a client has started more than one userauth requests, how does one know which request the response applies to?

Joe: if the client sends only first round responses, the ordering is maintained, but if there are multiple rounds, then the ordering can not be determined.

Bill: ambiguity when there are multiple rounds required.
Bill: can we insist that client send in order as well?
Joe: that kills multiple requests.
- the server interprets new userauth's as aborts of previous requests.

If one asserts the rule that every reply gets only one response, then we can fix this, but this breaks GSSAPI, but GSSAPI can work around it.

Eliminating multiple userauth's requests would solve this.

Bill: Anyone object to this?
Joe: Neils Mueller (absent) may be using this.

Discussion about different methods and whether or not different methods of operation are in fact using multiple userauths.

Markus: what is the gain in having multiple outstanding requests?

Bill: the rational is to cut down the number of round trips.

Documenting historic identifiers
- historic algorithm use (des-cbc).
- other identifiers in deployed implementations?
Marked as historic.
RFC2026: specs can be historic, and applicability statements can be "Not Recommended"; one document can be both.

No comments - issue is resolved this way.

Extension drafts
- Generic Message Exchange Authentication for SSH
believed to be ready for last call.

- GSSAPI Authentication and Key Exchange

concern about errors on the server be returned properly to the client.
Clarification about what happens after the last client message has been sent, and it needs an ACK, but there isn't space for one.

If the userauth multiple-outsanding-requests issue is not resolved in the core draft, then GSSAPI may have to resolve it.

- SECSH Public key File Format

ready for last call? taken to list.

- Diffie Hellman Group Exchange

ready for last call? Think so.
two implementations out there.

- Storing SSH Host Keys in DNS
Using DNSSEC extensions to store SSH host keys.
Current KEY RR is not sufficient to do what we need to do. APPKEY is a proposed solution.

Want to approach this from a different point of view, what do application need in the way of key distribution?

Concern was raised about security of DNSSEC server.

- File Transfer Protocol

more work need.
- string vs numeric user ids?
- how many reinvented wheels?

Much Unix centric pieces in the draft.
Even under Unix systems, it is used between disparit spheres of control, so that numbers are meaningless.

Conclusion get rid of long names.

MCR asked for attribute to say whether or not the file/directories are writable.

Future directions
- an agent forwarding would be nice.
Darren has volunteered to write this draft.

It was in v1, but was omitted from v2. If there are other vendors who want to have interoperable versions, contact Darren.

- review milestones


None received.