2.5.10 Secure Shell (secsh)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 25-Jul-00


Bill Sommerfeld <sommerfeld@east.sun.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ietf-ssh@clinet.fi
To Subscribe: majordomo@clinet.fi
In Body: subscribe ietf-ssh@clinet.fi in body
Archive: ftp://ftp.ietf.org/ietf-mail-archive/secsh/

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:

Feb 97


Submit Internet-Draft on SSH-2.0 protocol

Apr 97


Decide on Transport Layer protocol at Memphis IETF.

Aug 97


Finalize upper level protocols at Munich IETF.

Sep 97


Submit Internet-Drafts to IESG to consider for publication as RFCs.

Dec 97


Meet at DC IETF meeting.


No Request For Comments

Current Meeting Report

Minutes of the secsh working group
Wednesday, August 2, 2000
Notes taken by Jeremey Barrett <jeremey@terisa.com>, revised by Bill Sommerfeld <sommerfeld@east.sun.com>

Bill apologized for arranging the secsh meeting on such short notice.
Note that the schedule in charter badly blown (all dates are in 1997).

Working group status:

Bill took over as chair shortly before this IETF meeting.

The core set of 4 docs are all heavily inderdependent and need to advance as a unit. In Dec '97, a last call was put out on these documents; a couple comments came in, but no action was taken in response to the comments, and the documents were not submitted to the IESG.

In theory we could do last call again now and just go, but we're already aware of some issues which exist, so we may as well fix them first, and advance the core documents onto the standards track, then move on to new work.

Bill looked through archive for issues, though it was mind-numbing work and may have missed a few.

Open issues/proposed resolutions:

dangling reference to ssh-agent draft
- rip out until agent draft exists.
anti-dns language in section 4.1
- rip out section 4.1; dead code.
iana considerations section ok?
- waiting for answer from AD

