Minutes of the secsh working group Wednesday, August 2, 2000 Notes taken by Jeremey Barrett , revised by Bill Sommerfeld 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: draft-ietf-secsh-architecture-05.txt 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 draft-ietf-secsh-transport-07.txt 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. draft-ietf-secsh-userauth-07.txt any certificate implementation experience? - none yet, but that's ok for now. draft-ietf-secsh-connect-07.txt signal encoding - extend format, include optional string with signal name w/o SIG prefix. SIGBUS -> "BUS" 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 } /Niels ---- 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. kerberos-tgt 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 ======================================================== Charter no particular revisions appear to be needed until we decide on what extensions we want to work on. -------------------------------------- Schedule 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