From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 1 03:42:02 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01587 for ; Wed, 1 Oct 2003 03:42:01 -0400 (EDT) Received: (qmail 18792 invoked by uid 605); 1 Oct 2003 07:42:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18782 invoked from network); 1 Oct 2003 07:41:59 -0000 Received: from www.isc.netbsd.org (HELO narn.netbsd.org) (204.152.185.215) by mail.netbsd.org with SMTP; 1 Oct 2003 07:41:59 -0000 Received: from 169.254.87.107 (r200-40-185-164.adsl.anteldata.net.uy [200.40.185.164]) by narn.netbsd.org (Postfix) with SMTP id EB76711152 for ; Wed, 1 Oct 2003 07:41:49 +0000 (UTC) From: "Escuela de Negociacion" To: Subject: ESCUELA DE NEGOCIACION - Habilidades negociadoras y analisis estrategico de negociacion. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 1 Oct 2003 09:41:59 +0200 Reply-To: "Escuela de Negociacion" Message-Id: <20031001074150.EB76711152@narn.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit La Secretaría de la Oficina Internacional del Instituto Iberoamericano de Logística, Transporte y Comercio Internacional tiene el agrado de anunciar la realización de los siguientes cursos correspondientes a su ESCUELA DE NEGOCIACIÓN: 1. Desarrollo de Habilidad Negociadora. 2. Análisis estratégico de situaciones en la negociación. Cuyos detalles y contenidos se consignan a continuacion: ---------------------------------------------------------------- CURSO DE DESARROLLO DE HABILIDAD NEGOCIADORA. Primera edición. 6 al 10 de Octubre 2003. Fecha limite de inscripcion: lunes 6 de Octubre - 12 horas. Lunes a Viernes 18.30 a 22.30 horas. Objetivo del curso: Cultivar y desarrollar en los participantes, un conjunto de habilidades personales coadyuvantes a su manejo en la negociación. En todo proceso negociador, y de mediación, el comportamiento y el estilo de los participantes es un componente de alta trascendencia, con una decisiva influencia en el resultado final. El contenido de este curso viene a reforzar sustancialmente los conceptos manejados en el curso básico de negociación, en el de mediación y en el curso avanzado de negociación. La estructuración del curso es radicalmente innovadora. A través del pensamiento de los grandes maestros estratégicos, se busca contribuir a: Desarrollar la habilidad negociadora. Mejorar el control emocional del participante en la negociación. El desarrollo de la empatía del negociador. El reforzamiento del pensamiento estratégico. La habilidad en el control de las situaciones tensas de la negociación. Destinatarios: Fundamentalmente, quienes tengan conocimientos basicos de negociacion. Empresarios, ejecutivos, profesionales, técnicos, y todo personal involucrado con funciones y responsabilidades de gestión y negociación dentro de su ámbito laboral y con el medio exterior. Algunos ejemplos de áreas en las que se requieren habitualmente habilidades de negociación, persuasión y cierre de conflictos son: Área Comercial y de Ventas, Área de Compras y Abastecimiento, Recupero de Créditos y Gestión de Cobranzas, Áreas Administrativas Operativas, áreas que realizan transacciones comerciales relacionadas con el Comercio Exterior en lo relativo a importación y exportación, áreas de Recursos Humanos. Temas principales a desarrollar: Habilidades negociadoras personales, habilidades negociadoras en dirección y política, pensamiento estratégico aplicado a la negociación. Desarrollo de estilo negociador, control emocional en la negociación. Metodología: Se realizan diferentes casos prácticos para aplicar distintas técnicas contando con la proyección de diapositivas. Se entrega un manual con el contenido general del curso en formato digital. Se trabajarán aspectos que permitan generar valor a las relaciones profesionales, comerciales y/o personales. Se desarrollarán técnicas para reducción de tiempos innecesarios en reuniones y para la comprensión de los distintos escenarios de una negociación. SE ENTREGARA MATERIAL DE APOYO Y CERTIFICADO DE ASISTENCIA Informes e inscripciones: Instituto de Logística Iberoamericano Dirección: Boulevard Artigas 2791, Montevideo Horario de oficinas: 09.oo a 18.oo horas. Correo-electrónico: infoili@logistica-iberoamericana.org ilimont@logistica-iberoamericana.org Teléfonos: 2035345 - 2042383 ---------------------------------------------------------------------------- CURSO DE ANALISIS ESTRATEGICO DE SITUACIONES APLICADO A LA NEGOCIACIÓN. Segunda edición. 20 al 24 de Octubre 2003. Fecha limite de inscripcion: lunes 20 de octubre - 12 horas. Lunes a Viernes 18.30 a 22.30 horas. Objetivo del curso: Desarrollar el concepto de Estrategia, destacando el significado del término en la administración, sobre la base de la toma de decisiones presentes con efectos futuros. Se trata de presentar y permitir adquirir los elementos básicos para el desarrollo de estrategia, aplicados a modelos personales y empresariales, integrando elementos de posicionamiento, visión, plan, análisis y patrones integrados de comportamiento. La estrategia es un modelo coherente, unificador e integrador de decisiones que determina y revela el propósito del individuo y de las organizaciones en términos de objetivos de largo plazo, programas de acción y prioridades en la asignación de recursos. Se trata de dotar al participante de una metodología que le permita realizar la selección de los negocios actuales o futuros de la organización en términos de objetivos a largo plazo, respondiendo adecuadamente a las oportunidades y amenazas surgidas en el medio externo de la empresa, teniendo en cuenta las fortalezas y debilidades del individuo, ya sea en un plan personal, o el de una empresa u organización. Se establecerá, además, la diferencia entre pensamiento estratégico y planeamiento estratégico: planeamiento es análisis y pensamiento estratégico es síntesis. Ello, enmarcado en la metodología FODA, herramienta que permite conformar un cuadro de situación actual de la empresa u organización, obteniendo de esta manera un diagnóstico preciso que ayuda decididamente a la toma de decisiones acordes con los objetivos y las políticas formuladas. Destinatarios: Empresarios, ejecutivos, profesionales, técnicos, y todo personal involucrado con funciones y responsabilidades de gestión y negociación dentro de su ámbito laboral y con el medio exterior. Algunos ejemplos de áreas en las que se requieren habitualmente habilidades de análisis estratégico son: Área Comercial y de Ventas, Área de Compras y Abastecimiento, Recupero de Créditos y Gestión de Cobranzas, Áreas Administrativas Operativas, áreas que realizan transacciones comerciales relacionadas con el Comercio Exterior en lo relativo a importación y exportación, áreas de Recursos Humanos. Metodología: Se realizan diferentes casos prácticos para aplicar distintas técnicas contando con la proyección de diapositivas. Se entrega un manual con el contenido general del curso en formato digital. Se trabajarán aspectos que permitan generar valor a las relaciones profesionales, comerciales y/o personales. Se desarrollarán técnicas para el analisis estrategico sistematico de situaciones de acuerdo a matrices de analisis. Temas principales a desarrollar: 1.Concepto y desarrollo de la estrategia Introducción. Concepto de estrategia. Enfoques y definiciones. Concepto actual de estrategia. Visión. Posicionamiento. Cambio estratégico y reposicionamiento. Plan estratégico. Patrón integrado de comportamiento. Estrategia implícita y estrategia explícita. Niveles de estrategia. Pensamiento estratégico. Técnicas de planificación estratégica: de preferencia y prospectivas. Uso de escenarios. 2. Estrategia competitiva Introducción. Barreras de ingreso y de salida. Estrategias genéricas. Cadena de valor. Ventaja competitiva. 3. Planeamiento estratégico Desarrollo. Falacias. Claves. Estrategia y planeamiento. Evaluación de la estrategia. 4. Estrategias, políticas y premisas de planeamiento Estrategia y política. Planeación operativa: tácticas. Proceso de planeamiento estratégico. Instrumentación de estrategias. Desarrollo de premisas y pronósticos. 5. Análisis FODA Introducción y alcance del análisis. Análisis de ambiente externo. Análisis de ambiente interno. Análisis de fortalezas. Análisis de debilidades. Análisis de oportunidades. Análisis de amenazas. Análisis integrado. Generación de matrices FODA. 6. Análisis de situación competitiva La competitividad. Definición de competencia. Componentes del alcance de la competencia. Evaluación de competidores. Evaluación comparativa. Matriz de análisis competitivo. Conclusiones. SE ENTREGARA MATERIAL DE APOYO Y CERTIFICADO DE ASISTENCIA Informes e inscripciones: Instituto de Logística Iberoamericano Dirección: Boulevard Artigas 2791, Montevideo Horario de oficinas: 09.oo a 18.oo horas. Correo-electrónico: infoili@logistica-iberoamericana.org ilimont@logistica-iberoamericana.org Teléfonos: 2035345 - 2042383 -------------------------------------------------------------------------- Si no desea recibir la informacion sobre los cursos academicos desarrollados por la Institucion, por favor, envie una respuesta indicando "remove" en el "subject". From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 6 11:39:08 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08066 for ; Mon, 6 Oct 2003 11:39:08 -0400 (EDT) Received: (qmail 5949 invoked by uid 605); 6 Oct 2003 15:39:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5942 invoked from network); 6 Oct 2003 15:39:07 -0000 Received: from ckmso2.att.com (HELO ckmso2.proxy.att.com) (209.219.209.75) by mail.netbsd.org with SMTP; 6 Oct 2003 15:39:07 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h96FCQ3B025376 for ; Mon, 6 Oct 2003 11:39:06 -0400 Received: from OCCLUST02EVS1.ugd.att.com (135.38.164.8) by attrh3i.attrh.att.com (6.5.032) id 3F770691001CD863 for ietf-ssh@netbsd.org; Mon, 6 Oct 2003 11:37:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: scp issue between OpenSSH and SSH2 Date: Mon, 6 Oct 2003 10:39:05 -0500 Message-ID: <262F37DBFF9B664A9A919331C685545F06E496EA@OCCLUST02EVS1.ugd.att.com> Thread-Topic: scp issue between OpenSSH and SSH2 Thread-Index: AcOMIHx9Yzn2f89JRe6n3I5Vi+astg== From: "Nikolin, Vanja, ALABS" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Does OpenSSH 3.7.1 solve this problem? I'm trying to scp using an OpenSSH client to an SSH2 server. ssh works = fine, but scp returns this:=20 Executing ssh1 in compatibility mode failed This problem is often quite perplexing, since a ssh -v trace may show = that you're using SSH-2 - so what is a message about "ssh1 compatibility = mode" doing in there?=20 What's happening is this:=20 On the OpenSSH client, you run say, scp foo server:bar.=20 scp runs ssh in a subprocess to connect to the server, and run the = remote command scp -t bar. This is intended to start an instance of the = scp program on the server, and the two scp's will cooperate by speaking = over the SSH connection, to retrieve the file.=20 ssh connects to the server (using either protocol 1 or 2, it doesn't = matter), and runs the remote scp command. However, the "scp" that gets = run on the server is the SSH2 scp program (scp2), not the OpenSSH one. = The crux of the problem is: besides the name, these two scp's have = exactly nothing in common. scp2 cannot speak the file-transfer protocol = that OpenSSH scp does. However, scp2 recognizes from the "-t" flag = what's expected, and tries exec scp1 to service the connection (this is = the extent of SSH2's SSH-1 compatibility; where OpenSSH has code for = both protocols in a single set of programs, SSH2 expects to execute = programs from a parallel SSH1 installation). It fails (presumably = because you don't have SSH1 installed), and reports the problem.=20 The solution is to install either the OpenSSH or SSH1 version of scp on = the server under the name "scp1," somewhere in the sshd2's PATH.=20 Thanks! From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 6 11:53:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08487 for ; Mon, 6 Oct 2003 11:53:07 -0400 (EDT) Received: (qmail 12998 invoked by uid 605); 6 Oct 2003 15:53:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12990 invoked from network); 6 Oct 2003 15:53:13 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 6 Oct 2003 15:53:13 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h96FnPAU025528; Mon, 6 Oct 2003 17:49:25 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 22D1F2D044; Mon, 6 Oct 2003 17:49:01 +0200 (CEST) Date: Mon, 6 Oct 2003 17:49:01 +0200 From: Markus Friedl To: "Nikolin, Vanja, ALABS" Cc: ietf-ssh@NetBSD.org Subject: Re: scp issue between OpenSSH and SSH2 Message-ID: <20031006154901.GB11744@folly> References: <262F37DBFF9B664A9A919331C685545F06E496EA@OCCLUST02EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <262F37DBFF9B664A9A919331C685545F06E496EA@OCCLUST02EVS1.ugd.att.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Oct 06, 2003 at 10:39:05AM -0500, Nikolin, Vanja, ALABS wrote: > Does OpenSSH 3.7.1 solve this problem? no, and it's not related to ietf-ssh@. openssh's scp implements RCP openssh's sftp implements SFTP ssh.com 2.x's scp implements SFTP. no idea how to fix this. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 6 12:20:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09825 for ; Mon, 6 Oct 2003 12:20:57 -0400 (EDT) Received: (qmail 6598 invoked by uid 605); 6 Oct 2003 16:21:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6590 invoked from network); 6 Oct 2003 16:21:03 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 6 Oct 2003 16:21:03 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2333067 for ietf-ssh@NetBSD.org; Mon, 06 Oct 2003 10:21:02 -0600 Message-ID: <3F81966E.1030903@vandyke.com> Date: Mon, 06 Oct 2003 10:21:02 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Minor comments on draft-ietf-secsh-filexfer-04 References: <20030926222925.GA15376@chiark.greenend.org.uk> In-Reply-To: <20030926222925.GA15376@chiark.greenend.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Section 5.5 "Permissions": "...as defined by POSIX [1]": [1] isn't > POSIX. It would also be nice to have the relevant bit quoted so the > draft stands without POSIX. In fact, posix does not define the bit values, only that macros of a given name exist, and so is worthless in specifying a protocol where implementation must agree about the meaning of the bits. We had run into this when we realized AIX was giving us back a bit value we didn't recognize and asked the question, what would happen if this was sent over the wire? And started poking. The next version of the draft defines the values. > Section 5.6 "Times": "A negative value..." [for atime etc]: atime and > friends are defined as `uint64' in sec 5. > >>From draft-ietf-secsh-architecture-14, `uint64' "represents a 64-bit > unsigned integer", so can't go negative. > > The architecture draft doesn't define signed types, so some words > indicating that that the putative "uint64" is to be treated as 2's > complement signed yadda yadda are probably needed. I may introduce a int64 type for sftp instead. This seems better than saying unsigned, but not really. > Section 6.11 "Canonicalizing the Server-Side Path Name" (SSH_FXP_REALPATH): > It's not too clear how much of the path needs to exist at the time > REALPATH is invoked. This may cause interoperability problems. > > At least one implementation (psftp) contains workarounds to handle > variant server responses to REALPATH("../path/to/nonexistent") where > "../path/to" exists but the path component "nonexistent" doesn't (for > instance when the client is planning to create a file or directory). > > Some servers will apparently complain because "nonexistent" doesn't > exist, whereas others don't mind. > > Not sure what the right fix is - it's probably more important that it's > defined than how it's defined. A conservative one would be to require > the path to exist in its entirety (so in the above case, clients would > ask about the destination directory, and then splice the filename on the > end). This would remove ambiguity about how it's intended to be used; > however, there are a few cases where > realname(path) + "/" + leaf != realname(path + "/" + leaf) > for instance, if the client plans to mkdir(".."). This probably doesn't > matter. This one is a little bit trickier-- realpath is often implemented using the unix library function of the same name, which, I believe, fails if the path doesn't exist. Currently, our server doesn't fail if the path doesn't exist (being windows, it doesn't use realpath of course.) However, if realpath failed for nonexistent files or directories, a separate stat call would not be required for chdir operations on the client. I believe this is the route I will take. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 6 12:25:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10123 for ; Mon, 6 Oct 2003 12:25:29 -0400 (EDT) Received: (qmail 9766 invoked by uid 605); 6 Oct 2003 16:25:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9759 invoked from network); 6 Oct 2003 16:25:35 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 6 Oct 2003 16:25:35 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa13384; 6 Oct 2003 12:24 EDT Date: Mon, 06 Oct 2003 12:24:55 -0400 From: Jeffrey Hutzelman To: "Nikolin, Vanja, ALABS" cc: ietf-ssh@NetBSD.org Subject: Re: scp issue between OpenSSH and SSH2 Message-ID: <1613032704.1065457495@minbar.fac.cs.cmu.edu> In-Reply-To: <20031006154901.GB11744@folly> References: <262F37DBFF9B664A9A919331C685545F06E496EA@OCCLUST02EVS1.ugd.att.c om> <20031006154901.GB11744@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, October 06, 2003 17:49:01 +0200 Markus Friedl wrote: > On Mon, Oct 06, 2003 at 10:39:05AM -0500, Nikolin, Vanja, ALABS wrote: >> Does OpenSSH 3.7.1 solve this problem? > > no, and it's not related to ietf-ssh@. > > openssh's scp implements RCP > openssh's sftp implements SFTP > > ssh.com 2.x's scp implements SFTP. > > no idea how to fix this. Short term: Install ssh.com 2.x's "scp" as "sftp", and use openssh's sftp client. Long term: ssh.com should fix their broken software; SFTP is not scp From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 6 13:10:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12663 for ; Mon, 6 Oct 2003 13:10:57 -0400 (EDT) Received: (qmail 7743 invoked by uid 605); 6 Oct 2003 17:11:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7735 invoked from network); 6 Oct 2003 17:11:03 -0000 Received: from kcmso1.att.com (HELO kcmso1.proxy.att.com) (192.128.133.69) by mail.netbsd.org with SMTP; 6 Oct 2003 17:11:03 -0000 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h96H3UU7015556 for ; Mon, 6 Oct 2003 12:11:02 -0500 Received: from OCCLUST02EVS1.ugd.att.com (135.38.164.8) by attrh3i.attrh.att.com (6.5.032) id 3F770691001D5466; Mon, 6 Oct 2003 13:09:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: scp issue between OpenSSH and SSH2 Date: Mon, 6 Oct 2003 12:11:02 -0500 Message-ID: <262F37DBFF9B664A9A919331C685545F06E49822@OCCLUST02EVS1.ugd.att.com> Thread-Topic: scp issue between OpenSSH and SSH2 Thread-Index: AcOMJnui6zDKTd2jSA+qkAvuNdeGTAABr6Ww From: "Nikolin, Vanja, ALABS" To: "Jeffrey Hutzelman" Cc: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Guys, Thank you very much for the input. Regards, Vanja -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] Sent: Monday, October 06, 2003 12:25 PM To: Nikolin, Vanja, ALABS Cc: ietf-ssh@NetBSD.org Subject: Re: scp issue between OpenSSH and SSH2 On Monday, October 06, 2003 17:49:01 +0200 Markus Friedl=20 wrote: > On Mon, Oct 06, 2003 at 10:39:05AM -0500, Nikolin, Vanja, ALABS wrote: >> Does OpenSSH 3.7.1 solve this problem? > > no, and it's not related to ietf-ssh@. > > openssh's scp implements RCP > openssh's sftp implements SFTP > > ssh.com 2.x's scp implements SFTP. > > no idea how to fix this. Short term: Install ssh.com 2.x's "scp" as "sftp", and use openssh's sftp=20 client. Long term: ssh.com should fix their broken software; SFTP is not scp From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 13 15:58:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24256 for ; Mon, 13 Oct 2003 15:58:22 -0400 (EDT) Received: (qmail 20133 invoked by uid 605); 13 Oct 2003 19:58:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20126 invoked from network); 13 Oct 2003 19:58:18 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 13 Oct 2003 19:58:18 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24156; Mon, 13 Oct 2003 15:57:18 -0400 (EDT) Message-Id: <200310131957.PAA24156@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-newmodes-01.txt Date: Mon, 13 Oct 2003 15:57:14 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Encryption Modes Author(s) : M. Bellare, et. al. Filename : draft-ietf-secsh-newmodes-01.txt Pages : 11 Date : 2003-10-13 Researchers have recently discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy and integrity/authenticity attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-newmodes-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-newmodes-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-13145850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-newmodes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-newmodes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-13145850.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 14 02:40:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27612 for ; Tue, 14 Oct 2003 02:40:02 -0400 (EDT) Received: (qmail 12729 invoked by uid 605); 14 Oct 2003 06:39:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12712 invoked from network); 14 Oct 2003 06:39:49 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 14 Oct 2003 06:39:49 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 0476A1EB70; Tue, 14 Oct 2003 08:39:40 +0200 (CEST) Message-ID: <3F8B9A2C.5080107@siliconcircus.com> Date: Tue, 14 Oct 2003 08:39:40 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030826 Mozilla Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Bright Cc: ietf-ssh@NetBSD.org Subject: Re: Submission: draft-ietf-secsh-publickey-subsystem-03.txt References: <3F657540.8030203@siliconcircus.com> In-Reply-To: <3F657540.8030203@siliconcircus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, Jon Bright wrote: > I'd be grateful if you could post the attached submission, which is an > update of draft-galb-secsh-publickey-subsystem-02.txt (and is now a > secsh WG working item, hence the name change from galb -> ietf). If anyone's wondering where this draft got lost, it first had a naming problem (since it was previously draft-galb and was renamed draft-ietf, it should have been reset to 00). After resubmitting (on 02 Oct), the IETF contacted Bill to get his approval of the draft as a WG item. Either Bill didn't approve it yet, or the IETF is being slow with it... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 16 03:28:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22842 for ; Thu, 16 Oct 2003 03:28:41 -0400 (EDT) Received: (qmail 13150 invoked by uid 605); 16 Oct 2003 07:28:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13143 invoked from network); 16 Oct 2003 07:28:34 -0000 Received: from hermes.cs.aauckland.ac.nz (HELO hermes.cs.auckland.ac.nz) (130.216.33.151) by mail.netbsd.org with SMTP; 16 Oct 2003 07:28:34 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9G6YKxZ022178 for ; Thu, 16 Oct 2003 19:34:20 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9G6amE09485 for ietf-ssh@NetBSD.org; Thu, 16 Oct 2003 19:36:48 +1300 Date: Thu, 16 Oct 2003 19:36:48 +1300 Message-Id: <200310160636.h9G6amE09485@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Some questions about "SSH Transport Layer Encryption Modes" Sender: ietf-ssh-owner@NetBSD.org Precedence: list These are more just ideas tossed out to see what thoughts people have on the topic... - I can't see any indication of how binding this is (or will be), is it experimental, informational, or standards-track? - Section 3 talks about re-keying, but there seems to be some ambiguity in implementations about how to handle re-keying (specifically, what to do with data flows in progress when the re-key happens). How viable is the re- keying approach really? - From an implementation point of view, how practical is it to require the use of SDCTR mode? It's not one of the big four (ECB/CBC/CFB/OFB), which makes it awkward to use with any standard crypto library or crypto hardware because it has to be manually synthesised from ECB. Conversely, if people have to implement a nonstandard encryption mode anyway, what about just going the whole way and using some provable authenticate+encrypt combination? Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 16 04:33:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24732 for ; Thu, 16 Oct 2003 04:33:39 -0400 (EDT) Received: (qmail 27994 invoked by uid 605); 16 Oct 2003 08:33:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27987 invoked from network); 16 Oct 2003 08:33:40 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 16 Oct 2003 08:33:40 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h9G8TkAU018456; Thu, 16 Oct 2003 10:29:46 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id CD3A02D044; Thu, 16 Oct 2003 10:29:14 +0200 (CEST) Date: Thu, 16 Oct 2003 10:29:14 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031016082914.GA27895@folly> References: <200310160636.h9G6amE09485@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310160636.h9G6amE09485@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Oct 16, 2003 at 07:36:48PM +1300, Peter Gutmann wrote: > - Section 3 talks about re-keying, but there seems to be some ambiguity in > implementations about how to handle re-keying (specifically, what to do with > data flows in progress when the re-key happens). How viable is the re- > keying approach really? i think this has been discussed before. during rekeying (after KEXINIT is sent), only kex exchange related messages are allowed, so application data has to wait. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 17 16:36:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23284 for ; Fri, 17 Oct 2003 16:36:27 -0400 (EDT) Received: (qmail 14840 invoked by uid 605); 17 Oct 2003 20:36:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14833 invoked from network); 17 Oct 2003 20:36:27 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Oct 2003 20:36:27 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9HKaQUP023676 for ; Fri, 17 Oct 2003 13:36:27 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9HKaQbx005229 for ; Fri, 17 Oct 2003 16:36:26 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9HKaQwT007094 for ; Fri, 17 Oct 2003 16:36:26 -0400 (EDT) Message-Id: <200310172036.h9HKaQwT007094@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Russ Housley: IESG comments on draft-ietf-secsh-auth-kbdinteract-05.txt Reply-to: sommerfeld@east.sun.com Date: Fri, 17 Oct 2003 16:36:26 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list FYI, comments from the IESG. In summary, looks like an IANA issue, a few I18N issues, some matters of taste, plus a few nits. We'll need to re-spin the document and resubmit it. - Bill ------- Forwarded Message From sommerfeld-request@east.sun.com Fri Oct 17 16:32:34 2003 Date: Fri, 17 Oct 2003 16:31:21 -0400 To: sommerfeld@east.sun.com From: Russ Housley Subject: IESG comments on draft-ietf-secsh-auth-kbdinteract-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3128 Bill: A revised Internet-Draft is needed to resolve the comments. Russ = = = = = = = DISCUSS 1. This sentence caused a lot of trouble: The actual names of the submethods is something which the user and the server needs to agree upon. These submethods need to be specified by RFC, probably a standards-track RFC, and listed in an IANA registry, otherwise there can't be any standards-based interoperability of submethods. 2. Explain why the language tag in the SSH_MSG_USERAUTH_INFO_REQUEST is not deprecated, especially when they are deprecated in SSH_MSG_USERAUTH_REQUEST. 3. Section 3.4 seems problematic. It says: Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting. If I read the author's intentions correctly, they mean to say that a server might use an authentication method that was functionally similar to case-insensitive passwords, and would thus treat the strings like "aCEddd8" and "AceDdd8" (encoded in UTF-8) as equivalent. I don't think it should be "up to the server" though, I think the method (or submethod) has to determine this; otherwise the interaction seems pretty hard to debug. There are also a lot of worms under the carpet of "if the client reads the responses in some other encoding...it MUST convert the responses". It is particularly problematic when you have the possibility of authentication mechanisms that are not exact match, as the temptation is to increase the set of matches rather than strongly define the conversion. There are clear security concerns there. The reference to UTF-8 should probably be updated. 4. Building on the previous comment, when I see a document that talks about using UTF-8 and reading stuff from keyboards I immediately think "where's the stringprep profile?" I didn't see one specified here -- isn't one needed? If not, why not? COMMENT 5. I find the whole User Interface section grating. It has two or three visual models in mind and ignores a plethora of other possibilities. I'd personally rather they ripped it out, but this is probably rank prejudice, so take it as such. 6. 2nd to last paragraph of 3.1: Under what circumstances is an SSH_MSG_USERAUTH_SUCCESS sent in response to an SSH_MSG_USERAUTH_REQUEST? Some guidelines are given for when the other two possibilities (including FAILURE and INFO_REQUEST) are sent. I assume it's only when no authentication is needed for this particular user - when just asserting the username is sufficient authentication. Could the case in which this makes sense be stated explicitly here? 7. Nit, top of page 4 (section 3.1): "It is a a comma-separated list..." 8. Nit, second paragraph of page 4 (section 3.1): "which the user and the server needs", should be "need" 9. Missing IPR section 10. RFC2279 (norm ref) is being updated, 2279bis is in RFC-Editor queue. Probably want to reference the new version. ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 17 18:15:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27375 for ; Fri, 17 Oct 2003 18:15:22 -0400 (EDT) Received: (qmail 1478 invoked by uid 605); 17 Oct 2003 22:15:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1466 invoked from network); 17 Oct 2003 22:15:24 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 17 Oct 2003 22:15:24 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Oct 2003 00:13:30 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9HMFFl9003933 for ; Sat, 18 Oct 2003 00:15:16 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA15125 for ietf-ssh@NetBSD.org; Fri, 17 Oct 2003 23:15:16 +0100 (BST) Date: Fri, 17 Oct 2003 23:15:16 +0100 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: connection draft: Global messages Message-ID: <20031017231516.I23130@edinburgh.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Just noticed something in re-reading this: The global messages are: SSH_MSG_GLOBAL_REQUEST (80) SSH_MSG_REQUEST_SUCCESS (81) SSH_MSG_REQUEST_FAILURE (82) However section 5.1 refers to SSH_MSG_GLOBAL_REQUEST_SUCCESS when it should refer to SSH_MSG_REQUEST_SUCCESS. So a typo. But it does rais the question: should messages 81 and 82 be renamed along the lines of: SSH_MSG_GLOBAL_REQUEST_SUCCESS SSH_MSG_GLOBAL_REQUEST_FAILURE Since it looks like there was some partial attempt at that? It would also make the names more consistent. Something else I noticed, the TCP port forwarding doesn't allow port zero to be specified, reserving that for "allocate a port automatically" ala the sockets API. So how about using 65536 to mean use port 0? OK - the sockets API won't be able to handle it, but other APIs may. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 18 03:15:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22313 for ; Sat, 18 Oct 2003 03:15:01 -0400 (EDT) Received: (qmail 16838 invoked by uid 605); 18 Oct 2003 07:15:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16831 invoked from network); 18 Oct 2003 07:15:01 -0000 Received: from hermes.cs.aauckland.ac.nz (HELO hermes.cs.auckland.ac.nz) (130.216.33.151) by mail.netbsd.org with SMTP; 18 Oct 2003 07:15:01 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9I5uLxZ002839; Sat, 18 Oct 2003 18:56:21 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9I5uZs21761; Sat, 18 Oct 2003 18:56:35 +1300 Date: Sat, 18 Oct 2003 18:56:35 +1300 Message-Id: <200310180556.h9I5uZs21761@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: markus@openbsd.org, pgut001@cs.auckland.ac.nz Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Markus Friedl writes: >i think this has been discussed before. Hmm, I think "debated without clear resolution" might be a better description, if you're referring to the debate from about two years ago. Specifically, the exact message/data flow was never totally resolved. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 18 08:34:26 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26987 for ; Sat, 18 Oct 2003 08:34:26 -0400 (EDT) Received: (qmail 11537 invoked by uid 605); 18 Oct 2003 12:34:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11530 invoked from network); 18 Oct 2003 12:34:31 -0000 Received: from mail-in-02.arcor-online.net (151.189.21.42) by mail.netbsd.org with SMTP; 18 Oct 2003 12:34:31 -0000 Received: from localhost.arcor.net (dsl-213-023-012-005.arcor-ip.net [213.23.12.5]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 5EC4BF6030; Sat, 18 Oct 2003 14:34:29 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id EC03D2D004; Sat, 18 Oct 2003 14:33:51 +0200 (CEST) Date: Sat, 18 Oct 2003 14:33:49 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031018123349.GA11808@folly> References: <200310180556.h9I5uZs21761@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310180556.h9I5uZs21761@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Oct 18, 2003 at 06:56:35PM +1300, Peter Gutmann wrote: > Markus Friedl writes: > > >i think this has been discussed before. > > Hmm, I think "debated without clear resolution" might be a better description, > if you're referring to the debate from about two years ago. Specifically, the > exact message/data flow was never totally resolved. Hm, AFAIK we agreed, that after sending KEXINIT you MUST NOT send messages of type > 49 (i.e. only transport layer messages are allowed) until you send NEWKEYS. As a consequence OpenSSH's implementation of rekeying was changed. Changing this now again will very likely break interoperabitily. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 18 08:56:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27475 for ; Sat, 18 Oct 2003 08:56:06 -0400 (EDT) Received: (qmail 25993 invoked by uid 605); 18 Oct 2003 12:56:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25980 invoked from network); 18 Oct 2003 12:56:11 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 18 Oct 2003 12:56:11 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9ICuAxZ010143; Sun, 19 Oct 2003 01:56:10 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9ICuSK25422; Sun, 19 Oct 2003 01:56:28 +1300 Date: Sun, 19 Oct 2003 01:56:28 +1300 Message-Id: <200310181256.h9ICuSK25422@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: markus@openbsd.org, pgut001@cs.auckland.ac.nz Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Markus Friedl writes: >On Sat, Oct 18, 2003 at 06:56:35PM +1300, Peter Gutmann wrote: >>Markus Friedl writes: >>>i think this has been discussed before. >> >>Hmm, I think "debated without clear resolution" might be a better description, >>if you're referring to the debate from about two years ago. Specifically, the >>exact message/data flow was never totally resolved. > >Hm, AFAIK we agreed, that after sending KEXINIT you MUST NOT send messages of >type > 49 (i.e. only transport layer messages are allowed) until you send >NEWKEYS. I was under the impression that the debate had simply fizzled out. The specification certainly hasn't been clarified (it's remained unchanged since the -02 draft of late 1997), and that would be the definitive reference. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 18 18:24:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12273 for ; Sat, 18 Oct 2003 18:24:20 -0400 (EDT) Received: (qmail 22346 invoked by uid 605); 18 Oct 2003 22:24:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22339 invoked from network); 18 Oct 2003 22:24:17 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 18 Oct 2003 22:24:17 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa23785; 18 Oct 2003 18:23 EDT Date: Sat, 18 Oct 2003 18:23:25 -0400 From: Jeffrey Hutzelman To: Peter Gutmann , markus@openbsd.org cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <347725408.1066515805@minbar.fac.cs.cmu.edu> In-Reply-To: <200310181256.h9ICuSK25422@cs.auckland.ac.nz> References: <200310181256.h9ICuSK25422@cs.auckland.ac.nz> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Sunday, October 19, 2003 01:56:28 +1300 Peter Gutmann wrote: > Markus Friedl writes: >> On Sat, Oct 18, 2003 at 06:56:35PM +1300, Peter Gutmann wrote: >>> Markus Friedl writes: >>>> i think this has been discussed before. >>> >>> Hmm, I think "debated without clear resolution" might be a better >>> description, if you're referring to the debate from about two years >>> ago. Specifically, the exact message/data flow was never totally >>> resolved. >> >> Hm, AFAIK we agreed, that after sending KEXINIT you MUST NOT send >> messages of type > 49 (i.e. only transport layer messages are allowed) >> until you send NEWKEYS. > > I was under the impression that the debate had simply fizzled out. The > specification certainly hasn't been clarified (it's remained unchanged > since the -02 draft of late 1997), and that would be the definitive > reference. The document does seem a little murky in this area. Section 5.3 clearly states: Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. But it's unclear whether we're talking about all key exchanges, or just _initial_ key exchange. However, section 7, discussing rekey, says: Re-exchange is processed identically to the initial key exchange, except for the session identifier that will remain unchanged. ... More application data may be sent after the SSH_MSG_NEWKEYS packet has been sent; key exchange does not affect the protocols that lie above the SSH transport layer. That last sentence is _extremely_ ambiguous. It could be read to mean the behaviour which Markus described, in which application data (and, in fact, anything above the transport layer) is simply suspended until rekeying is complete. Or, it could be read to mean that application data continues to flow during the rekey. I think if I were a new SSH implementor, working in a vacuum, I'd read it to mean that higher-layer protocols are _not_ suspended. So if that's not what we mean, then maybe this needs to be clarified. Bleah. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 19 06:31:52 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05039 for ; Sun, 19 Oct 2003 06:31:51 -0400 (EDT) Received: (qmail 26579 invoked by uid 605); 19 Oct 2003 10:31:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26572 invoked from network); 19 Oct 2003 10:31:49 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 19 Oct 2003 10:31:49 -0000 Received: from localhost.arcor.net (dsl-213-023-020-188.arcor-ip.net [213.23.20.188]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 34A08104DF1; Sun, 19 Oct 2003 12:31:48 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 72D922D004; Sun, 19 Oct 2003 12:31:12 +0200 (CEST) Date: Sun, 19 Oct 2003 12:31:12 +0200 From: Markus Friedl To: Jeffrey Hutzelman Cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031019103112.GA32181@folly> References: <200310181256.h9ICuSK25422@cs.auckland.ac.nz> <347725408.1066515805@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <347725408.1066515805@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Oct 18, 2003 at 06:23:25PM -0400, Jeffrey Hutzelman wrote: > More application data may be sent after the SSH_MSG_NEWKEYS packet > has been sent; key exchange does not affect the protocols that lie > above the SSH transport layer. > > That last sentence is _extremely_ ambiguous. It could be read to mean the > behaviour which Markus described, in which application data (and, in fact, > anything above the transport layer) is simply suspended until rekeying is > complete. Or, it could be read to mean that application data continues to > flow during the rekey. I think if I were a new SSH implementor, working in > a vacuum, I'd read it to mean that higher-layer protocols are _not_ > suspended. So if that's not what we mean, then maybe this needs to be but that could result in the higher layer using the old keying material forever. > clarified. Bleah. I wrote earlier: > Date: Wed, 4 Apr 2001 12:00:54 +0200 > From: Markus Friedl > To: ietf-ssh@netbsd.org > Cc: Mats Andersson > Subject: Re: Key Re-Exchange > Message-ID: <20010404120054.B28718@faui02.informatik.uni-erlangen.de> > References: > In-Reply-To: ; from mats@mindbright.se on Wed, Apr 04, 2001 at 11:55:40AM +0200 > > > I think that the draft should point out that a sender MUST NOT send > non-KEX messages after he _sent_ a KEXINIT message. he has to delay all > non-KEX messages until he has sent the NEWKEYS message. > I remember a mail from Tatu about this issue, but I cannot find this right now... From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 19 12:36:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12215 for ; Sun, 19 Oct 2003 12:36:35 -0400 (EDT) Received: (qmail 9510 invoked by uid 605); 19 Oct 2003 16:36:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9503 invoked from network); 19 Oct 2003 16:36:37 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 19 Oct 2003 16:36:37 -0000 Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa05062; 19 Oct 2003 12:35 EDT Date: Sun, 19 Oct 2003 12:35:50 -0400 From: Jeffrey Hutzelman To: Markus Friedl cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <123220000.1066581350@mariner.pc.cs.cmu.edu> In-Reply-To: <20031019103112.GA32181@folly> References: <200310181256.h9ICuSK25422@cs.auckland.ac.nz> <347725408.1066515805@minbar.fac.cs.cmu.edu> <20031019103112.GA32181@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Sunday, October 19, 2003 12:31:12 +0200 Markus Friedl wrote: > On Sat, Oct 18, 2003 at 06:23:25PM -0400, Jeffrey Hutzelman wrote: >> More application data may be sent after the SSH_MSG_NEWKEYS packet >> has been sent; key exchange does not affect the protocols that lie >> above the SSH transport layer. >> >> That last sentence is _extremely_ ambiguous. It could be read to mean >> the behaviour which Markus described, in which application data (and, >> in fact, anything above the transport layer) is simply suspended until >> rekeying is complete. Or, it could be read to mean that application >> data continues to flow during the rekey. I think if I were a new SSH >> implementor, working in a vacuum, I'd read it to mean that higher-layer >> protocols are _not_ suspended. So if that's not what we mean, then >> maybe this needs to be > > but that could result in the higher layer using the > old keying material forever. Yes, it does. Of course, that would also happen if neither side decided to do a rekey. Once one side starts a rekey, it could certainly _choose_ not to send any application data until it sends a SSH_MSG_NEWKEYS. But as I read the document, it should be prepared to continue to receive application data using the old keys more or less indefinitely. This isn't an interop problem; it just means that one side can choose never to take new keys into use and instead continue to use the old keys for "too long". That said, I'm not actually advocating either behaviour over the other. However, I do think the document needs clarification in this regard. I've been active in this working group for a while now; I've written the specification for a key exchange method, and reviewed a special-purpose host key algorithm which depends on behaviour during a rekey. Until this discussion started, I believed the spec permitted higher-layer protocols to continue during a rekey. If I made that mistake, I wonder how many implementors also did. >> clarified. Bleah. > > I wrote earlier: Yes, your mail was quite clear on what the behaviour should be. But email isn't good enough; future implementors (and probably even some present ones) are going to work from the spec, not the mailing list discussion. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 19 19:52:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23393 for ; Sun, 19 Oct 2003 19:52:04 -0400 (EDT) Received: (qmail 12373 invoked by uid 605); 19 Oct 2003 23:52:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12366 invoked from network); 19 Oct 2003 23:52:05 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 19 Oct 2003 23:52:05 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9JNq0xA013151; Sun, 19 Oct 2003 16:52:00 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9JNpxIr005630; Sun, 19 Oct 2003 19:51:59 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9JNpxAx004282; Sun, 19 Oct 2003 19:51:59 -0400 (EDT) Message-Id: <200310192351.h9JNpxAx004282@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: Jeffrey Hutzelman , Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" In-Reply-To: Your message of "Sun, 19 Oct 2003 12:31:12 +0200." <20031019103112.GA32181@folly> Reply-to: sommerfeld@east.sun.com Date: Sun, 19 Oct 2003 19:51:58 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list So, it looks like the proper repair here is to clearly document what's actually implemented and deployed -- implementations must suspend transport of user data while rekey negotiation is in progress. This is not optimal but it works. For those still not satisfied, I invite anyone who wants "seamless"/non-blocking rekeying to write and submit a draft documenting how to negotiate the use of a different key cutover strategy with a consenting peer. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 20 08:09:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22948 for ; Mon, 20 Oct 2003 08:09:57 -0400 (EDT) Received: (qmail 28205 invoked by uid 605); 20 Oct 2003 12:09:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28197 invoked from network); 20 Oct 2003 12:09:58 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 20 Oct 2003 12:09:58 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 14:07:59 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9KC9luG013007 for ; Mon, 20 Oct 2003 14:09:48 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA14809 for ietf-ssh@netbsd.org; Mon, 20 Oct 2003 13:09:49 +0100 (BST) Date: Mon, 20 Oct 2003 13:09:49 +0100 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031020130948.D11248@edinburgh.cisco.com> References: <20031019103112.GA32181@folly> <200310192351.h9JNpxAx004282@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200310192351.h9JNpxAx004282@thunk.east.sun.com>; from sommerfeld@east.sun.com on Sun, Oct 19, 2003 at 07:51:58PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sun, Oct 19, 2003 at 07:51:58PM -0400, Bill Sommerfeld wrote: > > For those still not satisfied, I invite anyone who wants > "seamless"/non-blocking rekeying to write and submit a draft > documenting how to negotiate the use of a different key cutover > strategy with a consenting peer. Well one problem here is that I believe there is at least one implementation, which does not respond with SSH_MSG_UNIMPLEMENTED to unknown messages. So the (obvious) approach of sending a new Transport Layer message to negotiate it wouldn't work straight away. So how about the following (would need fleshing out): #define SSH_MSG_NONBLOCK_REKEY 22 SSH_MSG_NONBLOCK_REKEY boolean response Then at some point early in the connection, this message is sent followed by one which we expect to get a response to. If we get an UNIMPLEMENTED, fair enougth we know it's not supported. If we get the response to the subsequent packet, again it's not supported. If we get this packet with the response flag, it is supported. I'd guess one convenient place to send the message (for a client) would be between the initial NEWKEYS and the SERVICE_REQUEST. So client sends: NEWKEYS, NONBLOCK_REKEY(response=FALSE), SERVICE_REQUEST and expects to get back one of: NEWKEYS, NONBLOCK_REKEY(response=TRUE), SERVICE_ACCEPT NEWKEYS, UNIMPLEMENTED, SERVICE_ACCEPT NEWKEYS, SERVICE_ACCEPT There could also be a DISCONNECT in there as normal if the service was unacceptable. The question is would anyone DISCONNECT because they didn't understand the NONBLOCK_REKEY packet? Theoreticaly either end could send the NONBLOCK_REKEY message, and they could pass in transit, so one would have to be willing to cope with a request where one wanted a response. However this could be dealt with. Actually, thinking about it. Sending the message before the KEXINIT message may be better - then either end can announce it's support for this. So one would have: NONBLOCK_REKEY(response=FALSE), KEXINIT, ... and expect back one of: NONBLOCK_REKEY(response=TRUE), NEWKEYS, ... UNIMPLEMENTED, NEWKEYS, ... NEWKEYS, ... Thoughts? DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 20 08:42:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23754 for ; Mon, 20 Oct 2003 08:42:54 -0400 (EDT) Received: (qmail 19724 invoked by uid 605); 20 Oct 2003 12:42:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19713 invoked from network); 20 Oct 2003 12:42:58 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 20 Oct 2003 12:42:58 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id B5E3A1EB70; Mon, 20 Oct 2003 14:42:46 +0200 (CEST) Message-ID: <3F93D856.7040807@siliconcircus.com> Date: Mon, 20 Oct 2003 14:43:02 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Fawcus Cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" References: <20031019103112.GA32181@folly> <200310192351.h9JNpxAx004282@thunk.east.sun.com> <20031020130948.D11248@edinburgh.cisco.com> In-Reply-To: <20031020130948.D11248@edinburgh.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Derek Fawcus wrote: > On Sun, Oct 19, 2003 at 07:51:58PM -0400, Bill Sommerfeld wrote: > >>For those still not satisfied, I invite anyone who wants >>"seamless"/non-blocking rekeying to write and submit a draft >>documenting how to negotiate the use of a different key cutover >>strategy with a consenting peer. > > > Well one problem here is that I believe there is at least one > implementation, which does not respond with SSH_MSG_UNIMPLEMENTED > to unknown messages. I've no direct opinion on the rekeying issue, but I don't believe it's unreasonable to treat such implementations as broken and exclude them from discussions about extensions. There is, however, a second point against using SSH_MSG_UNIMPLEMENTED, namely that there's no indication within the message about *which* message was unimplemented. Short of keeping buffers of what's been sent and working out which packet is a response to what, which is probably impractical and certainly unpleasant, it's not possible to use .._UNIMPLEMENTED for implementing extensions anyway. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 20 09:01:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24583 for ; Mon, 20 Oct 2003 09:01:49 -0400 (EDT) Received: (qmail 2561 invoked by uid 605); 20 Oct 2003 13:01:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2548 invoked from network); 20 Oct 2003 13:01:43 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 20 Oct 2003 13:01:43 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 14:59:46 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9KD1YBc027784; Mon, 20 Oct 2003 15:01:35 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA17487; Mon, 20 Oct 2003 14:01:41 +0100 (BST) Date: Mon, 20 Oct 2003 14:01:40 +0100 From: Derek Fawcus To: Jon Bright Cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031020140140.E11248@edinburgh.cisco.com> References: <20031019103112.GA32181@folly> <200310192351.h9JNpxAx004282@thunk.east.sun.com> <20031020130948.D11248@edinburgh.cisco.com> <3F93D856.7040807@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3F93D856.7040807@siliconcircus.com>; from jon@siliconcircus.com on Mon, Oct 20, 2003 at 02:43:02PM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Oct 20, 2003 at 02:43:02PM +0200, Jon Bright wrote: > Derek Fawcus wrote: > > > Well one problem here is that I believe there is at least one > > implementation, which does not respond with SSH_MSG_UNIMPLEMENTED > > to unknown messages. > > I've no direct opinion on the rekeying issue, but I don't believe it's > unreasonable to treat such implementations as broken and exclude them > from discussions about extensions. Well, I'd have to rescan my mailbox to see who's implementation that was. But as I recall, he claimed it was done for security reasons... I do consider that class of "bug" to be different to the bugs in some implementations that require workarounds in other implementations. > There is, however, a second point > against using SSH_MSG_UNIMPLEMENTED, namely that there's no indication > within the message about *which* message was unimplemented. Well - there is the sequence number... > Short of > keeping buffers of what's been sent and working out which packet is a > response to what, which is probably impractical and certainly > unpleasant, Well at the point where I suggested sending it, there would be a pause anyway. It's the initial key exchange. So it would be relatively easy to keep a record of which sequence number the unknown message was sent with, and hence match up the replay. i.e. no long list of buffers. However, we're anticipating that _this_ message may get a response of unimplemented. So we record just the sequence numeber of _this_ message, and if an unimplemented message comes back with this sequence number, we know it's the one we were anticipating. Moreover, the initial key exchange would be done without allowing higher layer messages between the KEXINIT and NEWKEYS. Thereafter if this negotiation (for this extension) worked, one wouldn't have to track the sequence numbers again. > it's not possible to use .._UNIMPLEMENTED for implementing > extensions anyway. Huh? Why not? I just sketched out one way to do it. Or are you stating that it's ugly to do so, hence we shouldn't. One has to ask what purpose UNIMPLEMENTED serves if not as an escape for extensions. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 21 03:15:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08713 for ; Tue, 21 Oct 2003 03:15:06 -0400 (EDT) Received: (qmail 11295 invoked by uid 605); 21 Oct 2003 07:15:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11288 invoked from network); 21 Oct 2003 07:15:01 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 21 Oct 2003 07:15:01 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9L63qRS012418; Tue, 21 Oct 2003 19:03:52 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9L64cF03648; Tue, 21 Oct 2003 19:04:38 +1300 Date: Tue, 21 Oct 2003 19:04:38 +1300 Message-Id: <200310210604.h9L64cF03648@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dfawcus@cisco.com, jon@siliconcircus.com Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Derek Fawcus writes: >Well, I'd have to rescan my mailbox to see who's implementation that was. >But as I recall, he claimed it was done for security reasons... Probably me then, my code never reveals anything that isn't absolutely necessary. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 22 02:39:33 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26390 for ; Wed, 22 Oct 2003 02:39:32 -0400 (EDT) Received: (qmail 24559 invoked by uid 605); 22 Oct 2003 06:39:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24552 invoked from network); 22 Oct 2003 06:39:29 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 22 Oct 2003 06:39:29 -0000 Received: from mindrot.org (85.195.20.10.dhcp.netstarnetworks.com [10.20.195.85] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h9M6gCm08369; Wed, 22 Oct 2003 16:42:19 +1000 Message-ID: <3F9625FA.2090606@mindrot.org> Date: Wed, 22 Oct 2003 16:38:50 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: dfawcus@cisco.com, jon@siliconcircus.com, ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" References: <200310210604.h9L64cF03648@cs.auckland.ac.nz> In-Reply-To: <200310210604.h9L64cF03648@cs.auckland.ac.nz> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Derek Fawcus writes: > > >>Well, I'd have to rescan my mailbox to see who's implementation that was. >>But as I recall, he claimed it was done for security reasons... > > Probably me then, my code never reveals anything that isn't absolutely > necessary. An immediate disconnection reveals about as much as an 'unimplemented' reply. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 22 08:56:45 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06813 for ; Wed, 22 Oct 2003 08:56:43 -0400 (EDT) Received: (qmail 14943 invoked by uid 605); 22 Oct 2003 12:56:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14925 invoked from network); 22 Oct 2003 12:56:45 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 22 Oct 2003 12:56:45 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1ACIXX-0000JM-00; Wed, 22 Oct 2003 13:56:39 +0100 Date: Wed, 22 Oct 2003 13:56:39 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Minor comments on draft-ietf-secsh-filexfer-04 Message-ID: <20031022125639.GA31185@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F81966E.1030903@vandyke.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: > [Jacob Nevins:] > > Section 6.11 "Canonicalizing the Server-Side Path Name" (SSH_FXP_REALPATH): > > It's not too clear how much of the path needs to exist at the time > > REALPATH is invoked. This may cause interoperability problems. > > [snip] > > This one is a little bit trickier-- realpath is often implemented > using the unix library function of the same name, which, I believe, > fails if the path doesn't exist. That's how POSIX appears to define it. However, I've seen indication that some BSD-based realpath()s don't fail in this case. I don't see any big issue with filexfer defining it the same way as POSIX. The only concern is whether clients would be broken by this decision. I know PSFTP/PSCP wouldn't; sounds like your client wouldn't; any others? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 22 11:43:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14906 for ; Wed, 22 Oct 2003 11:43:56 -0400 (EDT) Received: (qmail 702 invoked by uid 605); 22 Oct 2003 15:43:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 695 invoked from network); 22 Oct 2003 15:43:56 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Oct 2003 15:43:56 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9MFhaPh024726; Wed, 22 Oct 2003 09:43:36 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9MFhZ58013195; Wed, 22 Oct 2003 09:43:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9MFdYQx000453; Wed, 22 Oct 2003 08:39:34 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9MFdXqN000452; Wed, 22 Oct 2003 08:39:33 -0700 (PDT) Date: Wed, 22 Oct 2003 08:39:33 -0700 From: Nicolas Williams To: Damien Miller Cc: Peter Gutmann , dfawcus@cisco.com, jon@siliconcircus.com, ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031022153929.GA446@binky.central.sun.com> References: <200310210604.h9L64cF03648@cs.auckland.ac.nz> <3F9625FA.2090606@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9625FA.2090606@mindrot.org> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Oct 22, 2003 at 04:38:50PM +1000, Damien Miller wrote: > Peter Gutmann wrote: > >Derek Fawcus writes: > > > >>Well, I'd have to rescan my mailbox to see who's implementation that was. > >>But as I recall, he claimed it was done for security reasons... > > > >Probably me then, my code never reveals anything that isn't absolutely > >necessary. > > An immediate disconnection reveals about as much as an 'unimplemented' > reply. Yeah, but the former is a lot more annoying... From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 22 20:31:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10820 for ; Wed, 22 Oct 2003 20:31:06 -0400 (EDT) Received: (qmail 29768 invoked by uid 605); 23 Oct 2003 00:31:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29760 invoked from network); 23 Oct 2003 00:31:08 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 23 Oct 2003 00:31:08 -0000 Received: by xanthine.gratuitous.org with local; Wed, 22 Oct 2003 20:30:52 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-weber-secsh-msg-hostkeys-00.txt] Message-Id: Date: Wed, 22 Oct 2003 20:30:52 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list ------- Start of forwarded message ------- To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-weber-secsh-msg-hostkeys-00.txt Date: Mon, 20 Oct 2003 15:43:46 -0400 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SSH_MSG_HOSTKEYS Author(s) : J. Weber Filename : draft-weber-secsh-msg-hostkeys-00.txt Pages : 7 Date : 2003-10-20 This document defines the message SSH_MSG_HOSTKEYS for the Secure Shell transport protocol. This message is used to send host keys for future use, and to provide information about revoked host keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weber-secsh-msg-hostkeys-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weber-secsh-msg-hostkeys-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-weber-secsh-msg-hostkeys-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-20145055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-weber-secsh-msg-hostkeys-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-weber-secsh-msg-hostkeys-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-20145055.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of forwarded message ------- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 23 18:39:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22758 for ; Thu, 23 Oct 2003 18:39:13 -0400 (EDT) Received: (qmail 28527 invoked by uid 605); 23 Oct 2003 22:39:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28520 invoked from network); 23 Oct 2003 22:39:11 -0000 Received: from banister.net (HELO wintermute.sponsor.net) (209.157.166.129) by mail.netbsd.org with SMTP; 23 Oct 2003 22:39:11 -0000 Received: (qmail 93633 invoked by uid 100); 23 Oct 2003 22:40:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Oct 2003 22:40:18 -0000 Date: Thu, 23 Oct 2003 15:40:18 -0700 (PDT) From: Eric Huss X-X-Sender: ehuss@wintermute.sponsor.net To: ietf-ssh@NetBSD.org Subject: comment on draft-ietf-secsh-transport-16.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list There appears to be a typo in this draft. Then penultimate paragraph in section 5.2 (Output from Key Exchange) has the following sentence: If the key length in longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. I assume it should be: If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. (just replacing "length in longer" with "length needed is longer"). -Eric From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 23 19:07:26 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23586 for ; Thu, 23 Oct 2003 19:07:26 -0400 (EDT) Received: (qmail 14260 invoked by uid 605); 23 Oct 2003 23:07:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14156 invoked from network); 23 Oct 2003 23:07:31 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 23 Oct 2003 23:07:31 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9NN7M5u025258; Thu, 23 Oct 2003 17:07:22 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9NN7Mbx021757; Thu, 23 Oct 2003 19:07:22 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9NN7L6o010040; Thu, 23 Oct 2003 19:07:21 -0400 (EDT) Message-Id: <200310232307.h9NN7L6o010040@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Fawcus cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" In-Reply-To: Your message of "Mon, 20 Oct 2003 13:09:49 BST." <20031020130948.D11248@edinburgh.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 23 Oct 2003 19:07:21 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > So one would have: > > NONBLOCK_REKEY(response=FALSE), KEXINIT, ... > > and expect back one of: > > NONBLOCK_REKEY(response=TRUE), NEWKEYS, ... > UNIMPLEMENTED, NEWKEYS, ... > NEWKEYS, ... > > Thoughts? Can this be done asynchronously, early during connection negotiation (or perhaps well before the rekey is needed)? That way, you won't hang waiting for a response which might never arrive... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 23 20:18:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25725 for ; Thu, 23 Oct 2003 20:18:21 -0400 (EDT) Received: (qmail 27941 invoked by uid 605); 24 Oct 2003 00:18:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27934 invoked from network); 24 Oct 2003 00:18:26 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 24 Oct 2003 00:18:26 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2003 02:16:25 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9O0IHhm019311; Fri, 24 Oct 2003 02:18:17 +0200 (MET DST) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA16827; Fri, 24 Oct 2003 01:18:22 +0100 (BST) Date: Fri, 24 Oct 2003 01:18:22 +0100 From: Derek Fawcus To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031024011821.B29676@edinburgh.cisco.com> References: <20031020130948.D11248@edinburgh.cisco.com> <200310232307.h9NN7L6o010040@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200310232307.h9NN7L6o010040@thunk.east.sun.com>; from sommerfeld@east.sun.com on Thu, Oct 23, 2003 at 07:07:21PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Oct 23, 2003 at 07:07:21PM -0400, Bill Sommerfeld wrote: > > So one would have: > > > > NONBLOCK_REKEY(response=FALSE), KEXINIT, ... > > > > and expect back one of: > > > > NONBLOCK_REKEY(response=TRUE), NEWKEYS, ... > > UNIMPLEMENTED, NEWKEYS, ... > > NEWKEYS, ... > > > > Thoughts? > > Can this be done asynchronously, early during connection negotiation > (or perhaps well before the rekey is needed)? That way, you won't > hang waiting for a response which might never arrive... Yes. That was the idea. Do it async before the _initial_ key exchange. Actually the above does sort of imply any response to the NONBLOCK_REKEY message would be delayed until the NEWKEYS is about to be sent. That wasn't my intention. I intended that the messages would be replied to in order, or at least as soon as possible. So one sends the sequence above (without waiting betwen the NONBLOCK_REKEY and the KEXINIT. At that stage one will do the normal KEXINIT algorithm, including the specific key negotiation stuff. So depending upon timing one could have: C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT C<--S NB_RKY(TRUE), KEXINIT, KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT C<--S UNIMP, KEXINIT, KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT C<--S KEXINIT, KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS (All of above are simple and distinguishable) C<--S KEXINIT C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT (pause) C<--S NB_RKY(TRUE), KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS C<--S KEXINIT C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT (pause) C<--S UINMP, KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS C<--S KEXINIT C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT (pause) C<--S KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS (This is the same, but generalised with the server optimising it's TX) C<--S NB_RKY(FALSE), KEXINIT C-->S NB_RKY(FALSE), KEXINIT, KEXDH_INIT C-->S NB_RKY(TRUE) (pause) C<--S NB_RKY(TRUE), KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS (Client and server both send it, server optimised TX) C-->S KEXINIT, KEXDH_INIT C<--S NB_RKY(FALSE), KEXINIT, KEXDH_REPLY, NEWKEYS (pause) C-->S NB_RKY(TRUE), NEWKEYS C-->S KEXINIT, KEXDH_INIT C<--S NB_RKY(FALSE), KEXINIT, KEXDH_REPLY, NEWKEYS (pause) C-->S UNIMP, NEWKEYS C-->S KEXINIT, KEXDH_INIT C<--S NB_RKY(FALSE), KEXINIT, KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS (Server initiates it) C<--S NB_RKY(FALSE), KEXINIT C-->S KEXINIT, KEXDH_INIT (pause) C<--S KEXDH_REPLY, NEWKEYS (pause) C-->S NB_RKY(TRUE), NEWKEYS C<--S NB_RKY(FALSE), KEXINIT C-->S KEXINIT, KEXDH_INIT (pause) C<--S KEXDH_REPLY, NEWKEYS (pause) C-->S UINMP, NEWKEYS C<--S NB_RKY(FALSE), KEXINIT C-->S KEXINIT, KEXDH_INIT (pause) C<--S KEXDH_REPLY, NEWKEYS (pause) C-->S NEWKEYS (Server initiates, and optimising it's TX) A similar analysis applies to dh-group-exchange, since it ultimately boils down to an INIT and REPLAY. I've not looked at the GSS draft (I've no interest in it), but the same rules should apply. A sender of the NONBLOCK_REKEY sends it before sending KEXINIT. Thereafter by the time he receives NEWKEYS he'll know from either the messages received, or a lack of response to the message, if his peer supports it. Since in general both ends have to consider the messages as pipelined rather than strict command-stop-response, this should always work. In fact the response to the NONBLOCK_REKEY (if there is one) could appear at any point in the messages received from the peer, as long as it's before the NEWKEYS message. So the above sequence would be used during the initial keying session (where the session id is created). Either end seeing or sending a NONBLOCK_REKEY(TRUE), means that both ends support the facility. Subsequent rekeys would not have to use the NONBLOCK_REKEY message, as they already know if it's supported. However there is no harm in sending it subsequently, it's just a waste of time to do so. Also the above does not burden implementations that don't wish to support this facility. Only those that do (and initiate the negotiation), have to go to the effort of tracking which packet sequence number they sent the NONBLOCK_REKEY message in such that they can determing if the UNIMPLEMENTED message matches it. Also the fact that the NONBLOCK_REKEY is sent before encryption and/or authentication are engaged does not cause any security problems (that I can see). The worst that could happen is the initial negotiation was broken (DOS attack). It would be possible to prevent this facility from being used if a MiTM changed/deleted the KEXDH_REPLY(TRUE) message, but that's just a performance loss, not a security problem. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 26 21:48:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09001 for ; Sun, 26 Oct 2003 21:48:19 -0500 (EST) Received: (qmail 1161 invoked by uid 605); 27 Oct 2003 02:48:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1139 invoked from network); 27 Oct 2003 02:48:15 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 27 Oct 2003 02:48:15 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9R2mD5u004344; Sun, 26 Oct 2003 19:48:13 -0700 (MST) Received: from [192.168.1.100] (vpn-129-150-17-151.SFBay.Sun.COM [129.150.17.151]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9R2m8Gs513964; Sun, 26 Oct 2003 18:48:08 -0800 (PST) Date: Sun, 26 Oct 2003 18:49:05 -0800 (PST) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-architecture-15.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Ed. Sun Microsystems, Inc Oct 2003 SSH Protocol Architecture draft-ietf-secsh-architecture-15.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate Ylonen & Moffat Expires March 31, 2004 [Page 1] Internet-Draft SSH Protocol Architecture Oct 2003 documents. Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specification of Requirements . . . . . . . . . . . . . . . 3 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 5 4.4 Security Properties . . . . . . . . . . . . . . . . . . . . 6 4.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 6 4.6 Localization and Character Set Support . . . . . . . . . . . 7 5. Data Type Representations Used in the SSH Protocols . . . . 8 6. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 10 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . 12 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 12 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 13 9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 17 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 19 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 19 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 20 9.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 20 9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 21 9.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 21 9.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 21 9.3.4 Public key authentication . . . . . . . . . . . . . . . . . 22 9.3.5 Password authentication . . . . . . . . . . . . . . . . . . 22 9.3.6 Host based authentication . . . . . . . . . . . . . . . . . 23 9.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 23 9.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 23 9.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 23 9.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 24 Normative References . . . . . . . . . . . . . . . . . . . . 24 Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 28 Ylonen & Moffat Expires March 31, 2004 [Page 2] Internet-Draft SSH Protocol Architecture Oct 2003 1. Contributors The major original contributors of this document were: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla) The document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html 2. Introduction SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major components: o The Transport Layer Protocol [SSH-TRANS] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream. o The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. It runs over the transport layer protocol. o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol. The client sends a service request once a secure transport layer connection has been established. A second service request is sent after user authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections. 3. Specification of Requirements All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC2119]. 4. Architecture Ylonen & Moffat Expires March 31, 2004 [Page 3] Internet-Draft SSH Protocol Architecture Oct 2003 4.1 Host Keys Each server host SHOULD have a host key. Hosts MAY have multiple host keys using multiple different algorithms. Multiple hosts MAY share the same host key. If a host has keys at all, it MUST have at least one key using each REQUIRED public key algorithm (DSS [FIPS-186]). The server host key is used during key exchange to verify that the client is really talking to the correct server. For this to be possible, the client must have a priori knowledge of the server's public host key. Two different trust models can be used: o The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure, and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain. o The host name-to-key association is certified by some trusted certification authority. The client only knows the CA root key, and can verify the validity of all host keys certified by accepted CAs. The second alternative eases the maintenance problem, since ideally only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible. Also, a lot of trust is placed on the central infrastructure. The protocol provides the option that the server name - host key association is not checked when connecting to the host for the first time. This allows communication without prior communication of host keys or certification. The connection still provides protection against passive listening; however, it becomes vulnerable to active man-in-the-middle attacks. Implementations SHOULD NOT normally allow such connections by default, as they pose a potential security problem. However, as there is no widely deployed key infrastructure available on the Internet yet, this option makes the protocol much more usable during the transition time until such an infrastructure emerges, while still providing a much higher level of security than that offered by older solutions (e.g. telnet [RFC-854] and rlogin [RFC-1282]). Implementations SHOULD try to make the best effort to check host keys. An example of a possible strategy is to only accept a host key without checking the first time a host is connected, save the key in a local database, and compare against that key on all future Ylonen & Moffat Expires March 31, 2004 [Page 4] Internet-Draft SSH Protocol Architecture Oct 2003 connections to that host. Implementations MAY provide additional methods for verifying the correctness of host keys, e.g. a hexadecimal fingerprint derived from the SHA-1 hash of the public key. Such fingerprints can easily be verified by using telephone or other external communication channels. All implementations SHOULD provide an option to not accept host keys that cannot be verified. We believe that ease of use is critical to end-user acceptance of security solutions, and no improvement in security is gained if the new solutions are not used. Thus, providing the option not to check the server host key is believed to improve the overall security of the Internet, even though it reduces the security of the protocol in configurations where it is allowed. 4.2 Extensibility We believe that the protocol will evolve over time, and some organizations will want to use their own encryption, authentication and/or key exchange methods. Central registration of all extensions is cumbersome, especially for experimental or classified features. On the other hand, having no central registration leads to conflicts in method identifiers, making interoperability difficult. We have chosen to identify algorithms, methods, formats, and extension protocols with textual names that are of a specific format. DNS names are used to create local namespaces where experimental or classified extensions can be defined without fear of conflicts with other implementations. One design goal has been to keep the base protocol as simple as possible, and to require as few algorithms as possible. However, all implementations MUST support a minimal set of algorithms to ensure interoperability (this does not imply that the local policy on all hosts would necessary allow these algorithms). The mandatory algorithms are specified in the relevant protocol documents. Additional algorithms, methods, formats, and extension protocols can be defined in separate drafts. See Section Algorithm Naming (Section 6) for more information. 4.3 Policy Issues The protocol allows full negotiation of encryption, integrity, key exchange, compression, and public key algorithms and formats. Encryption, integrity, public key, and compression algorithms can be Ylonen & Moffat Expires March 31, 2004 [Page 5] Internet-Draft SSH Protocol Architecture Oct 2003 different for each direction. The following policy issues SHOULD be addressed in the configuration mechanisms of each implementation: o Encryption, integrity, and compression algorithms, separately for each direction. The policy MUST specify which is the preferred algorithm (e.g. the first algorithm listed in each category). o Public key algorithms and key exchange method to be used for host authentication. The existence of trusted host keys for different public key algorithms also affects this choice. o The authentication methods that are to be required by the server for each user. The server's policy MAY require multiple authentication for some or all users. The required algorithms MAY depend on the location where the user is trying to log in from. o The operations that the user is allowed to perform using the connection protocol. Some issues are related to security; for example, the policy SHOULD NOT allow the server to start sessions or run commands on the client machine, and MUST NOT allow connections to the authentication agent unless forwarding such connections has been requested. Other issues, such as which TCP/ IP ports can be forwarded and by whom, are clearly issues of local policy. Many of these issues may involve traversing or bypassing firewalls, and are interrelated with the local security policy. 4.4 Security Properties The primary goal of the SSH protocol is improved security on the Internet. It attempts to do this in a way that is easy to deploy, even at the cost of absolute security. o All encryption, integrity, and public key algorithms used are well-known, well-established algorithms. o All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades. o All algorithms are negotiated, and in case some algorithm is broken, it is easy to switch to some other algorithm without modifying the base protocol. Specific concessions were made to make wide-spread fast deployment easier. The particular case where this comes up is verifying that the server host key really belongs to the desired host; the protocol allows the verification to be left out (but this is NOT RECOMMENDED). This is believed to significantly improve usability in the short term, until widespread Internet public key infrastructures emerge. 4.5 Packet Size and Overhead Some readers will worry about the increase in packet size due to new Ylonen & Moffat Expires March 31, 2004 [Page 6] Internet-Draft SSH Protocol Architecture Oct 2003 headers, padding, and MAC. The minimum packet size is in the order of 28 bytes (depending on negotiated algorithms). The increase is negligible for large packets, but very significant for one-byte packets (telnet-type sessions). There are, however, several factors that make this a non-issue in almost all cases: o The minimum size of a TCP/IP header is 32 bytes. Thus, the increase is actually from 33 to 51 bytes (roughly). o The minimum size of the data field of an Ethernet packet is 46 bytes [RFC-894]. Thus, the increase is no more than 5 bytes. When Ethernet headers are considered, the increase is less than 10 percent. o The total fraction of telnet-type data in the Internet is negligible, even with increased packet sizes. The only environment where the packet size increase is likely to have a significant effect is PPP [RFC-1134] over slow modem lines (PPP compresses the TCP/IP headers, emphasizing the increase in packet size). However, with modern modems, the time needed to transfer is in the order of 2 milliseconds, which is a lot faster than people can type. There are also issues related to the maximum packet size. To minimize delays in screen updates, one does not want excessively large packets for interactive sessions. The maximum packet size is negotiated separately for each channel. 4.6 Localization and Character Set Support For the most part, the SSH protocols do not directly pass text that would be displayed to the user. However, there are some places where such data might be passed. When applicable, the character set for the data MUST be explicitly specified. In most places, ISO 10646 with UTF-8 encoding is used [RFC-2279]. When applicable, a field is also provided for a language tag [RFC-3066]. One big issue is the character set of the interactive session. There is no clear solution, as different applications may display data in different formats. Different types of terminal emulation may also be employed in the client, and the character set to be used is effectively determined by the terminal emulation. Thus, no place is provided for directly specifying the character set or encoding for terminal session data. However, the terminal emulation type (e.g. "vt100") is transmitted to the remote site, and it implicitly specifies the character set and encoding. Applications typically use the terminal type to determine what character set they use, or the character set is determined using some external means. The terminal emulation may also allow configuring the default character set. In any case, the character set for the terminal session is considered Ylonen & Moffat Expires March 31, 2004 [Page 7] Internet-Draft SSH Protocol Architecture Oct 2003 primarily a client local issue. Internal names used to identify algorithms or protocols are normally never displayed to users, and must be in US-ASCII. The client and server user names are inherently constrained by what the server is prepared to accept. They might, however, occasionally be displayed in logs, reports, etc. They MUST be encoded using ISO 10646 UTF-8, but other encodings may be required in some cases. It is up to the server to decide how to map user names to accepted user names. Straight bit-wise binary comparison is RECOMMENDED. For localization purposes, the protocol attempts to minimize the number of textual messages transmitted. When present, such messages typically relate to errors, debugging information, or some externally configured data. For data that is normally displayed, it SHOULD be possible to fetch a localized message instead of the transmitted message by using a numerical code. The remaining messages SHOULD be configurable. 5. Data Type Representations Used in the SSH Protocols byte A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. Fixed length data is sometimes represented as an array of bytes, written byte[n], where n is the number of bytes in the array. boolean A boolean value is stored as a single byte. The value 0 represents FALSE, and the value 1 represents TRUE. All non-zero values MUST be interpreted as TRUE; however, applications MUST NOT store values other than 0 and 1. uint32 Represents a 32-bit unsigned integer. Stored as four bytes in the order of decreasing significance (network byte order). For example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 aa. uint64 Represents a 64-bit unsigned integer. Stored as eight bytes in the order of decreasing significance (network byte order). Ylonen & Moffat Expires March 31, 2004 [Page 8] Internet-Draft SSH Protocol Architecture Oct 2003 string Arbitrary length binary string. Strings are allowed to contain arbitrary binary data, including null characters and 8-bit characters. They are stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string. Terminating null characters are not used. Strings are also used to store text. In that case, US-ASCII is used for internal names, and ISO-10646 UTF-8 for text that might be displayed to the user. The terminating null character SHOULD NOT normally be stored in the string. For example, the US-ASCII string "testing" is represented as 00 00 00 07 t e s t i n g. The UTF8 mapping does not alter the encoding of US-ASCII characters. mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data. By convention, a number that is used in modular computations in Z_n SHOULD be represented in the range 0 <= x < n. Examples: value (hex) representation (hex) --------------------------------------------------------------- 0 00 00 00 00 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 80 00 00 00 02 00 80 -1234 00 00 00 02 ed cc -deadbeef 00 00 00 05 ff 21 52 41 11 name-list A string containing a comma separated list of names. A name list is represented as a uint32 containing its length (number of bytes that follow) followed by a comma-separated list of zero or more Ylonen & Moffat Expires March 31, 2004 [Page 9] Internet-Draft SSH Protocol Architecture Oct 2003 names. A name MUST be non-zero length, and it MUST NOT contain a comma (','). Context may impose additional restrictions on the names; for example, the names in a list may have to be valid algorithm identifier (see Algorithm Naming below), or [RFC-3066] language tags. The order of the names in a list may or may not be significant, also depending on the context where the list is is used. Terminating NUL characters are not used, neither for the individual names, nor for the list as a whole. Examples: value representation (hex) --------------------------------------- (), the empty list 00 00 00 00 ("zlib") 00 00 00 04 7a 6c 69 62 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 6. Algorithm Naming The SSH protocols refer to particular hash, encryption, integrity, compression, and key exchange algorithms or protocols by names. There are some standard algorithms that all implementations MUST support. There are also algorithms that are defined in the protocol specification but are OPTIONAL. Furthermore, it is expected that some organizations will want to use their own algorithms. In this protocol, all algorithm identifiers MUST be printable US-ASCII non-empty strings no longer than 64 characters. Names MUST be case-sensitive. There are two formats for algorithm names: o Names that do not contain an at-sign (@) are reserved to be assigned by IETF consensus (RFCs). Examples include `3des-cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part of the name). Names of this format MUST NOT be used without first registering them. Registered names MUST NOT contain an at-sign (@) or a comma (,). o Anyone can define additional algorithms by using names in the format name@domainname, e.g. "ourcipher-cbc@example.com". The format of the part preceding the at sign is not specified; it MUST consist of US-ASCII characters except at-sign and comma. The part following the at-sign MUST be a valid fully qualified internet domain name [RFC-1034] controlled by the person or organization defining the name. It is up to each domain how it manages its local namespace. Ylonen & Moffat Expires March 31, 2004 [Page 10] Internet-Draft SSH Protocol Architecture Oct 2003 7. Message Numbers SSH packets have message numbers in the range 1 to 255. These numbers have been allocated as follows: Transport layer protocol: 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, etc.) 20 to 29 Algorithm negotiation 30 to 49 Key exchange method specific (numbers can be reused for different authentication methods) User authentication protocol: 50 to 59 User authentication generic 60 to 79 User authentication method specific (numbers can be reused for different authentication methods) Connection protocol: 80 to 89 Connection protocol generic 90 to 127 Channel related messages Reserved for client protocols: 128 to 191 Reserved Local extensions: 192 to 255 Local extensions 8. IANA Considerations The initial state of the IANA registry is detailed in [SSH-NUMBERS]. Allocation of the following types of names in the SSH protocols is assigned by IETF consensus: o SSH encryption algorithm names, o SSH MAC algorithm names, o SSH public key algorithm names (public key algorithm also implies encoding and signature/encryption capability), o SSH key exchange method names, and o SSH protocol (service) names. Ylonen & Moffat Expires March 31, 2004 [Page 11] Internet-Draft SSH Protocol Architecture Oct 2003 These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Names with the at-sign ('@') in them are allocated by the owner of DNS name after the at-sign (hierarchical allocation in [RFC-2343]), otherwise the same restrictions as above. Each category of names listed above has a separate namespace. However, using the same name in multiple categories SHOULD be avoided to minimize confusion. Message numbers (see Section Message Numbers (Section 7)) in the range of 0..191 are allocated via IETF consensus; message numbers in the 192..255 range (the "Local extensions" set) are reserved for private use. 9. Security Considerations In order to make the entire body of Security Considerations more accessible, Security Considerations for the transport, authentication, and connection documents have been gathered here. The transport protocol [1] provides a confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [2] provides a suite of mechanisms which can be used to authenticate the client user to the server. Individual mechanisms specified in the in authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol. The connection protocol [3] specifies a mechanism to multiplex multiple streams [channels] of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 9.1 Pseudo-Random Number Generation This protocol binds each session key to the session by including random, session specific data in the hash used to produce session keys. Special care should be taken to ensure that all of the random numbers are of good quality. If the random data here (e.g., DH Ylonen & Moffat Expires March 31, 2004 [Page 12] Internet-Draft SSH Protocol Architecture Oct 2003 parameters) are pseudo-random then the pseudo-random number generator should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, proper entropy needs to be added to the pseudo-random number generator. RFC 1750 [1750] offers suggestions for sources of random numbers and entropy. Implementors should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing pseudo-random number generating functions. The amount of entropy available to a given client or server may sometimes be less than what is required. In this case one must either resort to pseudo-random number generation regardless of insufficient entropy or refuse to run the protocol. The latter is preferable. 9.2 Transport 9.2.1 Confidentiality It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry. At the time of this writing, ciphers commonly in use include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has been accepted by The published as a US Federal Information Processing Standards [FIPS-197] and the cryptographic community as being acceptable for this purpose as well has accepted AES. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410, which will show that its use does not meet the intent of this protocol. The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack Ylonen & Moffat Expires March 31, 2004 [Page 13] Internet-Draft SSH Protocol Architecture Oct 2003 is still deemed difficult and not considered fully practicable especially if relatively longer block sizes are used. Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]) to work, the attacker would need to know the IV of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e it is in the internal buffers of the ssh implementation or even in the kernel) then this attack will not work. If the last packet has been sent out to the network (i.e the attacker has access to it) then he can use the attack. In the optimal case an implementor would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementors may wish to check to see if there are any unsent packets awaiting transmission, but unfortunately it is not normally easy to obtain this information from the kernel or buffers. If there are not, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successfull. As an example, consider the following case: Client Server ------ ------ TCP(seq=x, len=500) -> contains Record 1 [500 ms passes, no ACK] TCP(seq=x, len=1000) -> contains Records 1,2 ACK 1. The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment 2. Record 2 is *not* at the beginning of the TCP segment and never will be, since it gets ACKed. Ylonen & Moffat Expires March 31, 2004 [Page 14] Internet-Draft SSH Protocol Architecture Oct 2003 3. Yet, the attack is possible because Record 1 has already been seen. As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. Ylonen & Moffat Expires March 31, 2004 [Page 15] Internet-Draft SSH Protocol Architecture Oct 2003 On the other hand, it's perfectly safe to have the following situation: Client Server ------ ------ TCP(seq=x, len=500) -> contains SSH_MSG_IGNORE TCP(seq=y, len=500) -> contains Data Provided that the IV for second SSH Record is fixed after the data for the Data packet is determined -i.e. you do: read from user encrypt null packet encrypt data packet 9.2.2 Data Integrity This protocol does allow the Data Integrity mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" MAC is enabled. So long as the "none" MAC is not used, this protocol provides data integrity. Because MACs use a 32 bit sequence number, they might start to leak information after 2**32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [1] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2**28 packets at the very most. 9.2.3 Replay The use of a MAC other than 'none' provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions. For example, the authentication protocol uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange) they cannot be successfully replayed in other sessions. Ylonen & Moffat Expires March 31, 2004 [Page 16] Internet-Draft SSH Protocol Architecture Oct 2003 Note that the session ID can be made public without harming the security of the protocol. If two session happen to have the same session ID [hash of key exchanges] then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more so true when specifying larger hash function outputs and DH parameters. Replay detection using monotonically increasing sequence numbers as input to the MAC, or HMAC in some cases, is described in [RFC2085] /> [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC1510]. The underlying construct is discussed in [RFC2104]. Essentially a different sequence number in each packet ensures that at least this one input to the MAC function will be unique and will provide a nonrecurring MAC output that is not predictable to an attacker. If the session stays active long enough, however, this sequence number will wrap. This event may provide an attacker an opportunity to replay a previously recorded packet with an identical sequence number but only if the peers have not rekeyed since the transmission of the first packet with that sequence number. If the peers have rekeyed, then the replay will be detected as the MAC check will fail. For this reason, it must be emphasized that peers MUST rekey before a wrap of the sequence numbers. Naturally, if an attacker does attempt to replay a captured packet before the peers have rekeyed, then the receiver of the duplicate packet will not be able to validate the MAC and it will be discarded. The reason that the MAC will fail is because the receiver will formulate a MAC based upon the packet contents, the shared secret, and the expected sequence number. Since the replayed packet will not be using that expected sequence number (the sequence number of the replayed packet will have already been passed by the receiver) then the calculated MAC will not match the MAC received with the packet. 9.2.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure or means for distributing the public keys of hosts. It is expected that this protocol will sometimes be used without first verifying the association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This section describes this and encourages administrators and users to understand the importance of verifying this association before any session is initiated. There are three cases of man-in-the-middle attacks to consider. The first is where an attacker places a device between the client and the Ylonen & Moffat Expires March 31, 2004 [Page 17] Internet-Draft SSH Protocol Architecture Oct 2003 server before the session is initiated. In this case, the attack device is trying to mimic the legitimate server and will offer its public key to the client when the client initiates a session. If it were to offer the public key of the server, then it would not be able to decrypt or sign the transmissions between the legitimate server and the client unless it also had access to the private-key of the host. The attack device will also, simultaneously to this, initiate a session to the legitimate server masquerading itself as the client. If the public key of the server had been securely distributed to the client prior to that session initiation, the key offered to the client by the attack device will not match the key stored on the client. In that case, the user SHOULD be given a warning that the offered host key does not match the host key cached on the client. As described in Section 3.1 of [ARCH], the user may be free to accept the new key and continue the session. It is RECOMMENDED that the warning provide sufficient information to the user of the client device so they may make an informed decision. If the user chooses to continue the session with the stored public-key of the server (not the public-key offered at the start of the session), then the session specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session specific data from the server since he does not have the private key of that server. The second case that should be considered is similar to the first case in that it also happens at the time of connection but this case points out the need for the secure distribution of server public keys. If the server public keys are not securely distributed then the client cannot know if it is talking to the intended server. An attacker may use social engineering techniques to pass off server keys to unsuspecting users and may then place a man-in-the-middle attack device between the legitimate server and the clients. If this is allowed to happen then the clients will form client-to-attacker sessions and the attacker will form attacker-to-server sessions and will be able to monitor and manipulate all of the traffic between the clients and the legitimate servers. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also include secured Web pages, physical pieces of paper, etc. Implementors SHOULD provide recommendations on how best to do this with their implementation. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, making the host key fingerprint Ylonen & Moffat Expires March 31, 2004 [Page 18] Internet-Draft SSH Protocol Architecture Oct 2003 available through a secure DNS lookup, or using kerberos over gssapi during key exchange to authenticate the server are possibilities. In the third man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established. As described in the Replay part of this section, a successful attack of this nature is very improbable. As in the Replay section, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yield a known MAC. With that they may be able to alter the contents of a packet in transit. Alternatively the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. In either of those cases, an attacker could construct a packet or packets that could be inserted into an SSH stream. To prevent that, implementors are encouraged to utilize commonly accepted MAC algorithms and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness. In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. It may however be necessary in non-security critical environments, and will still provide protection against passive attacks. Implementors of protocols and applications running on top of this protocol should keep this possibility in mind. 9.2.5 Denial-of-service This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid. In addition, this protocol is vulnerable to Denial of Service attacks because an attacker can force the server to go through the CPU and memory intensive tasks of connection setup and key exchange without authenticating. Implementors SHOULD provide features that make this more difficult. For example, only allowing connections from a subset of IPs known to have valid users. 9.2.6 Covert Channels The protocol was not designed to eliminate covert channels. For Ylonen & Moffat Expires March 31, 2004 [Page 19] Internet-Draft SSH Protocol Architecture Oct 2003 example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way to verify whether such information is being sent. 9.2.7 Forward Secrecy It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS). PFS is essentially defined as the cryptographic property of a key-establishment protocol in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session. [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using diffie-hellman-group1-sha1 are secure even if private keying/ authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSHv2 does have PFS. It is hoped that all other key exchange mechanisms proposed and used in the future will also provide PFS. This property is not commuted to any of the applications or protocols using SSH as a transport however. The transport layer of SSH provides confidentiality for password authentication and other methods that rely on secret data. Of course, if the DH private parameters for the client and server are revealed then the session key is revealed, but these items can be thrown away after the key exchange completes. It's worth pointing out that these items should not be allowed to end up on swap space and that they should be erased from memory as soon as the key exchange completes. 9.3 Authentication Protocol The purpose of this protocol is to perform client user authentication. It assumes that this run over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed. The server may go into a "sleep" period after repeated unsuccessful authentication attempts to make key search more difficult for attackers. Care should be taken so that this doesn't become a self-denial of service vector. Ylonen & Moffat Expires March 31, 2004 [Page 20] Internet-Draft SSH Protocol Architecture Oct 2003 9.3.1 Weak Transport If the transport layer does not provide confidentiality, authentication methods that rely on secret data SHOULD be disabled. If it does not provide strong integrity protection, requests to change authentication data (e.g. a password change) SHOULD be disabled to prevent an attacker from modifying the ciphertext without being noticed, or rendering the new authentication data unusable (denial of service). The assumption as stated above that the Authentication Protocol only run over a secure transport that has previously authenticated the server is very important to note. People deploying SSH are reminded of the consequences of man-in-the-middle attacks if the client does not have a very strong a priori association of the server with the host key of that server. Specifically for the case of the Authentication Protocol the client may form a session to a man-in-the-middle attack device and divulge user credentials such as their username and password. Even in the cases of authentication where no user credentials are divulged, an attacker may still gain information they shouldn't have by capturing key-strokes in much the same way that a honeypot works. 9.3.2 Debug messages Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during user authentication phase) if high security is required. Administrators of host machines should make all attempts to compartmentalize all event notification messages and protect them from unwarranted observation. Developers should be aware of the sensitive nature of some of the normal event messages and debug messages and may want to provide guidance to administrators on ways to keep this information away from unauthorized people. Developers should consider minimizing the amount of sensitive information obtainable by users during the authentication phase in accordance with the local policies. For this reason, it is RECOMMENDED that debug messages be initially disabled at the time of deployment and require an active decision by an administrator to allow them to be enabled. It is also RECOMMENDED that a message expressing this concern be presented to the administrator of a system when the action is taken to enable debugging messages. 9.3.3 Local security policy Implementer MUST ensure that the credentials provided validate the professed user and also MUST ensure that the local policy of the Ylonen & Moffat Expires March 31, 2004 [Page 21] Internet-Draft SSH Protocol Architecture Oct 2003 server permits the user the access requested. In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine the local security policy, if any, that should apply at the time of authentication because the kind of service being requested is not clear at that instant. For example, local policy might allow a user to access files on the server, but not start an interactive shell. However, during the authentication protocol, it is not known whether the user will be accessing files or attempting to use an interactive shell, or even both. In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly. Implementors are encouraged to provide a default local policy and make its parameters known to administrators and users. At the discretion of the implementors, this default policy may be along the lines of 'anything goes' where there are no restrictions placed upon users, or it may be along the lines of 'excessively restrictive' in which case the administrators will have to actively make changes to this policy to meet their needs. Alternatively, it may be some attempt at providing something practical and immediately useful to the administrators of the system so they don't have to put in much effort to get SSH working. Whatever choice is made MUST be applied and enforced as required above. 9.3.4 Public key authentication The use of public-key authentication assumes that the client host has not been compromised. It also assumes that the private-key of the server host has not been compromised. This risk can be mitigated by the use of passphrases on private keys; however, this is not an enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested. The server could require both password and public-key authentication, however, this requires the client to expose its password to the server (see section on password authentication below.) 9.3.5 Password authentication The password mechanism as specified in the authentication protocol assumes that the server has not been compromised. If the server has been compromised, using password authentication will reveal a valid username / password combination to the attacker, which may lead to further compromises. This vulnerability can be mitigated by using an alternative form of Ylonen & Moffat Expires March 31, 2004 [Page 22] Internet-Draft SSH Protocol Architecture Oct 2003 authentication. For example, public-key authentication makes no assumptions about security on the server. 9.3.6 Host based authentication Host based authentication assumes that the client has not been compromised. There are no mitigating strategies, other than to use host based authentication in combination with another authentication method. 9.4 Connection protocol 9.4.1 End point security End point security is assumed by the connection protocol. If the server has been compromised, any terminal sessions, port forwarding, or systems accessed on the host are compromised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 9.4.2 Proxy forwarding The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls. As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise Ylonen & Moffat Expires March 31, 2004 [Page 23] Internet-Draft SSH Protocol Architecture Oct 2003 all data passed over proxy forwarding. 9.4.3 X11 forwarding Another form of proxy forwarding provided by the ssh connection protocol is the forwarding of the X11 protocol. If end-point security has been compromised, X11 forwarding may allow attacks against the X11 server. Users and administrators should, as a matter of course, use appropriate X11 security mechanisms to prevent unauthorized use of the X11 server. Implementors, administrators and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT]. X11 display forwarding with SSH, by itself, is not sufficient to correct well known problems with X11 security [VENEMA]. However, X11 display forwarding in SSHv2 (or other, secure protocols), combined with actual and pseudo-displays which accept connections only over local IPC mechanisms authorized by permissions or ACLs, does correct many X11 security problems as long as the "none" MAC is not used. It is RECOMMENDED that X11 display implementations default to allowing display opens only over local IPC. It is RECOMMENDED that SSHv2 server implementations that support X11 forwarding default to allowing display opens only over local IPC. On single-user systems it might be reasonable to default to allowing local display opens over TCP/IP. Implementors of the X11 forwarding protocol SHOULD implement the magic cookie access checking spoofing mechanism as described in [ssh-connect] as an additional mechanism to prevent unauthorized use of the proxy. Normative References [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf-architecture-15.txt, Oct 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-17.txt, Oct 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-18.txt, Oct 2003. [SSH-CONNECT] Ylonen & Moffat Expires March 31, 2004 [Page 24] Internet-Draft SSH Protocol Architecture Oct 2003 Ylonen, T., "SSH Connection Protocol", I-D draft-ietf-connect-18.txt, Oct 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References [FIPS-186] Federal Information Processing Standards Publication, "FIPS PUB 186, Digital Signature Standard", May 1994. [FIPS-197] National Institue of Standards and Technology, "FIPS 197, Specification for the Advanced Encryption Standard", November 2001. [ANSI T1.523-2001] American National Standards Insitute, Inc., "Telecom Glossary 2000", February 2001. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links", RFC 1134, November 1989. [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. Ylonen & Moffat Expires March 31, 2004 [Page 25] Internet-Draft SSH Protocol Architecture Oct 2003 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", 1996. [KAUFMAN,PERLMAN,SPECINER] Kaufman, C., Perlman, R. and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", 1995. [CERT] CERT Coordination Center, The., "http://www.cert.org/nav/ Ylonen & Moffat Expires March 31, 2004 [Page 26] Internet-Draft SSH Protocol Architecture Oct 2003 index_red.html". [VENEMA] Venema, W., "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose CA http://www.usenix.org/publications/library/proceedings/ sec96/venema.html, July 1996. [ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", Unpublished paper http://www.cs.ucdavis.edu/~rogaway/ papers/draft-rogaway-ipsec-comments-00.txt, 1996. [DAI] Dai, W., "An attack against SSH2 protocol", Email to the SECSH Working Group ietf-ssh@netbsd.org ftp:// ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb 2002. [BELLARE,KOHNO,NAMPREMPRE] Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", , Sept 2002. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Darren J. Moffat (editor) Sun Microsystems, Inc 17 Network Circle Menlo Park CA 94025 USA EMail: Darren.Moffat@Sun.COM Ylonen & Moffat Expires March 31, 2004 [Page 27] Internet-Draft SSH Protocol Architecture Oct 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Ylonen & Moffat Expires March 31, 2004 [Page 28] Internet-Draft SSH Protocol Architecture Oct 2003 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen & Moffat Expires March 31, 2004 [Page 29] -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 26 21:49:33 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09072 for ; Sun, 26 Oct 2003 21:49:32 -0500 (EST) Received: (qmail 1994 invoked by uid 605); 27 Oct 2003 02:49:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1983 invoked from network); 27 Oct 2003 02:49:36 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 27 Oct 2003 02:49:36 -0000 Received: from jurassic.eng.sun.com ([129.146.87.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9R2n5UP008915; Sun, 26 Oct 2003 18:49:05 -0800 (PST) Received: from [192.168.1.100] (vpn-129-150-17-151.SFBay.Sun.COM [129.150.17.151]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9R2n3Gs514036; Sun, 26 Oct 2003 18:49:04 -0800 (PST) Date: Sun, 26 Oct 2003 18:50:01 -0800 (PST) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-assignednumbers-05.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Network Working Group S. Lehtinen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Ed. Sun Microsystems Oct 2003 SSH Protocol Assigned Numbers draft-ietf-secsh-assignednumbers-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for initalization of the IANA databases referenced in those documents. Lehtinen & Moffat Expires March 31, 2004 [Page 1] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 3 3.1 Message Numbers . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1 Disconnect Codes . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Service Names . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Authentication Method Names . . . . . . . . . . . . . . . . 6 3.2.2 Connection Protocol Assigned Names . . . . . . . . . . . . . 6 3.3 Key Exchange Method Names . . . . . . . . . . . . . . . . . 7 3.4 Assigned Algorithm Names . . . . . . . . . . . . . . . . . . 7 3.4.1 Encryption Algorithm Names . . . . . . . . . . . . . . . . . 7 3.4.2 MAC Algorithm Names . . . . . . . . . . . . . . . . . . . . 8 3.4.3 Public Key Algorithm Names . . . . . . . . . . . . . . . . . 8 3.4.4 Compression Algorithm Names . . . . . . . . . . . . . . . . 9 4. Intellectual Property . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . 9 Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Lehtinen & Moffat Expires March 31, 2004 [Page 2] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 1. Introduction This document does not define any new protocols. It is intended only to create the initial state of the IANA databases for the SSH protocol. Except for one HISTORIC algorithm generally regarded as obsolete, this document does not define any new protocols or any number ranges not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT] 2. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119] The used data types and terminology are specified in the architecture document [SSH-ARCH] The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. 3. IANA Considerations 3.1 Message Numbers The Message Number is an 8-bit value, which describes the payload of a packet. Protocol packets have message numbers in the range 1 to 255. These numbers have been allocated as follows in [SSH-ARCH]: Transport layer protocol: 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, etc.) 20 to 29 Algorithm negotiation 30 to 49 Key exchange method specific (numbers can be reused for different authentication methods) User authentication protocol: 50 to 59 User authentication generic 60 to 79 User authentication method specific (numbers can be reused for different authentication methods) Connection protocol: 80 to 89 Connection protocol generic 90 to 127 Channel related messages Lehtinen & Moffat Expires March 31, 2004 [Page 3] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 Reserved for client protocols: 128 to 191 Reserved Local extensions: 192 to 255 Local extensions Requests for assignments of new message numbers must be accompanied by an RFC which describes the new packet type. If the RFC is not on the standards-track (i.e. it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the message number is assigned. Message ID Value Reference ----------- ----- --------- SSH_MSG_DISCONNECT 1 [SSH-TRANS] SSH_MSG_IGNORE 2 [SSH-TRANS] SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] SSH_MSG_DEBUG 4 [SSH-TRANS] SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] SSH_MSG_KEXINIT 20 [SSH-TRANS] SSH_MSG_NEWKEYS 21 [SSH-TRANS] SSH_MSG_KEXDH_INIT 30 [SSH-TRANS] SSH_MSG_KEXDH_REPLY 31 [SSH-TRANS] SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] SSH_MSG_USERAUTH_PK_OK 60 [SSH-USERAUTH] SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT] Lehtinen & Moffat Expires March 31, 2004 [Page 4] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 3.1.1 Disconnect Codes The Disconnect code is an 8-bit value, which describes the disconnect reason. Requests for assignments of new disconnect codes must be accompanied by an RFC which describes the new disconnect reason code. Disconnect code Value Reference ---------------- ----- --------- SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 [SSH-TRANS] SSH_DISCONNECT_PROTOCOL_ERROR 2 [SSH-TRANS] SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 [SSH-TRANS] SSH_DISCONNECT_RESERVED 4 [SSH-TRANS] SSH_DISCONNECT_MAC_ERROR 5 [SSH-TRANS] SSH_DISCONNECT_COMPRESSION_ERROR 6 [SSH-TRANS] SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 [SSH-TRANS] SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 [SSH-TRANS] SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 [SSH-TRANS] SSH_DISCONNECT_CONNECTION_LOST 10 [SSH-TRANS] SSH_DISCONNECT_BY_APPLICATION 11 [SSH-TRANS] SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 [SSH-TRANS] SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 [SSH-TRANS] SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 [SSH-TRANS] SSH_DISCONNECT_ILLEGAL_USER_NAME 15 [SSH-TRANS] 3.2 Service Names The Service Name is used to describe a protocol layer. These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignments of new service names must be accompanied by an RFC which describes the interpretation for the service name. If the RFC is not on the standards-track (i.e. it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the service name is assigned. Service name Reference ------------- --------- ssh-userauth [SSH-USERAUTH] ssh-connection [SSH-CONNECT] Lehtinen & Moffat Expires March 31, 2004 [Page 5] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 3.2.1 Authentication Method Names The Authentication Method Name is used to describe an authentication method for the "ssh-userauth" service [SSH-USERAUTH]. These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignments of new authentication method names must be accompanied by an RFC which describes the interpretation for the authentication method. Method name Reference ------------ --------- publickey [SSH-USERAUTH, Section 4] password [SSH-USERAUTH, Section 5] hostbased [SSH-USERAUTH, Section 6] none [SSH-USERAUTH, Section 2.3] 3.2.2 Connection Protocol Assigned Names The following request and type names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignments of new assigned names must be accompanied by an RFC which describes the interpretation for the type or request. 3.2.2.1 Connection Protocol Channel Types Channel type Reference ------------ --------- session [SSH-CONNECT, Section 4.1] x11 [SSH-CONNECT, Section 4.3.2] forwarded-tcpip [SSH-CONNECT, Section 5.2] direct-tcpip [SSH-CONNECT, Section 5.2] 3.2.2.2 Connection Protocol Global Request Names Request type Reference ------------ --------- tcpip-forward [SSH-CONNECT, Section 5.1] cancel-tcpip-forward [SSH-CONNECT, Section 5.1] Lehtinen & Moffat Expires March 31, 2004 [Page 6] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 3.2.2.3 Connection Protocol Channel Request Names Request type Reference ------------ --------- pty-req [SSH-CONNECT, Section 4.2] x11-req [SSH-CONNECT, Section 4.3.1] env [SSH-CONNECT, Section 4.4] shell [SSH-CONNECT, Section 4.5] exec [SSH-CONNECT, Section 4.5] subsystem [SSH-CONNECT, Section 4.5] window-change [SSH-CONNECT, Section 4.7] xon-xoff [SSH-CONNECT, Section 4.8] signal [SSH-CONNECT, Section 4.9] exit-status [SSH-CONNECT, Section 4.10] exit-signal [SSH-CONNECT, Section 4.10] 3.3 Key Exchange Method Names The Key Exchange Method Name describes a key-exchange method for the protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignment of new key-exchange method names must be accompanied by a reference to a standards-track or Informational RFC which describes this method. Method name Reference ------------ --------- diffie-hellman-group1-sha1 [SSH-TRANS, Section 4.5] 3.4 Assigned Algorithm Names The following identifiers (names) MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignment of new algorithm names must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes the algorithm. 3.4.1 Encryption Algorithm Names Cipher name Reference Lehtinen & Moffat Expires March 31, 2004 [Page 7] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 ------------ --------- 3des-cbc [SSH-TRANS, Section 4.3] blowfish-cbc [SSH-TRANS, Section 4.3] twofish256-cbc [SSH-TRANS, Section 4.3] twofish-cbc [SSH-TRANS, Section 4.3] twofish192-cbc [SSH-TRANS, Section 4.3] twofish128-cbc [SSH-TRANS, Section 4.3] aes256-cbc [SSH-TRANS, Section 4.3] aes192-cbc [SSH-TRANS, Section 4.3] aes128-cbc [SSH-TRANS, Section 4.3] serpent256-cbc [SSH-TRANS, Section 4.3] serpent192-cbc [SSH-TRANS, Section 4.3] serpent128-cbc [SSH-TRANS, Section 4.3] arcfour [SSH-TRANS, Section 4.3] idea-cbc [SSH-TRANS, Section 4.3] cast128-cbc [SSH-TRANS, Section 4.3] none [SSH-TRANS, Section 4.3] des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS 46-3] 3.4.2 MAC Algorithm Names MAC name Reference --------- --------- hmac-sha1 [SSH-TRANS, Section 4.4] hmac-sha1-96 [SSH-TRANS, Section 4.4] hmac-md5 [SSH-TRANS, Section 4.4] hmac-md5-96 [SSH-TRANS, Section 4.4] none [SSH-TRANS, Section 4.4] 3.4.3 Public Key Algorithm Names Algorithm name Reference --------------- --------- ssh-dss [SSH-TRANS, Section 4.6] ssh-rsa [SSH-TRANS, Section 4.6] x509v3-sign-rsa [SSH-TRANS, Section 4.6] x509v3-sign-dss [SSH-TRANS, Section 4.6] spki-sign-rsa [SSH-TRANS, Section 4.6] spki-sign-dss [SSH-TRANS, Section 4.6] pgp-sign-rsa [SSH-TRANS, Section 4.6] pgp-sign-dss [SSH-TRANS, Section 4.6] Lehtinen & Moffat Expires March 31, 2004 [Page 8] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 3.4.4 Compression Algorithm Names Algorithm name Reference --------------- --------- none [SSH-TRANS, Section 4.2] zlib [SSH-TRANS, Section 4.2] 4. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Normative References [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf-architecture-15.txt, Oct 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-17.txt, Oct 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-18.txt, Oct 2003. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-ietf-connect-18.txt, Oct 2003. [SSH-NUMBERS] Lehtinen & Moffat Expires March 31, 2004 [Page 9] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References [FIPS-46-3] U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption Standard (DES)", October 1999. Authors' Addresses Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Darren J Moffat (editor) Sun Microsystems 901 San Antonio Road Palo Alto 94303 USA EMail: Darren.Moffat@Sun.COM Lehtinen & Moffat Expires March 31, 2004 [Page 10] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Lehtinen & Moffat Expires March 31, 2004 [Page 11] Internet-Draft SSH Protocol Assigned Numbers Oct 2003 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lehtinen & Moffat Expires March 31, 2004 [Page 12] -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 26 21:50:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09112 for ; Sun, 26 Oct 2003 21:50:05 -0500 (EST) Received: (qmail 2852 invoked by uid 605); 27 Oct 2003 02:50:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2699 invoked from network); 27 Oct 2003 02:50:05 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 27 Oct 2003 02:50:05 -0000 Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9R2nXxA021862; Sun, 26 Oct 2003 18:49:33 -0800 (PST) Received: from [192.168.1.100] (vpn-129-150-17-151.SFBay.Sun.COM [129.150.17.151]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9R2nUGs514051; Sun, 26 Oct 2003 18:49:30 -0800 (PST) Date: Sun, 26 Oct 2003 18:50:28 -0800 (PST) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-connect-18.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Editor, Ed. Sun Microsystems, Inc Oct 2003 SSH Connection Protocol draft-ietf-secsh-connect-18.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] Internet-Draft SSH Connection Protocol Oct 2003 Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . 3 4. Global Requests . . . . . . . . . . . . . . . . . . . . . . 3 5. Channel Mechanism . . . . . . . . . . . . . . . . . . . . . 4 5.1 Opening a Channel . . . . . . . . . . . . . . . . . . . . . 4 5.2 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 5 5.3 Closing a Channel . . . . . . . . . . . . . . . . . . . . . 6 5.4 Channel-Specific Requests . . . . . . . . . . . . . . . . . 7 6. Interactive Sessions . . . . . . . . . . . . . . . . . . . . 8 6.1 Opening a Session . . . . . . . . . . . . . . . . . . . . . 8 6.2 Requesting a Pseudo-Terminal . . . . . . . . . . . . . . . . 8 6.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 9 6.3.1 Requesting X11 Forwarding . . . . . . . . . . . . . . . . . 9 6.3.2 X11 Channels . . . . . . . . . . . . . . . . . . . . . . . . 10 6.4 Environment Variable Passing . . . . . . . . . . . . . . . . 10 6.5 Starting a Shell or a Command . . . . . . . . . . . . . . . 10 6.6 Session Data Transfer . . . . . . . . . . . . . . . . . . . 11 6.7 Window Dimension Change Message . . . . . . . . . . . . . . 12 6.8 Local Flow Control . . . . . . . . . . . . . . . . . . . . . 12 6.9 Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.10 Returning Exit Status . . . . . . . . . . . . . . . . . . . 13 7. TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 14 7.1 Requesting Port Forwarding . . . . . . . . . . . . . . . . . 14 7.2 TCP/IP Forwarding Channels . . . . . . . . . . . . . . . . . 15 8. Encoding of Terminal Modes . . . . . . . . . . . . . . . . . 16 9. Summary of Message Numbers . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 11. iana cONSiderations . . . . . . . . . . . . . . . . . . . . 19 12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19 Normative References . . . . . . . . . . . . . . . . . . . . 19 Informative References . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] Internet-Draft SSH Connection Protocol Oct 2003 1. Contributors The major original contributors of this document were: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla) The document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html 2. Introduction The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. The service name for this protocol is "ssh-connection". This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation. 3. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. The used data types and terminology are specified in the architecture document [SSH-ARCH]. The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. 4. Global Requests There are several kinds of requests that affect the state of the remote end "globally", independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. All such requests use the following format. byte SSH_MSG_GLOBAL_REQUEST string request name (restricted to US-ASCII) boolean want reply ... request-specific data follows Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] Internet-Draft SSH Connection Protocol Oct 2003 Request names follow the DNS extensibility naming convention outlined in [SSH-ARCH]. The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if `want reply' is TRUE. byte SSH_MSG_REQUEST_SUCCESS ..... response specific data Usually the response specific data is non-existent. If the recipient does not recognize or support the request, it simply responds with SSH_MSG_REQUEST_FAILURE. byte SSH_MSG_REQUEST_FAILURE 5. Channel Mechanism All terminal sessions, forwarded connections, etc. are channels. Either side may open a channel. Multiple channels are multiplexed into a single connection. Channels are identified by numbers at each end. The number referring to a channel may be different on each side. Requests to open a channel contain the sender's channel number. Any other channel-related messages contain the recipient's channel number for the channel. Channels are flow-controlled. No data may be sent to a channel until a message is received to indicate that window space is available. 5.1 Opening a Channel When either side wishes to open a new channel, it allocates a local number for the channel. It then sends the following message to the other side, and includes the local channel number and initial window size in the message. byte SSH_MSG_CHANNEL_OPEN string channel type (restricted to US-ASCII) uint32 sender channel uint32 initial window size uint32 maximum packet size ... channel type specific data follows The channel type is a name as described in the SSH architecture Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] Internet-Draft SSH Connection Protocol Oct 2003 document, with similar extension mechanisms. `sender channel' is a local identifier for the channel used by the sender of this message. `initial window size' specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. `Maximum packet size' specifies the maximum size of an individual data packet that can be sent to the sender (for example, one might want to use smaller packets for interactive connections to get better interactive response on slow links). The remote side then decides whether it can open the channel, and responds with either byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION uint32 recipient channel uint32 sender channel uint32 initial window size uint32 maximum packet size ... channel type specific data follows where `recipient channel' is the channel number given in the original open request, and `sender channel' is the channel number allocated by the other side, or byte SSH_MSG_CHANNEL_OPEN_FAILURE uint32 recipient channel uint32 reason code string additional textual information (ISO-10646 UTF-8 [RFC2279]) string language tag (as defined in [RFC3066]) If the recipient of the SSH_MSG_CHANNEL_OPEN message does not support the specified channel type, it simply responds with SSH_MSG_CHANNEL_OPEN_FAILURE. The client MAY show the additional information to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH]. The following reason codes are defined: #define SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1 #define SSH_OPEN_CONNECT_FAILED 2 #define SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3 #define SSH_OPEN_RESOURCE_SHORTAGE 4 5.2 Data Transfer The window size specifies how many bytes the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] Internet-Draft SSH Connection Protocol Oct 2003 byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 recipient channel uint32 bytes to add After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Data transfer is done with messages of the following type. byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data The maximum amount of data allowed is the current window size. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty. Additionally, some channels can transfer several types of data. An example of this is stderr data from interactive sessions. Such data can be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate integer specifies the type of the data. The available types and their interpretation depend on the type of the channel. byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient_channel uint32 data_type_code string data Data sent with these messages consumes the same window as ordinary data. Currently, only the following type is defined. #define SSH_EXTENDED_DATA_STDERR 1 5.3 Closing a Channel When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF. byte SSH_MSG_CHANNEL_EOF uint32 recipient_channel No explicit response is sent to this message; however, the application may send EOF to whatever is at the other end of the channel. Note that the channel remains open after this message, and Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] Internet-Draft SSH Connection Protocol Oct 2003 more data may still be sent in the other direction. This message does not consume window space and can be sent even if no window space is available. When either party wishes to terminate the channel, it sends SSH_MSG_CHANNEL_CLOSE. Upon receiving this message, a party MUST send back a SSH_MSG_CHANNEL_CLOSE unless it has already sent this message for the channel. The channel is considered closed for a party when it has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then reuse the channel number. A party MAY send SSH_MSG_CHANNEL_CLOSE without having sent or received SSH_MSG_CHANNEL_EOF. byte SSH_MSG_CHANNEL_CLOSE uint32 recipient_channel This message does not consume window space and can be sent even if no window space is available. It is recommended that any data sent before this message is delivered to the actual destination, if possible. 5.4 Channel-Specific Requests Many channel types have extensions that are specific to that particular channel type. An example is requesting a pty (pseudo terminal) for an interactive session. All channel-specific requests use the following format. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string request type (restricted to US-ASCII) boolean want reply ... type-specific data If want reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. This message does not consume window space and can be sent even if no window space is available. Request types are local to each channel type. The client is allowed to send further messages without waiting for the response to the request. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] Internet-Draft SSH Connection Protocol Oct 2003 request type names follow the DNS extensibility naming convention outlined in [SSH-ARCH] byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient_channel byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel These messages do not consume window space and can be sent even if no window space is available. 6. Interactive Sessions A session is a remote execution of a program. The program may be a shell, an application, a system command, or some built-in subsystem. It may or may not have a tty, and may or may not involve X11 forwarding. Multiple sessions can be active simultaneously. 6.1 Opening a Session A session is started by sending the following message. byte SSH_MSG_CHANNEL_OPEN string "session" uint32 sender channel uint32 initial window size uint32 maximum packet size Client implementations SHOULD reject any session channel open requests to make it more difficult for a corrupt server to attack the client. 6.2 Requesting a Pseudo-Terminal A pseudo-terminal can be allocated for the session by sending the following message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "pty-req" boolean want_reply string TERM environment variable value (e.g., vt100) uint32 terminal width, characters (e.g., 80) uint32 terminal height, rows (e.g., 24) uint32 terminal width, pixels (e.g., 640) uint32 terminal height, pixels (e.g., 480) Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] Internet-Draft SSH Connection Protocol Oct 2003 string encoded terminal modes The encoding of terminal modes is described in Section Encoding of Terminal Modes (Section 8). Zero dimension parameters MUST be ignored. The character/row dimensions override the pixel dimensions (when nonzero). Pixel dimensions refer to the drawable area of the window. The dimension parameters are only informational. The client SHOULD ignore pty requests. 6.3 X11 Forwarding 6.3.1 Requesting X11 Forwarding X11 forwarding may be requested for a session by sending byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "x11-req" boolean want reply boolean single connection string x11 authentication protocol string x11 authentication cookie uint32 x11 screen number It is recommended that the authentication cookie that is sent be a fake, random cookie, and that the cookie is checked and replaced by the real cookie when a connection request is received. X11 connection forwarding should stop when the session channel is closed; however, already opened forwardings should not be automatically closed when the session channel is closed. If `single connection' is TRUE, only a single connection should be forwarded. No more connections will be forwarded after the first, or after the session channel has been closed. The "x11 authentication protocol" is the name of the X11 authentication method used, e.g. "MIT-MAGIC-COOKIE-1". The x11 authentication cookie MUST be hexadecimal encoded. X Protocol is documented in [SCHEIFLER]. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] Internet-Draft SSH Connection Protocol Oct 2003 6.3.2 X11 Channels X11 channels are opened with a channel open request. The resulting channels are independent of the session, and closing the session channel does not close the forwarded X11 channels. byte SSH_MSG_CHANNEL_OPEN string "x11" uint32 sender channel uint32 initial window size uint32 maximum packet size string originator address (e.g. "192.168.7.38") uint32 originator port The recipient should respond with SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE. Implementations MUST reject any X11 channel open requests if they have not requested X11 forwarding. 6.4 Environment Variable Passing Environment variables may be passed to the shell/command to be started later. Uncontrolled setting of environment variables in a privileged process can be a security hazard. It is recommended that implementations either maintain a list of allowable variable names or only set environment variables after the server process has dropped sufficient privileges. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "env" boolean want reply string variable name string variable value 6.5 Starting a Shell or a Command Once the session has been set up, a program is started at the remote end. The program can be a shell, an application program or a subsystem with a host-independent name. Only one of these requests can succeed per channel. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "shell" boolean want reply Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] Internet-Draft SSH Connection Protocol Oct 2003 This message will request the user's default shell (typically defined in /etc/passwd in UNIX systems) to be started at the other end. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exec" boolean want reply string command This message will request the server to start the execution of the given command. The command string may contain a path. Normal precautions MUST be taken to prevent the execution of unauthorized commands. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string subsystem name This last form executes a predefined subsystem. It is expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish it from arbitrary output generated by shell initialization scripts etc. This spurious output from the shell may be filtered out either at the server or at the client. The server SHOULD not halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel. It is RECOMMENDED to request and check the reply for these messages. The client SHOULD ignore these messages. Subsystem names follow the DNS extensibility naming convention outlined in [SSH-ARCH]. 6.6 Session Data Transfer Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism. The extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr data. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] Internet-Draft SSH Connection Protocol Oct 2003 6.7 Window Dimension Change Message When the window (terminal) size changes on the client side, it MAY send a message to the other side to inform it of the new dimensions. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "window-change" boolean FALSE uint32 terminal width, columns uint32 terminal height, rows uint32 terminal width, pixels uint32 terminal height, pixels No response SHOULD be sent to this message. 6.8 Local Flow Control On many systems, it is possible to determine if a pseudo-terminal is using control-S/control-Q flow control. When flow control is allowed, it is often desirable to do the flow control at the client end to speed up responses to user requests. This is facilitated by the following notification. Initially, the server is responsible for flow control. (Here, again, client means the side originating the session, and server means the other side.) The message below is used by the server to inform the client when it can or cannot perform flow control (control-S/control-Q processing). If `client can do' is TRUE, the client is allowed to do flow control using control-S and control-Q. The client MAY ignore this message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "xon-xoff" boolean FALSE boolean client can do No response is sent to this message. 6.9 Signals A signal can be delivered to the remote process/service using the following message. Some systems may not implement signals, in which case they SHOULD ignore this message. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "signal" Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] Internet-Draft SSH Connection Protocol Oct 2003 boolean FALSE string signal name without the "SIG" prefix. Signal names will be encoded as discussed in the "exit-signal" SSH_MSG_CHANNEL_REQUEST. 6.10 Returning Exit Status When the command running at the other end terminates, the following message can be sent to return the exit status of the command. Returning the status is RECOMMENDED. No acknowledgment is sent for this message. The channel needs to be closed with SSH_MSG_CHANNEL_CLOSE after this message. The client MAY ignore these messages. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "exit-status" boolean FALSE uint32 exit_status The remote command may also terminate violently due to a signal. Such a condition can be indicated by the following message. A zero exit_status usually means that the command terminated successfully. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "exit-signal" boolean FALSE string signal name without the "SIG" prefix. boolean core dumped string error message (ISO-10646 UTF-8) string language tag (as defined in [RFC3066]) The signal name is one of the following (these are from [POSIX]) ABRT ALRM FPE HUP ILL INT KILL PIPE QUIT SEGV TERM Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] Internet-Draft SSH Connection Protocol Oct 2003 USR1 USR2 Additional signal names MAY be sent in the format "sig-name@xyz", where `sig-name' and `xyz' may be anything a particular implementor wants (except the `@' sign). However, it is suggested that if a `configure' script is used, the non-standard signal names it finds be encoded as "SIG@xyz.config.guess", where `SIG' is the signal name without the "SIG" prefix, and `xyz' be the host type, as determined by `config.guess'. The `error message' contains an additional explanation of the error message. The message may consist of multiple lines. The client software MAY display this message to the user. If this is done, the client software should take the precautions discussed in [SSH-ARCH]. 7. TCP/IP Port Forwarding 7.1 Requesting Port Forwarding A party need not explicitly request forwardings from its own end to the other direction. However, if it wishes that connections to a port on the other side be forwarded to the local side, it must explicitly request this. byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want reply string address to bind (e.g. "0.0.0.0") uint32 port number to bind `Address to bind' and `port number to bind' specify the IP address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. (Note that the client can still filter connections based on information passed in the open request.) Implementations should only allow forwarding privileged ports if the user has been authenticated as a privileged user. Client implementations SHOULD reject these messages; they are normally only sent by the client. If a client passes 0 as port number to bind and has want reply TRUE then the server allocates the next available unprivileged port number and replies with the following message, otherwise there is no Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] Internet-Draft SSH Connection Protocol Oct 2003 response specific data. byte SSH_MSG_GLOBAL_REQUEST_SUCCESS uint32 port that was bound on the server A port forwarding can be cancelled with the following message. Note that channel open requests may be received until a reply to this message is received. byte SSH_MSG_GLOBAL_REQUEST string "cancel-tcpip-forward" boolean want reply string address_to_bind (e.g. "127.0.0.1") uint32 port number to bind Client implementations SHOULD reject these messages; they are normally only sent by the client. 7.2 TCP/IP Forwarding Channels When a connection comes to a port for which remote forwarding has been requested, a channel is opened to forward the port to the other side. byte SSH_MSG_CHANNEL_OPEN string "forwarded-tcpip" uint32 sender channel uint32 initial window size uint32 maximum packet size string address that was connected uint32 port that was connected string originator IP address uint32 originator port Implementations MUST reject these messages unless they have previously requested a remote TCP/IP port forwarding with the given port number. When a connection comes to a locally forwarded TCP/IP port, the following packet is sent to the other side. Note that these messages MAY be sent also for ports for which no forwarding has been explicitly requested. The receiving side must decide whether to allow the forwarding. byte SSH_MSG_CHANNEL_OPEN string "direct-tcpip" uint32 sender channel Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] Internet-Draft SSH Connection Protocol Oct 2003 uint32 initial window size uint32 maximum packet size string host to connect uint32 port to connect string originator IP address uint32 originator port `Host to connect' and `port to connect' specify the TCP/IP host and port where the recipient should connect the channel. `Host to connect' may be either a domain name or a numeric IP address. `Originator IP address' is the numeric IP address of the machine where the connection request comes from, and `originator port' is the port on the originator host from where the connection came from. Forwarded TCP/IP channels are independent of any sessions, and closing a session channel does not in any way imply that forwarded connections should be closed. Client implementations SHOULD reject direct TCP/IP open requests for security reasons. 8. Encoding of Terminal Modes Terminal modes (as passed in a pty request) are encoded into a byte stream. It is intended that the coding be portable across different environments. The tty mode description is a stream of bytes. The stream consists of opcode-argument pairs. It is terminated by opcode TTY_OP_END (0). Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined, and cause parsing to stop (they should only be used after any other data). The client SHOULD put in the stream any modes it knows about, and the server MAY ignore any modes it does not know about. This allows some degree of machine-independence, at least between systems that use a POSIX-like tty interface. The protocol can support other systems as well, but the client may need to fill reasonable values for a number of parameters so the server pty gets set to a reasonable mode (the server leaves all unspecified mode bits in their default values, and only some combinations make sense). The following opcodes have been defined. The naming of opcodes mostly follows the POSIX terminal mode flags. 0 TTY_OP_END Indicates end of options. 1 VINTR Interrupt character; 255 if none. Similarly for the Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] Internet-Draft SSH Connection Protocol Oct 2003 other characters. Not all of these characters are supported on all systems. 2 VQUIT The quit character (sends SIGQUIT signal on POSIX systems). 3 VERASE Erase the character to left of the cursor. 4 VKILL Kill the current input line. 5 VEOF End-of-file character (sends EOF from the terminal). 6 VEOL End-of-line character in addition to carriage return and/or linefeed. 7 VEOL2 Additional end-of-line character. 8 VSTART Continues paused output (normally control-Q). 9 VSTOP Pauses output (normally control-S). 10 VSUSP Suspends the current program. 11 VDSUSP Another suspend character. 12 VREPRINT Reprints the current input line. 13 VWERASE Erases a word left of cursor. 14 VLNEXT Enter the next character typed literally, even if it is a special character 15 VFLUSH Character to flush output. 16 VSWTCH Switch to a different shell layer. 17 VSTATUS Prints system status line (load, command, pid etc). 18 VDISCARD Toggles the flushing of terminal output. 30 IGNPAR The ignore parity flag. The parameter SHOULD be 0 if this flag is FALSE set, and 1 if it is TRUE. 31 PARMRK Mark parity and framing errors. 32 INPCK Enable checking of parity errors. 33 ISTRIP Strip 8th bit off characters. 34 INLCR Map NL into CR on input. 35 IGNCR Ignore CR on input. 36 ICRNL Map CR to NL on input. 37 IUCLC Translate uppercase characters to lowercase. 38 IXON Enable output flow control. 39 IXANY Any char will restart after stop. 40 IXOFF Enable input flow control. 41 IMAXBEL Ring bell on input queue full. 50 ISIG Enable signals INTR, QUIT, [D]SUSP. 51 ICANON Canonicalize input lines. 52 XCASE Enable input and output of uppercase characters by preceding their lowercase equivalents with `\'. 53 ECHO Enable echoing. 54 ECHOE Visually erase chars. 55 ECHOK Kill character discards current line. 56 ECHONL Echo NL even if ECHO is off. 57 NOFLSH Don't flush after interrupt. 58 TOSTOP Stop background jobs from output. 59 IEXTEN Enable extensions. 60 ECHOCTL Echo control characters as ^(Char). 61 ECHOKE Visual erase for line kill. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] Internet-Draft SSH Connection Protocol Oct 2003 62 PENDIN Retype pending input. 70 OPOST Enable output processing. 71 OLCUC Convert lowercase to uppercase. 72 ONLCR Map NL to CR-NL. 73 OCRNL Translate carriage return to newline (output). 74 ONOCR Translate newline to carriage return-newline (output). 75 ONLRET Newline performs a carriage return (output). 90 CS7 7 bit mode. 91 CS8 8 bit mode. 92 PARENB Parity enable. 93 PARODD Odd parity, else even. 128 TTY_OP_ISPEED Specifies the input baud rate in bits per second. 129 TTY_OP_OSPEED Specifies the output baud rate in bits per second. 9. Summary of Message Numbers #define SSH_MSG_GLOBAL_REQUEST 80 #define SSH_MSG_REQUEST_SUCCESS 81 #define SSH_MSG_REQUEST_FAILURE 82 #define SSH_MSG_CHANNEL_OPEN 90 #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 #define SSH_MSG_CHANNEL_OPEN_FAILURE 92 #define SSH_MSG_CHANNEL_WINDOW_ADJUST 93 #define SSH_MSG_CHANNEL_DATA 94 #define SSH_MSG_CHANNEL_EXTENDED_DATA 95 #define SSH_MSG_CHANNEL_EOF 96 #define SSH_MSG_CHANNEL_CLOSE 97 #define SSH_MSG_CHANNEL_REQUEST 98 #define SSH_MSG_CHANNEL_SUCCESS 99 #define SSH_MSG_CHANNEL_FAILURE 100 10. Security Considerations This protocol is assumed to run on top of a secure, authenticated transport. User authentication and protection against network-level attacks are assumed to be provided by the underlying protocols. It is RECOMMENDED that implementations disable all the potentially dangerous features (e.g. agent forwarding, X11 forwarding, and TCP/IP forwarding) if the host key has changed. Full security considerations for this protocol are provided in Section 8 of [SSH-ARCH] Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18] Internet-Draft SSH Connection Protocol Oct 2003 11. iana cONSiderations This document is part of a set, the IANA considerations for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT] are detailed in [SSH-NUMBERS]. 12. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Normative References [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf-architecture-15.txt, Oct 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-17.txt, Oct 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-18.txt, Oct 2003. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-ietf-connect-18.txt, Oct 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19] Internet-Draft SSH Connection Protocol Oct 2003 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. [POSIX] ISO/IEC, 9945-1., "Information technology -- Portable Operating System Interface (POSIX)-Part 1: System Application Program Interface (API) C Language", ANSI/IEE Std 1003.1, July 1996. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Darren J. Moffat (editor) Sun Microsystems, Inc 17 Network Circle Menlo Park CA 94025 USA EMail: Darren.Moffat@Sun.COM Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20] Internet-Draft SSH Connection Protocol Oct 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21] Internet-Draft SSH Connection Protocol Oct 2003 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22] -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 26 21:50:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09168 for ; Sun, 26 Oct 2003 21:50:37 -0500 (EST) Received: (qmail 3412 invoked by uid 605); 27 Oct 2003 02:50:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3399 invoked from network); 27 Oct 2003 02:50:35 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 27 Oct 2003 02:50:35 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9R2oY5u004887; Sun, 26 Oct 2003 19:50:34 -0700 (MST) Received: from [192.168.1.100] (vpn-129-150-17-151.SFBay.Sun.COM [129.150.17.151]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9R2oWGs514111; Sun, 26 Oct 2003 18:50:32 -0800 (PST) Date: Sun, 26 Oct 2003 18:51:29 -0800 (PST) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-userauth-18.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 2, 2003 D. Moffat, Ed. Sun Microsystems, Inc September 2002 SSH Authentication Protocol draft-ietf-secsh-userauth-18.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. Ylonen & Moffat Expires March 2, 2003 [Page 1] Internet-Draft SSH Authentication Protocol September 2002 Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . 3 3.1 The Authentication Protocol Framework . . . . . . . . . . . 3 3.1.1 Authentication Requests . . . . . . . . . . . . . . . . . . 4 3.1.2 Responses to Authentication Requests . . . . . . . . . . . . 5 3.1.3 The "none" Authentication Request . . . . . . . . . . . . . 6 3.1.4 Completion of User Authentication . . . . . . . . . . . . . 6 3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Authentication Protocol Message Numbers . . . . . . . . . . 7 3.3 Public Key Authentication Method: publickey . . . . . . . . 8 3.4 Password Authentication Method: password . . . . . . . . . . 10 3.5 Host-Based Authentication: hostbased . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . 12 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . 15 Ylonen & Moffat Expires March 2, 2003 [Page 2] Internet-Draft SSH Authentication Protocol September 2002 1. Contributors The major original contributors of this document were: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla) The document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html 2. Introduction The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. This protocol assumes that the underlying protocols provide integrity and confidentiality protection. This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation. The service name for this protocol is "ssh-userauth". When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower-level protocol provides confidentiality protection. 3. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119] The used data types and terminology are specified in the architecture document [SSH-ARCH] The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. 3.1 The Authentication Protocol Framework The server drives the authentication by telling the client which Ylonen & Moffat Expires March 2, 2003 [Page 3] Internet-Draft SSH Authentication Protocol September 2002 authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server. Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be allowed in without any authentication, in which case the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server. The server SHOULD have a timeout for authentication, and disconnect if the authentication has not been accepted within the timeout period. The RECOMMENDED timeout period is 10 minutes. Additionally, the implementation SHOULD limit the number of failed authentication attempts a client may perform in a single session (the RECOMMENDED limit is 20 attempts). If the threshold is exceeded, the server SHOULD disconnect. 3.1.1 Authentication Requests All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method. byte SSH_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding [RFC2279]) string service name (in US-ASCII) string method name (US-ASCII) The rest of the packet is method-specific. The user name and service are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated authentication states if they change. If it is unable to flush some authentication state, it MUST disconnect if the user or service name changes. The service name specifies the service to start after authentication. There may be several different authenticated services provided. If the requested service is not available, the server MAY disconnect immediately or at any later time. Sending a proper disconnect message is RECOMMENDED. In any case, if the service does not exist, Ylonen & Moffat Expires March 2, 2003 [Page 4] Internet-Draft SSH Authentication Protocol September 2002 authentication MUST NOT be accepted. If the requested user does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentication methods, but never accept any. This makes it possible for the server to avoid disclosing information on which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted. While there is usually little point for clients to send requests that the server does not list as acceptable, sending such requests is not an error, and the server SHOULD simply reject requests that it does not recognize. An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. 3.1.2 Responses to Authentication Requests If the server rejects the authentication request, it MUST respond with the following: byte SSH_MSG_USERAUTH_FAILURE string authentications that can continue boolean partial success "Authentications that can continue" is a comma-separated list of authentication method names that may productively continue the authentication dialog. It is RECOMMENDED that servers only include those methods in the list that are actually useful. However, it is not illegal to include methods that cannot be used to authenticate the user. Already successfully completed authentications SHOULD NOT be included in the list, unless they really should be performed again for some reason. "Partial success" MUST be TRUE if the authentication request to which this is a response was successful. It MUST be FALSE if the request was not successfully processed. When the server accepts authentication, it MUST respond with the following: Ylonen & Moffat Expires March 2, 2003 [Page 5] Internet-Draft SSH Authentication Protocol September 2002 byte SSH_MSG_USERAUTH_SUCCESS Note that this is not sent after each step in a multi-method authentication sequence, but only when the authentication is complete. The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST process each request completely and acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message before processing the next request. A request that results in further exchange of messages will be aborted by a second request. It is not possible to send a second request without waiting for a response from the server, if the first request will result in further exchange of messages. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. Any non-authentication messages sent by the client after the request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. Such messages can be identified by their message numbers (see Section Message Numbers (Section 3.2)). 3.1.3 The "none" Authentication Request A client may request a list of authentication methods that may continue by using the "none" authentication method. If no authentication at all is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication methods that can continue. This method MUST NOT be listed as supported by the server. 3.1.4 Completion of User Authentication Authentication is complete when the server has responded with SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received after sending this message SHOULD be silently ignored. After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested service. Ylonen & Moffat Expires March 2, 2003 [Page 6] Internet-Draft SSH Authentication Protocol September 2002 3.1.5 Banner Message In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from `/etc/issue', or use "tcp wrappers" or similar software to display a banner before issuing a login prompt. The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time before authentication is successful. This message contains text to be displayed to the client user before authentication is attempted. The format is as follows: byte SSH_MSG_USERAUTH_BANNER string message (ISO-10646 UTF-8) string language tag (as defined in [RFC3066]) The client SHOULD by default display the message on the screen. However, since the message is likely to be sent for every login attempt, and since some client software will need to open a separate window for this warning, the client software may allow the user to explicitly disable the display of banners from the server. The message may consist of multiple lines. If the message string is displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending terminal control characters. 3.2 Authentication Protocol Message Numbers All message numbers used by this authentication protocol are in the range from 50 to 79, which is part of the range reserved for protocols running on top of the SSH transport layer protocol. Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting (preferably with a proper disconnect message sent first to ease troubleshooting). After successful authentication, such messages are passed to the higher-level service. These are the general authentication message codes: #define SSH_MSG_USERAUTH_REQUEST 50 #define SSH_MSG_USERAUTH_FAILURE 51 #define SSH_MSG_USERAUTH_SUCCESS 52 Ylonen & Moffat Expires March 2, 2003 [Page 7] Internet-Draft SSH Authentication Protocol September 2002 #define SSH_MSG_USERAUTH_BANNER 53 In addition to the above, there is a range of message numbers (60..79) reserved for method-specific messages. These messages are only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). Different authentication methods reuse the same message numbers. 3.3 Public Key Authentication Method: publickey The only REQUIRED authentication method is public key authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in the near future. With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the signature is valid. If both hold, the authentication request MUST be accepted; otherwise it MUST be rejected. (Note that the server MAY require additional authentications after successful authentication.) Private keys are often stored in an encrypted form at the client host, and the user must supply a passphrase before the signature can be generated. Even if they are not, the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the key would be acceptable. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean FALSE string public key algorithm name string public key blob Public key algorithms are defined in the transport layer specification [SSH-TRANS]. The public key blob may contain certificates. Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange. If the server does not support some algorithm, it MUST simply reject the request. The server MUST respond to this message with either Ylonen & Moffat Expires March 2, 2003 [Page 8] Internet-Draft SSH Authentication Protocol September 2002 SSH_MSG_USERAUTH_FAILURE or with the following: byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request To perform actual authentication, the client MAY then send a signature generated using the private key. The client MAY send the signature directly without first verifying whether the key is acceptable. The signature is sent using the following packet: byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication string signature Signature is a signature by the corresponding private key over the following data, in the following order: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct. If both checks succeed, this method is successful. Note that the server may require additional authentications. The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed). The following method-specific message numbers are used by the publickey authentication method. /* Key-based */ #define SSH_MSG_USERAUTH_PK_OK 60 Ylonen & Moffat Expires March 2, 2003 [Page 9] Internet-Draft SSH Authentication Protocol September 2002 3.4 Password Authentication Method: password Password authentication uses the following packets. Note that a server MAY request the user to change the password. All implementations SHOULD support password authentication. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "password" boolean FALSE string plaintext password (ISO-10646 UTF-8) Note that the password is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the password and validates it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords. Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Both the server and the client should check whether the underlying transport layer provides confidentiality (i.e., if encryption is being used). If no confidentiality is provided (none cipher), password authentication SHOULD be disabled. If there is no confidentiality or no MAC, password change SHOULD be disabled. Normally, the server responds to this message with success or failure. However, if the password has expired the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In anycase the server MUST NOT allow an expired password to be used for authentication. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC3066]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. byte SSH_MSG_USERAUTH_REQUEST string user name string service Ylonen & Moffat Expires March 2, 2003 [Page 10] Internet-Draft SSH Authentication Protocol September 2002 string "password" boolean TRUE string plaintext old password (ISO-10646 UTF-8) string plaintext new password (ISO-10646 UTF-8) The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as follows: SSH_MSG_USERAUTH_SUCCESS The password has been changed, and authentication has been successfully completed. SSH_MSG_USERAUTH_FAILURE with partial success The password has been changed, but more authentications are needed. SSH_MSG_USERAUTH_FAILURE without partial success The password has not been changed. Either password changing was not supported, or the old password was bad. Note that if the server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports changing the password. SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because the new password was not acceptable (e.g. too easy to guess). The following method-specific message numbers are used by the password authentication method. #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 3.5 Host-Based Authentication: hostbased Some sites wish to allow authentication based on the host where the user is coming from, and the user name on the remote host. While this form of authentication is not suitable for high-security sites, it can be very convenient in many environments. This form of authentication is OPTIONAL. When used, special care SHOULD be taken to prevent a regular user from obtaining the private host key. The client requests this form of authentication by sending the following message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of authentication, except that the identity of the client host is checked more rigorously. This method works by having the client send a signature created with the private key of the client host, which the server checks with that host's public key. Once the client host's identity is established, Ylonen & Moffat Expires March 2, 2003 [Page 11] Internet-Draft SSH Authentication Protocol September 2002 authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name (FQDN; US-ASCII) string user name on the client host (ISO-10646 UTF-8) string signature Public key algorithm names for use in "public key algorithm for host key" are defined in the transport layer specification. The "public host key for client host" may include certificates. Signature is a signature with the private host key of the following data, in this order: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name (FQDN; US-ASCII) string user name on the client host(ISO-10646 UTF-8) The server MUST verify that the host key actually belongs to the client host named in the message, that the given user on that host is allowed to log in, and that the signature is a valid signature on the appropriate value by the given host key. The server MAY ignore the client user name, if it wants to authenticate only the client host. It is RECOMMENDED that whenever possible, the server perform additional checks to verify that the network address obtained from the (untrusted) network matches the given client host name. This makes exploiting compromised host keys more difficult. Note that this may require special handling for connections coming through a firewall. 4. Security Considerations The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport Ylonen & Moffat Expires March 2, 2003 [Page 12] Internet-Draft SSH Authentication Protocol September 2002 layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. The transport layer provides forward secrecy for password authentication and other methods that rely on secret data. Full security considerations for this protocol are provided in Section 8 of [SSH-ARCH] Normative [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf-architecture-15.txt, Oct 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-17.txt, Oct 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-18.txt, Oct 2003. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-ietf-connect-18.txt, Oct 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Ylonen & Moffat Expires March 2, 2003 [Page 13] Internet-Draft SSH Authentication Protocol September 2002 Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Darren J. Moffat (editor) Sun Microsystems, Inc 17 Network Circle Menlo Park 95025 USA EMail: Darren.Moffat@Sun.COM Ylonen & Moffat Expires March 2, 2003 [Page 14] Internet-Draft SSH Authentication Protocol September 2002 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Ylonen & Moffat Expires March 2, 2003 [Page 15] Internet-Draft SSH Authentication Protocol September 2002 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen & Moffat Expires March 2, 2003 [Page 16] -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 26 21:50:52 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09184 for ; Sun, 26 Oct 2003 21:50:51 -0500 (EST) Received: (qmail 3481 invoked by uid 605); 27 Oct 2003 02:50:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3393 invoked from network); 27 Oct 2003 02:50:34 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 27 Oct 2003 02:50:34 -0000 Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9R2o3xA022005; Sun, 26 Oct 2003 18:50:03 -0800 (PST) Received: from [192.168.1.100] (vpn-129-150-17-151.SFBay.Sun.COM [129.150.17.151]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9R2nwGs514066; Sun, 26 Oct 2003 18:49:58 -0800 (PST) Date: Sun, 26 Oct 2003 18:50:56 -0800 (PST) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-transport-17.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Network Working Group T. Ylonen Internet-Draft SSH Communications Security Corp Expires: March 31, 2004 D. Moffat, Editor, Ed. Sun Microsystems, Inc Oct 2003 SSH Transport Layer Protocol draft-ietf-secsh-transport-17.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are Ylonen & Moffat, Editor Expires March 31, 2004 [Page 1] Internet-Draft SSH Transport Layer Protocol Oct 2003 all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. Table of Contents 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . 3 4. Connection Setup . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . 4 4.3 Compatibility With Old SSH Versions . . . . . . . . . . . . 4 4.3.1 Old Client, New Server . . . . . . . . . . . . . . . . . . . 5 4.3.2 New Client, Old Server . . . . . . . . . . . . . . . . . . . 5 5. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . 5 5.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . 6 5.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 9 5.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 10 5.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . 11 6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . 13 6.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . 16 6.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 17 7. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . 18 7.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 19 8. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . 20 9. Service Request . . . . . . . . . . . . . . . . . . . . . . 21 10. Additional Messages . . . . . . . . . . . . . . . . . . . . 21 10.1 Disconnection Message . . . . . . . . . . . . . . . . . . . 22 10.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . 22 10.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . 23 10.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . 23 11. Summary of Message Numbers . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 13. Security Considerations . . . . . . . . . . . . . . . . . . 24 14. Intellectual Property . . . . . . . . . . . . . . . . . . . 24 15. Additional Information . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 25 Informative . . . . . . . . . . . . . . . . . . . . . . . . 25 A. Contibutors . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 28 Ylonen & Moffat, Editor Expires March 31, 2004 [Page 2] Internet-Draft SSH Transport Layer Protocol Oct 2003 1. Contributors The major original contributors of this document were: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla) The document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html 2. Introduction The SSH transport layer is a secure low level transport protocol. It provides strong encryption, cryptographic host authentication, and integrity protection. Authentication in this protocol level is host-based; this protocol does not perform user authentication. A higher level protocol for user authentication can be designed on top of this protocol. The protocol has been designed to be simple, flexible, to allow parameter negotiation, and to minimize the number of round-trips. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. It is expected that in most environments, only 2 round-trips will be needed for full key exchange, server authentication, service request, and acceptance notification of service request. The worst case is 3 round-trips. 3. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. The used data types and terminology are specified in the architecture document [SSH-ARCH]. The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. 4. Connection Setup SSH works over any 8-bit clean, binary-transparent transport. The underlying transport SHOULD protect against transmission errors as such errors cause the SSH connection to terminate. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 3] Internet-Draft SSH Transport Layer Protocol Oct 2003 The client initiates the connection. 4.1 Use over TCP/IP When used over TCP/IP, the server normally listens for connections on port 22. This port number has been registered with the IANA, and has been officially assigned for SSH. 4.2 Protocol Version Exchange When the connection has been established, both sides MUST send an identification string of the form "SSH-protoversion-softwareversion comments", followed by carriage return and newline characters (ASCII 13 and 10, respectively). Both sides MUST be able to process identification strings without carriage return character. No null character is sent. The maximum length of the string is 255 characters, including the carriage return and newline. The part of the identification string preceding carriage return and newline is used in the Diffie-Hellman key exchange (see Section Section 7). The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; if they are displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting. Version strings MUST consist of printable US-ASCII characters, not including whitespaces or a minus sign (-). The version string is primarily used to trigger compatibility extensions and to indicate the capabilities of an implementation. The comment string should contain additional information that might be useful in solving user problems. The protocol version described in this document is 2.0. Key exchange will begin immediately after sending this identifier. All packets following the identification string SHALL use the binary packet protocol, to be described below. 4.3 Compatibility With Old SSH Versions During the transition period, it is important to be able to work in a Ylonen & Moffat, Editor Expires March 31, 2004 [Page 4] Internet-Draft SSH Transport Layer Protocol Oct 2003 way that is compatible with the installed SSH clients and servers that use an older version of the protocol. Information in this section is only relevant for implementations supporting compatibility with SSH versions 1.x. There is no standards track or informational draft available that defines the SSH 1.x protocol. The only known documentation of the 1.x protocol is contained in README files that are shipped along with the source code. 4.3.1 Old Client, New Server Server implementations MAY support a configurable "compatibility" flag that enables compatibility with old versions. When this flag is on, the server SHOULD identify its protocol version as "1.99". Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode the server SHOULD NOT send the carriage return character (ASCII 13) after the version identification string. In the compatibility mode the server SHOULD NOT send any further data after its initialization string until it has received an identification string from the client. The server can then determine whether the client is using an old protocol, and can revert to the old protocol if required. In the compatibility mode, the server MUST NOT send additional data before the version string. When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string. 4.3.2 New Client, Old Server Since the new client MAY immediately send additional data after its identification string (before receiving server's identification), the old protocol may already have been corrupted when the client learns that the server is old. When this happens, the client SHOULD close the connection to the server, and reconnect using the old protocol. 5. Binary Packet Protocol Each packet is in the following format: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length packet_length Ylonen & Moffat, Editor Expires March 31, 2004 [Page 5] Internet-Draft SSH Transport Layer Protocol Oct 2003 The length of the packet (bytes), not including MAC or the packet_length field itself. padding_length Length of padding (bytes). payload The useful contents of the packet. If compression has been negotiated, this field is compressed. Initially, compression MUST be "none". random padding Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes. mac Message authentication code. If message authentication has been negotiated, this field contains the MAC bytes. Initially, the MAC algorithm MUST be "none". Note that length of the concatenation of packet length, padding length, payload, and padding MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced even when using stream ciphers. Note that the packet length field is also encrypted, and processing it requires special care when sending or receiving packets. The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus MAC); implementations SHOULD decrypt the length after receiving the first 8 (or cipher block size, whichever is larger) bytes of a packet. 5.1 Maximum Packet Length All implementations MUST be able to process packets with uncompressed payload length of 32768 bytes or less and total packet size of 35000 bytes or less (including length, padding length, payload, padding, and MAC.). The maximum of 35000 bytes is an arbitrary chosen value larger than uncompressed size. Implementations SHOULD support longer packets, where they might be needed, e.g. if an implementation wants to send a very large number of certificates. Such packets MAY be sent if the version string indicates that the other party is able to process them. However, implementations SHOULD check that the packet Ylonen & Moffat, Editor Expires March 31, 2004 [Page 6] Internet-Draft SSH Transport Layer Protocol Oct 2003 length is reasonable for the implementation to avoid denial-of-service and/or buffer overflow attacks. 5.2 Compression If compression has been negotiated, the payload field (and only it) will be compressed using the negotiated algorithm. The length field and MAC will be computed from the compressed payload. Encryption will be done after compression. Compression MAY be stateful, depending on the method. Compression MUST be independent for each direction, and implementations MUST allow independently choosing the algorithm for each direction. The following compression methods are currently defined: none REQUIRED no compression zlib OPTIONAL ZLIB (LZ77) compression The "zlib" compression is described in [RFC1950] and in [RFC1951]. The compression context is initialized after each key exchange, and is passed from one packet to the next with only a partial flush being performed at the end of each packet. A partial flush means that the current compressed block is ended and all data will be output. If the current block is not a stored block, one or more empty blocks are added after the current block to ensure that there are at least 8 bits counting from the start of the end-of-block code of the current block to the end of the packet payload. Additional methods may be defined as specified in [SSH-ARCH]. 5.3 Encryption An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding length, payload and padding fields of each packet MUST be encrypted with the given algorithm. The encrypted data in all packets sent in one direction SHOULD be considered a single data stream. For example, initialization vectors SHOULD be passed from the end of one packet to the beginning of the next packet. All ciphers SHOULD use keys with an effective key length of 128 bits or more. The ciphers in each direction MUST run independently of each other, and implementations MUST allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy). Ylonen & Moffat, Editor Expires March 31, 2004 [Page 7] Internet-Draft SSH Transport Layer Protocol Oct 2003 The following ciphers are currently defined: 3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc OPTIONALi Blowfish in CBC mode twofish256-cbc OPTIONAL Twofish in CBC mode, with 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons) twofish192-cbc OPTIONAL Twofish with 192-bit key twofish128-cbc OPTIONAL Twofish with 128-bit key aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, with 256-bit key aes192-cbc OPTIONAL AES with 192-bit key aes128-cbc RECOMMENDED AES with 128-bit key serpent256-cbc OPTIONAL Serpent in CBC mode, with 256-bit key serpent192-cbc OPTIONAL Serpent with 192-bit key serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode cast128-cbc OPTIONAL CAST-128 in CBC mode none OPTIONAL no encryption; NOT RECOMMENDED The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [FIPS-46-3] The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys [SCHNEIER]. This is a block cipher with 8 byte blocks. The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, with 256 bit keys as described [TWOFISH]. This is a block cipher with 16 byte blocks. The "twofish192-cbc" cipher. Same as above but with 192-bit key. The "twofish128-cbc" cipher. Same as above but with 128-bit key. The "aes256-cbc" cipher is AES (Advanced Encryption Standard) [FIPS-197], formerly Rijndael, in CBC mode. This version uses 256-bit key. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 8] Internet-Draft SSH Transport Layer Protocol Oct 2003 The "aes192-cbc" cipher. Same as above but with 192-bit key. The "aes128-cbc" cipher. Same as above but with 128-bit key. The "serpent256-cbc" cipher in CBC mode, with 256-bit key as described in the Serpent AES submission. The "serpent192-cbc" cipher. Same as above but with 192-bit key. The "serpent128-cbc" cipher. Same as above but with 128-bit key. The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. Arcfour (and RC4) has problems with weak keys, and should be used with caution. The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC2144]. The "none" algorithm specifies that no encryption is to be done. Note that this method provides no confidentiality protection, and it is not recommended. Some functionality (e.g. password authentication) may be disabled for security reasons if this cipher is chosen. Additional methods may be defined as specified in [SSH-ARCH]. 5.4 Data Integrity Data integrity is protected by including with each packet a message authentication code (MAC) that is computed from a shared secret, packet sequence number, and the contents of the packet. The message authentication algorithm and key are negotiated during key exchange. Initially, no MAC will be in effect, and its length MUST be zero. After key exchange, the selected MAC will be computed before encryption from the concatenation of packet data: mac = MAC(key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length fields, payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The sequence number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It Ylonen & Moffat, Editor Expires March 31, 2004 [Page 9] Internet-Draft SSH Transport Layer Protocol Oct 2003 is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet sequence number itself is not included in the packet sent over the wire. The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for both directions. The MAC bytes resulting from the MAC algorithm MUST be transmitted without encryption as the last part of the packet. The number of MAC bytes depends on the algorithm chosen. The following MAC algorithms are currently defined: hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key length = 20) hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest length = 12, key length = 20) hmac-md5 OPTIONAL HMAC-MD5 (digest length = key length = 16) hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest length = 12, key length = 16) none OPTIONAL no MAC; NOT RECOMMENDED Figure 1 The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use only the first n bits of the resulting value. The hash algorithms are described in [SCHNEIER]. Additional methods may be defined as specified in [SSH-ARCH]. 5.5 Key Exchange Methods The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. Only one REQUIRED key exchange method has been defined: diffie-hellman-group1-sha1 REQUIRED This method is described later in this document. Additional methods may be defined as specified in [SSH-ARCH]. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 10] Internet-Draft SSH Transport Layer Protocol Oct 2003 5.6 Public Key Algorithms This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption). There are several aspects that define a public key type: o Key format: how is the key encoded and how are certificates represented. The key blobs in this protocol MAY contain certificates in addition to keys. o Signature and/or encryption algorithms. Some key types may not support both signing and encryption. Key usage may also be restricted by policy statements in e.g. certificates. In this case, different key types SHOULD be defined for the different policy alternatives. o Encoding of signatures and/or encrypted data. This includes but is not limited to padding, byte order, and data formats. The following public key and/or certificate formats are currently defined: ssh-dss REQUIRED sign Raw DSS Key ssh-rsa RECOMMENDED sign Raw RSA Key x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) Additional key types may be defined as specified in [SSH-ARCH]. The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data The certificate part may have be a zero length string, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. Public key / certifcate formats that do not explicitly specify a signature format identifier MUST use the public key / certificate format identifier as the signature identifier. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 11] Internet-Draft SSH Transport Layer Protocol Oct 2003 Signatures are encoded as follows: string signature format identifier (as specified by the public key / cert format) byte[n] signature blob in format specific encoding. The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p mpint q mpint g mpint y Here the p, q, g, and y parameters form the signature key blob. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [SCHNEIER]. The resulting signature is encoded as follows: string "ssh-dss" string dss_signature_blob dss_signature_blob is encoded as a string containing r followed by s (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n Here the e and n parameters form the signature key blob. Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). Ylonen & Moffat, Editor Expires March 31, 2004 [Page 12] Internet-Draft SSH Transport Layer Protocol Oct 2003 The "spki-sign-rsa" method indicates that the certificate blob contains a sequence of SPKI certificates. The format of SPKI certificates is described in [RFC2693]. This method indicates that the key (or one of the keys in the certificate) is an RSA-key. The "spki-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. The "pgp-sign-rsa" method indicates the certificates, the public key, and the signature are in OpenPGP compatible binary format ([RFC2440]). This method indicates that the key is an RSA-key. The "pgp-sign-dss". As above, but indicates that the key is a DSS-key. 6. Key Exchange Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. Guess is considered wrong, if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section Section 6.1). Otherwise, the guess is considered to be right and the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. Server authentication in the key exchange MAY be implicit. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 6.1 Algorithm Negotiation Key exchange begins by each side sending the following packet: Ylonen & Moffat, Editor Expires March 31, 2004 [Page 13] Internet-Draft SSH Transport Layer Protocol Oct 2003 byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension) Each of the algorithm strings MUST be a comma-separated list of algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each supported (allowed) algorithm MUST be listed in order of preference. The first algorithm in each list MUST be the preferred (guessed) algorithm. Each string MUST contain at least one algorithm name. cookie The cookie MUST be a random value generated by the sender. Its purpose is to make it impossible for either side to fully determine the keys and the session identifier. kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST be used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 14] Internet-Draft SSH Transport Layer Protocol Oct 2003 server_host_key_algorithms List of the algorithms supported for the server host key. The server lists the algorithms for which it has host keys; the client lists the algorithms that it is willing to accept. (There MAY be multiple host keys for a host, possibly with different algorithms.) Some host keys may not support both signatures and encryption (this can be determined from the algorithm), and thus not all host keys are valid for all key exchange methods. Algorithm selection depends on whether the chosen key exchange algorithm requires a signature or encryption capable host key. It MUST be possible to determine this from the public key algorithm name. The first algorithm on the client's list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. encryption_algorithms Lists the acceptable symmetric encryption algorithms in order of preference. The chosen encryption algorithm to each direction MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The defined algorithm names are listed in Section Section 5.3. mac_algorithms Lists the acceptable MAC algorithms in order of preference. The chosen MAC algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The MAC algorithm names are listed in Section Figure 1. compression_algorithms Lists the acceptable compression algorithms in order of preference. The chosen compression algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 15] Internet-Draft SSH Transport Layer Protocol Oct 2003 Note that "none" must be explicitly listed if it is to be acceptable. The compression algorithm names are listed in Section Section 5.2. languages This is a comma-separated list of language tags in order of preference [RFC3066]. Both parties MAY ignore this list. If there are no language preferences, this list SHOULD be empty. Language tags SHOULD NOT be present unless they are known to be needed by the sending party. first_kex_packet_follows Indicates whether a guessed key exchange packet follows. If a guessed packet will be sent, this MUST be TRUE. If no guessed packet will be sent, this MUST be FALSE. After receiving the SSH_MSG_KEXINIT packet from the other side, each party will know whether their guess was right. If the other party's guess was wrong, and this field was TRUE, the next packet MUST be silently ignored, and both sides MUST then act as determined by the negotiated key exchange method. If the guess was right, key exchange MUST continue using the guessed packet. After the KEXINIT packet exchange, the key exchange algorithm is run. It may involve several packet exchanges, as specified by the key exchange method. 6.2 Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we'll call it HASH. Encryption keys MUST be computed as HASH of a known value and K as follows: Ylonen & Moffat, Editor Expires March 31, 2004 [Page 16] Internet-Draft SSH Transport Layer Protocol Oct 2003 o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data."A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. 128 bits (16 bytes) MUST be used for algorithms with variable-length keys. The only variable key length algorithm defined in this document is arcfour). For other algorithms, as many bytes as are needed are taken from the beginning of the hash value. If the key length needed is longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g. "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH. 6.3 Taking Keys Into Use Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. When this message is received, the new keys and algorithms MUST be taken into use for receiving. This message is the only valid message after key exchange, in addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. The purpose of this message is to ensure that a party is able to respond with a disconnect message that the other party can understand if something goes wrong with the key exchange. Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 17] Internet-Draft SSH Transport Layer Protocol Oct 2003 byte SSH_MSG_NEWKEYS 7. Diffie-Hellman Key Exchange The Diffie-Hellman key exchange provides a shared secret that can not be determined by either party alone. The key exchange is combined with a signature with the host key to provide host authentication. In the following description (C is the client, S is the server; p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup; V_S is S's version string; V_C is C's version string; K_S is S's public host key; I_C is C's KEXINIT message and I_S S's KEXINIT message which have been exchanged before this part begins): 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends "e" to S. 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g. using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The public key algorithm for signing is negotiated with the KEXINIT messages. First, the client sends the following: Ylonen & Moffat, Editor Expires March 31, 2004 [Page 18] Internet-Draft SSH Transport Layer Protocol Oct 2003 byte SSH_MSG_KEXDH_INIT mpint e The server responds with the following: byte SSH_MSG_KEXDH_REPLY string server public host key and certificates (K_S) mpint f string signature of H The hash H is computed as the HASH hash of the concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret. The signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding. For example, "ssh-dss" specifies SHA-1 hashing; in that case, the data is first hashed with HASH to compute H, and H is then hashed with SHA-1 as part of the signing operation. 7.1 diffie-hellman-group1-sha1 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit MODP Group). It is included below in hexadecimal and decimal. The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + 129093 ). Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 Ylonen & Moffat, Editor Expires March 31, 2004 [Page 19] Internet-Draft SSH Transport Layer Protocol Oct 2003 FFFFFFFF FFFFFFFF. In decimal, this value is: 179769313486231590770839156793787453197860296048756011706444 423684197180216158519368947833795864925541502180565485980503 646440548199239100050792877003355816639229553136239076508735 759914822574862575007425302077447712589550957937778424442426 617334727629299387668709205606050270810842907692932019128194 467627007. The generator used with this prime is g = 2. The group order q is (p - 1) / 2. 8. Key Re-Exchange Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when not already doing a key exchange (as described in Section Section 6.1). When this message is received, a party MUST respond with its own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT already was a reply. Either party MAY initiate the re-exchange, but roles MUST NOT be changed (i.e., the server remains the server, and the client remains the client). Key re-exchange is performed using whatever encryption was in effect when the exchange was started. Encryption, compression, and MAC methods are not changed before a new SSH_MSG_NEWKEYS is sent after the key exchange (as in the initial key exchange). Re-exchange is processed identically to the initial key exchange, except for the session identifier that will remain unchanged. It is permissible to change some or all of the algorithms during the re-exchange. Host keys can also change. All keys and initialization vectors are recomputed after the exchange. Compression and encryption contexts are reset. It is recommended that the keys are changed after each gigabyte of transmitted data or after each hour of connection time, whichever comes sooner. However, since the re-exchange is a public key operation, it requires a fair amount of processing power and should not be performed too often. More application data may be sent after the SSH_MSG_NEWKEYS packet has been sent; key exchange does not affect the protocols that lie above the SSH transport layer. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 20] Internet-Draft SSH Transport Layer Protocol Oct 2003 9. Service Request After the key exchange, the client requests a service. The service is identified by a name. The format of names and procedures for defining new names are defined in [SSH-ARCH]. Currently, the following names have been reserved: ssh-userauth ssh-connection Similar local naming policy is applied to the service names, as is applied to the algorithm names; a local service should use the "servicename@domain" syntax. byte SSH_MSG_SERVICE_REQUEST string service name If the server rejects the service request, it SHOULD send an appropriate SSH_MSG_DISCONNECT message and MUST disconnect. When the service starts, it may have access to the session identifier generated during the key exchange. If the server supports the service (and permits the client to use it), it MUST respond with the following: byte SSH_MSG_SERVICE_ACCEPT string service name Message numbers used by services should be in the area reserved for them (see Section 6 in [SSH-ARCH]). The transport level will continue to process its own messages. Note that after a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 10. Additional Messages Either party may send any of the following messages at any time. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 21] Internet-Draft SSH Transport Layer Protocol Oct 2003 10.1 Disconnection Message byte SSH_MSG_DISCONNECT uint32 reason code string description [RFC2279] string language tag [RFC3066] This message causes immediate termination of the connection. All implementations MUST be able to process this message; they SHOULD be able to send this message. The sender MUST NOT send or receive any data after this message, and the recipient MUST NOT accept any data after receiving this message. The description field gives a more specific explanation in a human-readable form. The error code gives the reason in a more machine-readable format (suitable for localization), and can have the following values: #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 #define SSH_DISCONNECT_RESERVED 4 #define SSH_DISCONNECT_MAC_ERROR 5 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 #define SSH_DISCONNECT_CONNECTION_LOST 10 #define SSH_DISCONNECT_BY_APPLICATION 11 #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 If the description string is displayed, control character filtering discussed in [SSH-ARCH] should be used to avoid attacks by sending terminal control characters. 10.2 Ignored Data Message byte SSH_MSG_IGNORE string data All implementations MUST understand (and ignore) this message at any time (after receiving the protocol version). No implementation is required to send them. This message can be used as an additional protection measure against advanced traffic analysis techniques. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 22] Internet-Draft SSH Transport Layer Protocol Oct 2003 10.3 Debug Message byte SSH_MSG_DEBUG boolean always_display string message [RFC2279] string language tag [RFC3066] All implementations MUST understand this message, but they are allowed to ignore it. This message is used to pass the other side information that may help debugging. If always_display is TRUE, the message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless debugging information has been explicitly requested by the user. The message doesn't need to contain a newline. It is, however, allowed to consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. If the message string is displayed, terminal control character filtering discussed in [SSH-ARCH] should be used to avoid attacks by sending terminal control characters. 10.4 Reserved Messages An implementation MUST respond to all unrecognized messages with an SSH_MSG_UNIMPLEMENTED message in the order in which the messages were received. Such messages MUST be otherwise ignored. Later protocol versions may define other meanings for these message types. byte SSH_MSG_UNIMPLEMENTED uint32 packet sequence number of rejected message 11. Summary of Message Numbers The following message numbers have been defined in this protocol: #define SSH_MSG_DISCONNECT 1 #define SSH_MSG_IGNORE 2 #define SSH_MSG_UNIMPLEMENTED 3 #define SSH_MSG_DEBUG 4 #define SSH_MSG_SERVICE_REQUEST 5 #define SSH_MSG_SERVICE_ACCEPT 6 #define SSH_MSG_KEXINIT 20 #define SSH_MSG_NEWKEYS 21 Ylonen & Moffat, Editor Expires March 31, 2004 [Page 23] Internet-Draft SSH Transport Layer Protocol Oct 2003 /* Numbers 30-49 used for kex packets. Different kex methods may reuse message numbers in this range. */ #define SSH_MSG_KEXDH_INIT 30 #define SSH_MSG_KEXDH_REPLY 31 12. IANA Considerations This document is part of a set, the IANA considerations for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT] are detailed in [SSH-NUMBERS]. 13. Security Considerations This protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. Full security considerations for this protocol are provided in Section 8 of [SSH-ARCH] 14. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 15. Additional Information The current document editor is: Darren.Moffat@Sun.COM. Comments on Ylonen & Moffat, Editor Expires March 31, 2004 [Page 24] Internet-Draft SSH Transport Layer Protocol Oct 2003 this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html Normative [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf-architecture-15.txt, Oct 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-17.txt, Oct 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-18.txt, Oct 2003. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-ietf-connect-18.txt, Oct 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative [FIPS-186] Federal Information Processing Standards Publication, "FIPS PUB 186, Digital Signature Standard", May 1994. [FIPS-197] NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)", November 2001. [FIPS-46-3] U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption Standard (DES)", October 1999. [RFC2459] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", Ylonen & Moffat, Editor Expires March 31, 2004 [Page 25] Internet-Draft SSH Transport Layer Protocol Oct 2003 STD 13, RFC 1034, November 1987. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", 1996. [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition", March 1999. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 26] Internet-Draft SSH Transport Layer Protocol Oct 2003 Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Darren J. Moffat (editor) Sun Microsystems, Inc 17 Network Circle Menlo Park 95025 USA EMail: Darren.Moffat@Sun.COM Appendix A. Contibutors Ylonen & Moffat, Editor Expires March 31, 2004 [Page 27] Internet-Draft SSH Transport Layer Protocol Oct 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 28] Internet-Draft SSH Transport Layer Protocol Oct 2003 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen & Moffat, Editor Expires March 31, 2004 [Page 29] -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 27 09:19:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14752 for ; Mon, 27 Oct 2003 09:19:29 -0500 (EST) Received: (qmail 9476 invoked by uid 605); 27 Oct 2003 14:19:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9468 invoked from network); 27 Oct 2003 14:19:26 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Oct 2003 14:19:26 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14675; Mon, 27 Oct 2003 09:19:13 -0500 (EST) Message-Id: <200310271419.JAA14675@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickey-subsystem-00.txt Date: Mon, 27 Oct 2003 09:19:13 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Secure Shell Public-Key Subsystem Author(s) : Filename : draft-ietf-secsh-publickey-subsystem-00.txt Pages : 16 Date : 2003-10-24 SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting aShell or a Command''. The subsystem name used with this protocol is ''publickey''. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickey-subsystem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24171905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24171905.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 27 14:27:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02152 for ; Mon, 27 Oct 2003 14:27:20 -0500 (EST) Received: (qmail 3913 invoked by uid 605); 27 Oct 2003 19:27:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3906 invoked from network); 27 Oct 2003 19:27:24 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 27 Oct 2003 19:27:24 -0000 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RJRNxA022846 for ; Mon, 27 Oct 2003 11:27:23 -0800 (PST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9RJRNGs685837 for ; Mon, 27 Oct 2003 11:27:23 -0800 (PST) Date: Mon, 27 Oct 2003 11:26:44 -0800 (PST) From: Darren J Moffat To: ietf-ssh@NetBSD.org Subject: Recently updated SSH core drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list As you have probably already noticed by now the 5 core SSH protocol drafts have been updated. All of these updates were at the request of IESG. I believe I have not yet completed all of the IESG requested changes so when we will still need yet another issue of some of the docs. I will send out a detailed note later this week explaining what the changes were. In particular I need some help with some of the references (IESG complained that we had references some docs that were becomming or were obsolete). -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 27 15:08:46 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04965 for ; Mon, 27 Oct 2003 15:08:45 -0500 (EST) Received: (qmail 816 invoked by uid 605); 27 Oct 2003 20:08:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 805 invoked from network); 27 Oct 2003 20:08:51 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 27 Oct 2003 20:08:51 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9RK7xxA009860; Mon, 27 Oct 2003 12:07:59 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9RK7v58012282; Mon, 27 Oct 2003 13:07:58 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9RK3qQx003840; Mon, 27 Oct 2003 12:03:52 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9RK3oR7003839; Mon, 27 Oct 2003 12:03:50 -0800 (PST) Date: Mon, 27 Oct 2003 12:03:50 -0800 From: Nicolas Williams To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@NetBSD.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org Cc: nfsv4@ietf.org Subject: [I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt] Message-ID: <20031027200350.GI24528@binky.central.sun.com> Mail-Followup-To: ipsec@lists.tislabs.com, ietf-sasl@imc.org, ipsec-policy@vpnc.org, ietf-krb-wg@anl.gov, ietf-tls@lists.certicom.com, ietf-ssh@netbsd.org, ietf-cat-wg@lists.stanford.edu, ips@ietf.org, nfsv4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Followups-To: nfsv4@ietf.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list [Apologies for the cross-post; followups should NOT be cross-posted this widely. Please Cc ONLY the appropriate WG mailing list(s) on any replies. Since I am not subscribed to all of the relevant WGs' mailing lists, please Cc me in all replies.] The NFSv4 WG I-D on channel bindings needs review from several IETF WGs. This I-D, draft-ietf-nfsv4-channel-bindings-00.txt, goes along with the soon to be published draft-ietf-nfsv4-ccm-03.txt (currently: -02). We would appreciate feedback from the Cc'ed WGs on several areas as requested below. Please cc the appropriate WG lists only in your replies. The I-D announcement is included below, including the I-D Abstract. Thanks, Nico Review requests: - From all the cc'ed WGs, the security community in general and the [concluded] CAT WG mailing list: o Please review the generic definition of "channel bindings" in this I-D and the concept of "channel bindings" in general. (Use the CAT WG list and/or the NFSv4 WG list.) - From the IPSEC WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. o Please review the IPsec channel bindings construction. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPSP WG: o Please review the IPsec channel construction in this I-D and the relevant interface requirements. (Use the IPSEC WG and/or the IPSP WG lists.) - From the IPS WG: o Please consider the channel bindings concept as a general solution to the problems with the iSCSI approach to security ("authenticate at iSCSI layer with x, y or z authentication technology, but delegate session integrity/confidentiality protection to IPsec"). See the introduction (section 1) of this I-D for a description of the problem with the iSCSI approach to security. (I realize that I'm late to the iSCSI party - my goal is not to affect the progression of the iSCSI I-Ds to Proposed Standard and publication as RFCs, far from it.) (Use the IPS WG list.) - From the TLS WG: o Please review the construction of channel bindings to TLS channels given in this I-D. (Use the TLS WG list.) - From the SECSH WG: o Please review the construction of channel bindings to SSHv2 channels given in this I-D. (Use the SECSH WG list.) - From the KRB WG: o Please review sections 3.3 and 4.5 of this I-D. (Use the KRB WG list.) - From the SASL WG: o Please review section 3.2 of this I-D. (Use the SASL WG list.) ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Fri, 24 Oct 2003 10:50:50 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-nfsv4-channel-bindings-00.txt To: IETF-Announce: ; Cc: nfsv4@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : On the Use of Channel Bindings to Secure Channels Author(s) : N. Williams Filename : draft-ietf-nfsv4-channel-bindings-00.txt Pages : 14 Date : 2003-10-23 This document defines and formalizes the concept of channel bindings to secure layers and defines the actual contents of channel bindings for several secure channels. The concept of channel bindings allows applications to prove that the end-points of two secure channels are the same by binding authentication at one network layer to the session protection negotiation at a lower network layer. The use of channel bindings allows applications to delegate session protection to lower layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-channel-bindings-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-channel-bindings-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 27 17:11:45 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19712 for ; Mon, 27 Oct 2003 17:11:44 -0500 (EST) Received: (qmail 18976 invoked by uid 605); 27 Oct 2003 22:11:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18623 invoked from network); 27 Oct 2003 22:11:27 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Oct 2003 22:11:27 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19566; Mon, 27 Oct 2003 17:11:07 -0500 (EST) Message-Id: <200310272211.RAA19566@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickey-subsystem-00.txt Date: Mon, 27 Oct 2003 17:11:07 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Secure Shell Public-Key Subsystem Author(s) : Filename : draft-ietf-secsh-publickey-subsystem-00.txt Pages : 16 Date : 2003-10-24 SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting aShell or a Command''. The subsystem name used with this protocol is ''publickey''. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickey-subsystem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27171530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171530.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 28 09:38:27 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24635 for ; Tue, 28 Oct 2003 09:38:26 -0500 (EST) Received: (qmail 13265 invoked by uid 605); 28 Oct 2003 14:38:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13256 invoked from network); 28 Oct 2003 14:38:32 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2003 14:38:32 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24614; Tue, 28 Oct 2003 09:38:19 -0500 (EST) Message-Id: <200310281438.JAA24614@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-18.txt Date: Tue, 28 Oct 2003 09:38:18 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-18.txt Pages : 16 Date : 2003-10-27 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095603.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 28 09:38:44 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24679 for ; Tue, 28 Oct 2003 09:38:43 -0500 (EST) Received: (qmail 13478 invoked by uid 605); 28 Oct 2003 14:38:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13450 invoked from network); 28 Oct 2003 14:38:38 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2003 14:38:38 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24636; Tue, 28 Oct 2003 09:38:26 -0500 (EST) Message-Id: <200310281438.JAA24636@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-18.txt Date: Tue, 28 Oct 2003 09:38:26 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-18.txt Pages : 22 Date : 2003-10-27 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095625.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 28 09:38:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24704 for ; Tue, 28 Oct 2003 09:38:54 -0500 (EST) Received: (qmail 13613 invoked by uid 605); 28 Oct 2003 14:38:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13589 invoked from network); 28 Oct 2003 14:38:46 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2003 14:38:46 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24667; Tue, 28 Oct 2003 09:38:34 -0500 (EST) Message-Id: <200310281438.JAA24667@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-15.txt Date: Tue, 28 Oct 2003 09:38:34 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-architecture-15.txt Pages : 29 Date : 2003-10-27 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-15.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095638.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 28 09:39:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24748 for ; Tue, 28 Oct 2003 09:39:18 -0500 (EST) Received: (qmail 14619 invoked by uid 605); 28 Oct 2003 14:39:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14612 invoked from network); 28 Oct 2003 14:39:24 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2003 14:39:24 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24736; Tue, 28 Oct 2003 09:39:12 -0500 (EST) Message-Id: <200310281439.JAA24736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-05.txt Date: Tue, 28 Oct 2003 09:39:12 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : S. Lehtinen, D. Moffat Filename : draft-ietf-secsh-assignednumbers-05.txt Pages : 12 Date : 2003-10-27 This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH- CONNECT], [SSH-USERAUTH]. Except for one HISTORIC algorithm generally regarded as obsolete, this document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095651.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 28 09:39:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24809 for ; Tue, 28 Oct 2003 09:39:31 -0500 (EST) Received: (qmail 14945 invoked by uid 605); 28 Oct 2003 14:39:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14938 invoked from network); 28 Oct 2003 14:39:36 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Oct 2003 14:39:36 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24797; Tue, 28 Oct 2003 09:39:25 -0500 (EST) Message-Id: <200310281439.JAA24797@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-17.txt Date: Tue, 28 Oct 2003 09:39:25 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-17.txt Pages : 29 Date : 2003-10-27 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095704.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095704.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 28 12:40:42 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11430 for ; Tue, 28 Oct 2003 12:40:41 -0500 (EST) Received: (qmail 7969 invoked by uid 605); 28 Oct 2003 17:40:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7961 invoked from network); 28 Oct 2003 17:40:41 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 28 Oct 2003 17:40:41 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1AEXpg-0003Du-00; Tue, 28 Oct 2003 17:40:40 +0000 Date: Tue, 28 Oct 2003 17:40:40 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Some questions about "SSH Transport Layer Encryption Modes" Message-ID: <20031028174040.GC3680@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310192351.h9JNpxAx004282@thunk.east.sun.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: > So, it looks like the proper repair here is to clearly document what's > actually implemented and deployed -- implementations must suspend > transport of user data while rekey negotiation is in progress. There doesn't appear to be anything new for this in draft-ietf-secsh-transport-17. Should a ticket be raised on rt.psg.com so it's not lost again? (Tangent: it seems unfortunate that this site requires installation of a root CA certificate in a browser, and even after that still fails to verify, at least in IE6.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 31 19:15:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26296 for ; Fri, 31 Oct 2003 19:15:17 -0500 (EST) Received: (qmail 19512 invoked by uid 605); 1 Nov 2003 00:15:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19425 invoked from network); 1 Nov 2003 00:15:19 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 1 Nov 2003 00:15:19 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hA10FGUP006065 for ; Fri, 31 Oct 2003 16:15:16 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA10FFbx005537 for ; Fri, 31 Oct 2003 19:15:15 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hA10FFS4021836 for ; Fri, 31 Oct 2003 19:15:15 -0500 (EST) Message-Id: <200311010015.hA10FFS4021836@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: secsh WG meeting at IETF58 in Minneapolis: November 11, 2003 Reply-to: sommerfeld@east.sun.com Date: Fri, 31 Oct 2003 19:15:15 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list We're currently scheduled for Tuesday afternoon. Please send proposed agenda items to me. - Bill DRAFT Agenda of the 58th IETF Meeting November 9-14, 2003 (As of October 31, 2003) .... TUESDAY, November 11, 2003 ... 1415-1515 Afternoon Sessions II APP ldup LDAP Duplication/Replication/Update Protocols WG INT eap Extensible Authentication Protocol WG INT magma Multicast & Anycast Group Membership WG IRTF gsec Group Security Research Group SEC secsh Secure Shell WG TSV alias Access Link Intermediaries Assisting Services BOF TSV nsis Next Steps in Signaling WG