optimistic algorithm negotiation - discuss on list.
eliminating redundant length fields - just do it.
add ssh-rsa key type - just do it.
arcfour - add cautionary text
key stretching clamps entropy to hash size
- ok as is given current threat models, but document as such
packet size fuzz factor
- document 35000 as arbitrary value larger than
uncompressed size
secrecy of exchange hash
- document that its best to keep it secret
Should concatenated string encoding specify length of each string?
(transport, section 6)
- [chair couldn't find context; will take to list]
DH parameter selection clarification
- [chair couldn't find context; will take to list]
dangling references to pkix, spki
- both are now rfcs; correct references.

any certificate implementation experience?
- none yet, but that's ok for now.

signal encoding
- extend format, include optional string with signal name w/o SIG prefix.
need references to X11, POSIX drafts
- just add them.
ssh agent forwarding dangling references
- remove for now until agent draft appears.

As far as I can tell, there's no standard whatsoever assigning numerical signal numbers to signals. (Some) symbolic signal names are defined by posix. In practice, numbers 1-15 seems to be the same everywhere, while higher numbers mean different things on different systems.

I don't know te motivation for adding an optional signal name, but it doesn't solve the problem.

In lsh, I use the concept of "network signal numbers" which are a somewhat arbitrary numbering that local numbers are translated to and from when transmitted in the protocol (in the "exit-signal" and "signal" SSH_MSG_CHANNEL_REQUEST:s). I use the following numbering

{ network number, local number }

{ 1, SIGHUP },
{ 2, SIGINT },
{ 3, SIGQUIT },
{ 4, SIGILL },
{ 5, SIGTRAP },
{ 6, SIGABRT },
/* IOT is the mnemonic for the PDP-11 instruction used by the abort() function */
{ 7, SIGEMT },
{ 8, SIGFPE },
{ 9, SIGKILL },
{ 10, SIGBUS },
{ 11, SIGSEGV },
{ 12, SIGSYS },
{ 13, SIGPIPE },
{ 14, SIGALRM },
{ 15, SIGTERM },
/* Signals beyond 15 does not have the same meaning everywhere */
{ 16, SIGURG },
{ 17, SIGSTOP },
{ 18, SIGTSTP },
{ 19, SIGCONT },
{ 20, SIGCHLD },
{ 21, SIGTTIN },
{ 22, SIGTTOU },
{ 23, SIGIO },
{ 23, SIGPOLL }, /* SysV name for SIGIO */
{ 24, SIGXCPU },
{ 25, SIGXFSZ },
{ 26, SIGVTALRM },
{ 27, SIGPROF },
{ 28, SIGWINCH },
{ 29, SIGLOST },
{ 30, SIGUSR1 },
{ 31, SIGUSR2 }



Kerberos Authentication (Tatu Ylonen)

Two new auth methods:
kerberos - Generate Kerberos AP_REQ

Server must be able to parse and decrypt request in order to accept auth.

Passes ticket-granting ticket to server in CREDS message from c->s

Server MUST use the tgt to create a new ticket to validate it
Server MAY store it in the credentials cache

First keeps server from getting access to tgt, second gives server tgt

Password method
no protocol change
SHOULD allow Kerb password and SHOULD store tgt in credentials cache

User names with realms
In addition to basic user name, could be user@realm
The user name MUST be mapped to local name by the server if it supports Kerb.
Might need to change draft to allow @
% might be used instead of @ on in client and then translated, since you can do ssh blah@foo

Folks familiar with kerberos picked a few nits with the proposal.

- protocol needs to use mutual authentication.
- credential forwarding needs to either happen after mutual authentication or be protected with the ticket's key.
- don't need a principal name outside the ticket; just leave login name alone

questions: why not GSSAPI?
- misc implementation/portability issues.
(can't do what ssh needs with current mechanism-independant gssapi)

action: tatu to write up an independant draft based on feedback and publish.

Other new features:
(MUST be independant drafts; don't want to hold up core drafts.)

Authentication agent

An old draft exists, but must be checked against implementations, etc. Won't take long to write a draft, just matter of getting to it.

Neils Moller: Is Tatu's proposal available anywhere? I'm looking into kerberos support, and my current thinking is that if kerberos is used to provide mutual authentication (and not simply as a different password verification mechanism), it should be done as a keyexchange method, not a userauth method. So kerberos is an example of a keyexchange method that authenticates both user and host (other examples are SRP and similar protocols). I think it makes sense to use this class of keyexchange methods, and then skip the user authentication on success. I.e. the client can send a SSH_MSG_SERVICE_REQUEST asking for "ssh-connection", and the server will associate the userid established during key exchange with any created sessions, processes etc. Comments? Are there any security problems here that I have overlooked? I imagine that the keyexchange has to include some steps to bind the exchange hash to the negotiated key.

File transfer

Current sftp draft is not in any state. sftp protocol needs to be documented, reviewed by the working group. file listing format should take a look at what the FTP WG did for directory listings.

"How to write an auth method"

Suggestion that since there is interest in new auth methods, there should be some text on how to do this somewhere.

Bill: if someone wants to write one, please do

DH param negotiation

Draft has boilerplate problems. Author couldn't make it this week (Nils Provos). No comments.

Text file key exchange format info doc

For pubkeys and private keys to allow portability of keys between implementations.

Jeff van Dyke volunteered to put together a summary of the 4 variations out there for the list.

Problems with SSHv1

There was a request to publish a spec for sshv1 as an IETF document (probably going directly to Historic status).

Tatu proposed, as an alternative, documenting "why not SSHv1" as an Informational document.

Improvided password auth

EKE/SPEKE/SRP interest which ties the password a bit better into the crypto and less succeptible to dictionaries. A volunteer exists to write a draft on this.

Niels: Are you referring to my draft on SRP here, or have I missed something?

Should look at these on the list.

il8n of usernames

A comment to the list was made that multiple representations could happen, do we need canonicalization.

Niels Moller suggested waiting for il8n strategy from the DNS people and using that.

Neils: One approach is to adopt draft-duerst-i18n-norm-04.txt, saying that usernames and passwords MUST be encoded in utf8, "Early Uniform Normalization according to Unicode Normalization Form C, Canonical Composition (NFC)".
Bill: other people are attacking this and what they do will probably work, the main problem with at least one draft is case sensitivity (especially with DNS stuff)
Tatu: If you want to make username something other than canonicalized binary crud, you will have to add something to identify which encoding it's in, might make sense to add it at this point. If we add it now, the installed base might be able to handle it when il8n is actually ready.
Bill: for compatibility we could add more magic strings for the tagged username format
Tatu: canonicalization could happen at client, and require NO changes to draft
Bill: anyone know of any mine fields here?
Comment: client would need unicode database
Comment: is there a reason UTF-8 wasn't used?
Tero: there are implementations that use "just binary data"

A bunch of UTF-8 discussion...

Comment: possible large sizes, etc
Ted: classic objection to UTF-8 is byte extension, but for usernames, not a big deal. The big deal is il8n hell.
Tero: I think canonicalization should be done at server, since it knows internal format it wants to use.
Neils: This makes sense (as I admitted on the list earlier). However, using the rules of draft-duerst-i18n-norm-04.txt may well make the job easier for most internal representations a server might want to use, and reduce the amount unicode-knowledge reqiured by the server. For instance, I think we get rid of all "strange" canonical equivalents to ascii, like "(1)".
Bill: take this to the list


no particular revisions appear to be needed until we decide on what extensions we want to work on.


Sep 00 Finalization of core drafts
Oct 00 Last calls
Oct 00 Submit core drafts to IESG
Oct 00 Determine schedule for extensions
Nov 00 Submit extension drafts for discussion
Dec 00 Meet in SD
Sep 01 Submit core drafts for publication as draft standard

Discussion on how long we need for extension drafts; we can discuss that once the core drafts are finalized.

Authors interested in working on internet-drafts for extensions should get in touch with the WG chair.

Extension drafts should be done at least a month before the next WG meeting so that we have time to look at them and discuss them on the list before the meeting.

- Bill


None received.