From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 1 12:40: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 MAA29342 for ; Fri, 1 Aug 2003 12:40:23 -0400 (EDT) Received: (qmail 24378 invoked by uid 605); 1 Aug 2003 16:40:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24371 invoked from network); 1 Aug 2003 16:40:20 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 1 Aug 2003 16:40:20 -0000 Received: from [127.0.0.1] (HELO TREX) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1767798 for ietf-ssh@netbsd.org; Fri, 01 Aug 2003 10:40:18 -0600 Message-ID: <000901c3584b$972a5030$4c00a8c0@TREX> From: "Jeff P. Van Dyke" To: Subject: Re: I-D ACTION:draft-ietf-secsh-gsskeyex-06.txt Date: Fri, 1 Aug 2003 10:40:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >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 : GSSAPI Authentication and Key Exchange for the Secure > Shell Protocol > Author(s) : J. Hutzelman, J. Salowey, J. Galbraith, V. Welch > Filename : draft-ietf-secsh-gsskeyex-06.txt > Pages : 27 > Date : 2003-3-6 > As of this week, we now have client and server implementations for Windows and several flavors of UNIX. We would be interested in working with others on doing some interoperability testing. If you are interested, please drop me a note. A few details... We've implemented both the user and host authentication. We have held off on implementing the secure transmission of the host key for now. If there is another implementation that has implemented this last feature, we'd be very interested in completing this work and doing some additional testing between different implementations. Thank you. Jeff P. Van Dyke jpv@vandyke.com www.vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 1 12:47: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 MAA29682 for ; Fri, 1 Aug 2003 12:47:54 -0400 (EDT) Received: (qmail 28250 invoked by uid 605); 1 Aug 2003 16:47:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28243 invoked from network); 1 Aug 2003 16:47:54 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 1 Aug 2003 16:47:54 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h71Glp3t087678 for ; Fri, 1 Aug 2003 10:47:52 -0600 (MDT) Message-ID: <001901c3584c$62fbbe10$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: References: Subject: Re: draft-ietf-secsh-publickeyfile-04.txt Date: Fri, 1 Aug 2003 10:45:59 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C3581A.181C2EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-0.5 required=10.0 tests=REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C3581A.181C2EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here's a revision of the publickey file format draft with the following changes: 1. bumped the expiration date and changed version to 04. 2. Change one typo in Section 3: "Key File Format" ...must share public key files between the client and the server in order interoperate. ^^^ (I added "to"). 3. Changed references to "Normative References" 4. Added Security Considerations as discussed. thanks, Brent ------=_NextPart_000_0016_01C3581A.181C2EC0 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-04.txt" Content-Disposition: attachment; filename="draft-ietf-secsh-publickeyfile-04.txt" Content-Transfer-Encoding: quoted-printable Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: January 30, 2004 R. Thayer The Tillerman Group August 1, 2003 SSH Public Key File Format draft-ietf-secsh-publickeyfile-04.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 January 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document formally documents the existing public key file format in use for exchanging public keys between different SSH implementations. Galbraith & Thayer Expires January 30, 2004 [Page 1] =0C Internet-Draft SSH Public Key File Format August 2003 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Line termination Characters . . . . . . . . . . . . . . . . 5 3.2 Begin and end markers . . . . . . . . . . . . . . . . . . . 5 3.3 Key File Header . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1 Subject Header . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.2 Comment Header . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Public Key File Body . . . . . . . . . . . . . . . . . . . . 6 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . 8 Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Galbraith & Thayer Expires January 30, 2004 [Page 2] =0C Internet-Draft SSH Public Key File Format August 2003 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [4]. Galbraith & Thayer Expires January 30, 2004 [Page 3] =0C Internet-Draft SSH Public Key File Format August 2003 2. Introduction In order to use public key authentication, public keys must be exchanged between client and server. This document formally describes the existing public key file format, with few exceptions. Where this document departs from current practice, it also suggests a mechanism for backwards compatibility. Galbraith & Thayer Expires January 30, 2004 [Page 4] =0C Internet-Draft SSH Public Key File Format August 2003 3. Key File Format SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 bytes. 3.1 Line termination Characters In order to achieve the goal of being able to exchange public key files between servers, implementations are REQUIRED to read files using any of the common line termination sequence, , or . Implementations may generate files using which ever line termination convention is most convenient 3.2 Begin and end markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be a end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3 Key File Header The key file header section consists of multiple RFC822 - style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 bytes. The Header-value MUST NOT be more than 1024 bytes. Each line in the header MUST NOT be more than 72 bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and appending the contents of the next line. The Header-tag MUST be US-ASCII. The Header-value MUST be encoded in UTF-8. [2] Galbraith & Thayer Expires January 30, 2004 [Page 5] =0C Internet-Draft SSH Public Key File Format August 2003 A line that is not a continuation line that has no ':' in it is assumed to be the first line of the base 64 encoded body (Section 8) Compliant implementations MUST ignore unrecognized header fields. Implementations SHOULD preserve unrecognized header fields when manipulating the key file. Existing implementations may not correctly handle unrecognized fields. During a transition period, implementations SHOULD generate key file headers that contain only a Subject field followed by a Comment field. 3.3.1 Subject Header This field currently is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2 Comment Header Contain a user specified comment which will be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@mycompany.com Currently, common practice is to quote the Header-value of the Comment, and some existing implementations fail if these quotes are omitted. Compliant implementations MUST function correctly if the quotes are omitted. During an interim period implementations MAY include the quotes. If the first and last characters of the Header-value are matching quotes, implementations SHOULD remove them before using the value. 3.4 Public Key File Body The body of a public key file consists of the public key blob as described in the SSH transport draft [1], section 4.6, "Public Key Algorithms", encoded in base 64 as specified in RFC-2045, section 6.8, "Base64 Content-Transfer-Encoding". [5] As with all other lines, each line in the body MUST NOT be longer Galbraith & Thayer Expires January 30, 2004 [Page 6] =0C Internet-Draft SSH Public Key File Format August 2003 than 72 characters. 3.5 Examples The following are some example public key files that are compliant: ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by galb@test1" = AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRbYY = Fw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ5TT4 SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE=3D ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp = AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbETW6 = ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdHYI14 = Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5cvwHWTZ = DPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGfJ0/RHd+N = jB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAAvioUPkmdMc = 0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACBAN7CY+KKv1gH = pRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HSn24VYtYtsMu74q = XviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5sY29ouezv4Xz2PuM ch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 = 2001 = AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459 = 6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6 NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0=3D ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires January 30, 2004 [Page 7] =0C Internet-Draft SSH Public Key File Format August 2003 4. Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. Galbraith & Thayer Expires January 30, 2004 [Page 8] =0C Internet-Draft SSH Public Key File Format August 2003 Normative References [1] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Protocol Transport Protocol", September 2002. [2] Yergeau, F., "UTF-8, a Transformation Format of Unicode and ISO 10646", October 1996. [3] Bradner, S., "The Internet Standards Process -- Revision 3", October 1996. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [5] Freed and Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", November 1996. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 EMail: rodney@tillerman.to Galbraith & Thayer Expires January 30, 2004 [Page 9] =0C Internet-Draft SSH Public Key File Format August 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. 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. 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 Galbraith & Thayer Expires January 30, 2004 [Page 10] =0C Internet-Draft SSH Public Key File Format August 2003 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. Galbraith & Thayer Expires January 30, 2004 [Page 11] =0C ------=_NextPart_000_0016_01C3581A.181C2EC0-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 4 19:27:10 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 TAA15483 for ; Mon, 4 Aug 2003 19:27:10 -0400 (EDT) Received: (qmail 8294 invoked by uid 605); 4 Aug 2003 23:27:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8287 invoked from network); 4 Aug 2003 23:27:09 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 4 Aug 2003 23:27:09 -0000 Received: from heliopolis.eng.sun.com ([152.70.8.30]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h74NR9qY021420 for ; Mon, 4 Aug 2003 16:27:09 -0700 (PDT) Received: from srmtv29c (srmtv29c [152.70.10.43]) by heliopolis.eng.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.1p1) with ESMTP id h74NR6P02353 for ; Mon, 4 Aug 2003 16:27:06 -0700 (PDT) Date: Mon, 4 Aug 2003 16:27:08 -0700 (PDT) From: Douglas Stebila X-X-Sender: ds133359@srmtv29c To: ietf-ssh@NetBSD.org Subject: Elliptic Curve Cryptography in SSH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is anyone looking at the use of elliptic curve cryptography in the SSH protocol? Specifically at either ECDH for key exchange or ECDSA for signatures? -- Douglas Stebila Email: douglas.stebila@sun.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 5 03:55:11 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 DAA04546 for ; Tue, 5 Aug 2003 03:55:10 -0400 (EDT) Received: (qmail 4586 invoked by uid 605); 5 Aug 2003 07:55:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4576 invoked from network); 5 Aug 2003 07:55:10 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 5 Aug 2003 07:55:10 -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 h757pNOc002037; Tue, 5 Aug 2003 09:51:24 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 708A52D004; Tue, 5 Aug 2003 09:51:08 +0200 (CEST) Date: Tue, 5 Aug 2003 09:51:08 +0200 From: Markus Friedl To: Douglas Stebila Cc: ietf-ssh@NetBSD.org Subject: Re: Elliptic Curve Cryptography in SSH Message-ID: <20030805075108.GB22785@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Aug 04, 2003 at 04:27:08PM -0700, Douglas Stebila wrote: > Is anyone looking at the use of elliptic curve cryptography in the SSH > protocol? Specifically at either ECDH for key exchange or ECDSA for > signatures? not for openssh, since it opens another can of stupid patent problems. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 5 06:19: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 GAA06561 for ; Tue, 5 Aug 2003 06:19:19 -0400 (EDT) Received: (qmail 17127 invoked by uid 605); 5 Aug 2003 10:19:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17120 invoked from network); 5 Aug 2003 10:19:19 -0000 Received: from mystic1.trustcenter.de (193.194.157.34) by mail.netbsd.org with SMTP; 5 Aug 2003 10:19:19 -0000 Received: (from root@localhost) by mystic1.trustcenter.de (8.11.6+Sun/8.11.6) id h75ACot14589; Tue, 5 Aug 2003 12:12:50 +0200 (MEST) Received: from venus.trustcenter.de(192.168.202.4) by mystic1.trustcenter.de via csmap (V6.0) id srcAAAFUaGFC; Tue, 5 Aug 03 12:12:49 +0200 Received: from trustcenter.de (ew-nla.trustcenter.de [192.168.200.46]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h75AJ4a28331; Tue, 5 Aug 2003 12:19:04 +0200 (MET DST) Message-ID: <3F2F8491.3060704@trustcenter.de> Date: Tue, 05 Aug 2003 12:18:57 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Friedl CC: Douglas Stebila , ietf-ssh@NetBSD.org Subject: Re: Elliptic Curve Cryptography in SSH References: <20030805075108.GB22785@folly> In-Reply-To: <20030805075108.GB22785@folly> 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 Markus Friedl wrote: > On Mon, Aug 04, 2003 at 04:27:08PM -0700, Douglas Stebila wrote: > >>Is anyone looking at the use of elliptic curve cryptography in the SSH >>protocol? Specifically at either ECDH for key exchange or ECDSA for >>signatures? > > > not for openssh, since it opens another can of stupid patent problems. I don't think that patents are a problem (for ECDSA and ECDH) if only curves over GF(p), p prime, are used (see for example: http://grouper.ieee.org/groups/1363/P1363/patents.html). Using curves over GF(2**m) without some features (point compression, onb basis etc.) should be possible as well. Note: Implementing ECDSA and ECDH in OpenSSH shouldn't very difficult as soon as OpenSSL 0.9.8 is released as OpenSSL 0.9.8 will support ecdsa and ecdh. Nils From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 6 00:41:21 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 AAA08808 for ; Wed, 6 Aug 2003 00:41:20 -0400 (EDT) Received: (qmail 11194 invoked by uid 605); 6 Aug 2003 04:41:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11187 invoked from network); 6 Aug 2003 04:41:19 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 6 Aug 2003 04:41:19 -0000 Received: from mindrot.org (116.195.20.10.dhcp.netstarnetworks.com [10.20.195.116] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h764hoQ21392; Wed, 6 Aug 2003 14:43:53 +1000 Message-ID: <3F308693.1030007@mindrot.org> Date: Wed, 06 Aug 2003 14:39:47 +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: Nils Larsch CC: Markus Friedl , Douglas Stebila , ietf-ssh@NetBSD.org Subject: Re: Elliptic Curve Cryptography in SSH References: <20030805075108.GB22785@folly> <3F2F8491.3060704@trustcenter.de> In-Reply-To: <3F2F8491.3060704@trustcenter.de> 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 Nils Larsch wrote: > Markus Friedl wrote: > >> On Mon, Aug 04, 2003 at 04:27:08PM -0700, Douglas Stebila wrote: >> >>> Is anyone looking at the use of elliptic curve cryptography in the SSH >>> protocol? Specifically at either ECDH for key exchange or ECDSA for >>> signatures? >> >> not for openssh, since it opens another can of stupid patent problems. > > I don't think that patents are a problem (for ECDSA and ECDH) if only > curves over GF(p), p prime, are used (see for example: > http://grouper.ieee.org/groups/1363/P1363/patents.html). Using > curves over GF(2**m) without some features (point compression, > onb basis etc.) should be possible as well. I was under the (possibly mistaken) impression that avoiding these patents eliminated many of the benefits of EC. (Not to mention that avoiding patents is a difficult and potentially expensive game.) > Note: Implementing ECDSA and ECDH in OpenSSH shouldn't very difficult > as soon as OpenSSL 0.9.8 is released as OpenSSL 0.9.8 will support > ecdsa and ecdh. The license that the EC stuff in OpenSSL is released under contains some terms that we won't accept. In particular, the patent license: http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html So, like RSA and SRP, another interesting crypto technology is killed for ~20 years. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 6 01:40:00 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 BAA09653 for ; Wed, 6 Aug 2003 01:39:59 -0400 (EDT) Received: (qmail 9298 invoked by uid 605); 6 Aug 2003 05:39:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9291 invoked from network); 6 Aug 2003 05:39:58 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 6 Aug 2003 05:39:58 -0000 Received: from vger.corp.google.com (vger.corp.google.com [10.32.60.132]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h765dvHa007221; Tue, 5 Aug 2003 22:39:57 -0700 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id h765dvs19878; Tue, 5 Aug 2003 22:39:57 -0700 Date: Tue, 5 Aug 2003 22:39:57 -0700 From: Frank Cusack To: Bill Sommerfeld Cc: Russ Housley , ietf-ssh@NetBSD.org Subject: Re: Please advance draft-ietf-secsh-auth-kbdinteract-05.txt Message-ID: <20030805223957.A19859@google.com> References: <200307292025.h6TKPB8Q026343@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307292025.h6TKPB8Q026343@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Jul 29, 2003 at 04:25:11PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 29, 2003 at 04:25:11PM -0400, Bill Sommerfeld wrote: > Please start the ball rolling on: > > Generic Message Exchange Authentication For SSH > > > .. for publication as a Proposed Standard. Here are a few typo fixes (ie, nothing substantive, but still worth fixing before publication) I meant to get in earlier. The diff here is against my nroff source. Should I submit a -06 draft? --- pwplus.n 2003/04/29 06:03:05 1.5 +++ pwplus.n 2003/07/31 05:31:23 1.6 @@ -83,7 +83,7 @@ 1. Introduction The SSH authentication protocol \%[SSH-USERAUTH] is a general-purpose user -authentication protocol. It is intended to be run over the SSH transport +authentication protocol. It is intended to be run over the SSH transport layer protocol \%[SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection. @@ -178,7 +178,7 @@ does not support the requested language is implementation-dependent. The submethods field is included so the user can give a hint of which -actual methods he wants to use. It is a a comma-separated list of +actual methods he wants to use. It is a comma-separated list of authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods @@ -186,7 +186,7 @@ the empty string. The actual names of the submethods is something which the user and the -server needs to agree upon. +server need to agree upon. Server interpretation of the submethods field is implementation-dependent. @@ -221,7 +221,7 @@ The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST -message outstanding. That is, it may not send another request before +message outstanding. That is, it may not send another request before the client has answered. .KS @@ -293,7 +293,7 @@ the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be -an obvious indication that such truncation has occured. The instruction +an obvious indication that such truncation has occurred. The instruction field SHOULD NOT be truncated. Clients SHOULD use control character filtering as discussed in \%[SSH-ARCH] @@ -363,7 +363,7 @@ If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending to the client. It is suspected that implementations are likely to make the time delay -a configurable, a suggested default is 2 seconds. +a configurable; a suggested default is 2 seconds. .ti 0 4. Authentication Examples @@ -485,7 +485,7 @@ .ti 0 6. Security Considerations -The authentication protocol, and this authentication method, depends +The authentication protocol, and this authentication method, depend on the security of the underlying SSH transport layer. Without the confidentiality provided therein, any authentication data passed with this method is subject to interception. @@ -494,8 +494,8 @@ authentication using this method may be variable. It is possible that an observer may gain valuable information simply by counting that number. For example, an observer may guess that a user's password has expired, -and with further observation may be able to determine the frequency of -a site's password expiration policy. +and with further observation may be able to determine the password lifetime +imposed by a site's password expiration policy. .KS .ti 0 @@ -561,7 +561,7 @@ .in 3 .KS .ti 0 -8. Author's Addresses +8. Authors' Addresses .nf .ne 5 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 6 02:18:24 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 CAA24775 for ; Wed, 6 Aug 2003 02:18:23 -0400 (EDT) Received: (qmail 25905 invoked by uid 605); 6 Aug 2003 06:18:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25894 invoked from network); 6 Aug 2003 06:18:19 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 6 Aug 2003 06:18:19 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id EFCEC567D; Wed, 6 Aug 2003 08:18:06 +0200 (CEST) Message-ID: <3F309DB5.40703@siliconcircus.com> Date: Wed, 06 Aug 2003 08:18:29 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Cusack Cc: Bill Sommerfeld , Russ Housley , ietf-ssh@NetBSD.org Subject: Re: Please advance draft-ietf-secsh-auth-kbdinteract-05.txt References: <200307292025.h6TKPB8Q026343@thunk.east.sun.com> <20030805223957.A19859@google.com> In-Reply-To: <20030805223957.A19859@google.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, Frank Cusack wrote: > Here are a few typo fixes (ie, nothing substantive, but still worth fixing Here's one more :-) > @@ -363,7 +363,7 @@ > If the server intends to respond with a failure message, it MAY delay > for an implementation-dependent time before sending to the client. > It is suspected that implementations are likely to make the time delay > -a configurable, a suggested default is 2 seconds. > +a configurable; a suggested default is 2 seconds. +configurable; a suggested default is 2 seconds. ...or... +a configurable item; a suggested default is 2 seconds. Or s/item/parameter/, either way, configurable is not a noun... -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 6 04:44: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 EAA09561 for ; Wed, 6 Aug 2003 04:44:01 -0400 (EDT) Received: (qmail 842 invoked by uid 605); 6 Aug 2003 08:43:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 834 invoked from network); 6 Aug 2003 08:43:56 -0000 Received: from mystic1.trustcenter.de (193.194.157.34) by mail.netbsd.org with SMTP; 6 Aug 2003 08:43:56 -0000 Received: (from root@localhost) by mystic1.trustcenter.de (8.11.6+Sun/8.11.6) id h768bVA02627; Wed, 6 Aug 2003 10:37:31 +0200 (MEST) Received: from venus.trustcenter.de(192.168.202.4) by mystic1.trustcenter.de via csmap (V6.0) id srcAAAP_aqif; Wed, 6 Aug 03 10:37:29 +0200 Received: from trustcenter.de (ew-nla.trustcenter.de [192.168.200.46]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h768hja05211; Wed, 6 Aug 2003 10:43:45 +0200 (MET DST) Message-ID: <3F30BFF2.3090002@trustcenter.de> Date: Wed, 06 Aug 2003 10:44:34 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damien Miller CC: ietf-ssh@NetBSD.org Subject: Re: Elliptic Curve Cryptography in SSH References: <20030805075108.GB22785@folly> <3F2F8491.3060704@trustcenter.de> <3F308693.1030007@mindrot.org> In-Reply-To: <3F308693.1030007@mindrot.org> 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 Damien Miller wrote: .... >> I don't think that patents are a problem (for ECDSA and ECDH) if only >> curves over GF(p), p prime, are used (see for example: >> http://grouper.ieee.org/groups/1363/P1363/patents.html). Using >> curves over GF(2**m) without some features (point compression, >> onb basis etc.) should be possible as well. > > > I was under the (possibly mistaken) impression that avoiding these > patents eliminated many of the benefits of EC. (Not to mention that > avoiding patents is a difficult and potentially expensive game.) As far as I know is this not true if only curve ober GF(p), p prime, are used. Curves over GF(2^m) are another story as for example the point compression as defined in X9.62 is afaik patented (or the use normal bases). >> Note: Implementing ECDSA and ECDH in OpenSSH shouldn't very difficult >> as soon as OpenSSL 0.9.8 is released as OpenSSL 0.9.8 will support >> ecdsa and ecdh. > > > The license that the EC stuff in OpenSSL is released under contains some > terms that we won't accept. In particular, the patent license: Well, the basic GF(p) ec stuff and the ecdsa code were mostly written by Bodo Moeller and me and are therefore under the standard OpenSSL license. Sun wrote the ECDH code, but put it under the standard OpenSSL license. > > http://research.sun.com/projects/crypto/FrequenlyAskedQuestions.html Greping trough the OpenSSL source code I could only find one file with the "covenant" license and that's crypto/bn/bn_gf2m.c => not using GF(2^m) should avoid this license. Nils From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 6 13:31: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 NAA25805 for ; Wed, 6 Aug 2003 13:31:35 -0400 (EDT) Received: (qmail 22560 invoked by uid 605); 6 Aug 2003 17:31:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22552 invoked from network); 6 Aug 2003 17:31:30 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 6 Aug 2003 17:31:30 -0000 Received: from heliopolis.eng.sun.com ([152.70.24.37]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h76HVPL0029299; Wed, 6 Aug 2003 11:31:25 -0600 (MDT) Received: from srmtv29c (srmtv29c [152.70.10.43]) by heliopolis.eng.sun.com (8.11.6+Sun/8.11.6/ENSMAIL,v2.1p1) with ESMTP id h76HVOP18138; Wed, 6 Aug 2003 10:31:24 -0700 (PDT) Date: Wed, 6 Aug 2003 10:31:24 -0700 (PDT) From: Douglas Stebila X-X-Sender: ds133359@srmtv29c To: ietf-ssh@NetBSD.org cc: Damien Miller Subject: Re: Elliptic Curve Cryptography in SSH In-Reply-To: <3F30BFF2.3090002@trustcenter.de> Message-ID: References: <20030805075108.GB22785@folly> <3F2F8491.3060704@trustcenter.de> <3F308693.1030007@mindrot.org> <3F30BFF2.3090002@trustcenter.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 6 Aug 2003, Nils Larsch wrote: > > The license that the EC stuff in OpenSSL is released under contains some > > terms that we won't accept. In particular, the patent license: > > Well, the basic GF(p) ec stuff and the ecdsa code were mostly written > by Bodo Moeller and me and are therefore under the standard OpenSSL > license. Sun wrote the ECDH code, but put it under the standard OpenSSL > license. > > Greping trough the OpenSSL source code I could only find one file > with the "covenant" license and that's crypto/bn/bn_gf2m.c => > not using GF(2^m) should avoid this license. The routines in crypto/bn/bn_gf2m.c contain comments indicating where the algorithm originally came from. (See the file online at http://cvs.openssl.org/getfile?v=1.10&f=openssl/crypto/bn/bn_gf2m.c) The only algorithm referenced to Sun Microsystems is the version of BN_GF2m_mod_div from a paper by Chang-Shantz. Compilation of this version of BN_GF2m_mod_div is controlled by the preprocessor flag OPENSSL_SUN_GF2M_DIV and is as far as I know not compiled in by the default OpenSSL configure script. Douglas From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 9 16:14:20 2003 Received: from mail.netbsd.org ([204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06116 for ; Sat, 9 Aug 2003 16:14:19 -0400 (EDT) Received: (qmail 24045 invoked by uid 605); 9 Aug 2003 20:14:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24038 invoked from network); 9 Aug 2003 20:14:16 -0000 Received: from mail.wv-cis.net (HELO pop.wv-cis.net) (209.197.41.6) by mail.netbsd.org with SMTP; 9 Aug 2003 20:14:16 -0000 Received: by pop.wv-cis.net from localhost (router,slmail V5.1); Sat, 09 Aug 2003 16:26:47 -0400 for Received: from usr142.fbnt.chas.cisinternet.net [209.197.41.87] by pop.wv-cis.net [209.197.41.6] (SLmail 5.1.0.4420) with ESMTP id A13BF24E4C954EA583C734623BA98E4D for ; Sat, 09 Aug 2003 16:26:46 -0400 Subject: I would like to join the openssh mailing list From: "Dan Thompson" To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1060460315.3837.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 09 Aug 2003 16:18:35 -0400 Content-Transfer-Encoding: 7bit X-SLUIDL: 84C3B922-998E4142-AA2C2CCA-F7D6A79F Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit -- Dan Thompson From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 06:49: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 GAA15328 for ; Wed, 13 Aug 2003 06:49:18 -0400 (EDT) Received: (qmail 23879 invoked by uid 605); 13 Aug 2003 10:49:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23872 invoked from network); 13 Aug 2003 10:49:15 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 13 Aug 2003 10:49:15 -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 h7DAjROc026944; Wed, 13 Aug 2003 12:45:28 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 5B8EB2D044; Wed, 13 Aug 2003 12:45:00 +0200 (CEST) Date: Wed, 13 Aug 2003 12:44:59 +0200 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 Message-ID: <20030813104459.GA26607@folly> References: <02fb01c2f613$0220a2e0$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02fb01c2f613$0220a2e0$4d00a8c0@galb.vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Mar 29, 2003 at 09:48:21AM -0700, Joseph Galbraith wrote: > uint32 break-length in milliseconds what's the reason for including this in the protocol? shouldn't the server decide what break-length is reasonable? e.g. depending on what kind of devices is attached? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 10:02:59 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 KAA19615 for ; Wed, 13 Aug 2003 10:02:58 -0400 (EDT) Received: (qmail 4220 invoked by uid 605); 13 Aug 2003 14:02:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4213 invoked from network); 13 Aug 2003 14:02:58 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 13 Aug 2003 14:02:58 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19582; Wed, 13 Aug 2003 10:02:51 -0400 (EDT) Message-Id: <200308131402.KAA19582@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-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 10:02:51 -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 : SCP/SFTP/SSH URI Format Author(s) : S. Suehring, J. Salowey Filename : draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Pages : 7 Date : 2003-8-13 This document describes the Uniform Resource Identifiers used to locate resources for the SCP, SFTP, and SSH protocols. The document describes the generic syntax involved in URI definitions as well as specific definitions for each protocol. These specific definitions may include user credentials such as username and password and also may include other parameters such as fingerprint. In addition, security considerations and examples are also provided within this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-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-scp-sftp-ssh-uri-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-scp-sftp-ssh-uri-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-8-13102135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-scp-sftp-ssh-uri-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-13102135.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 11:25: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 LAA23136 for ; Wed, 13 Aug 2003 11:25:18 -0400 (EDT) Received: (qmail 19857 invoked by uid 605); 13 Aug 2003 15:25:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19850 invoked from network); 13 Aug 2003 15:25:17 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 13 Aug 2003 15:25:17 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19mxUp-0003ey-00; Wed, 13 Aug 2003 16:25:07 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <200308131402.KAA19582@ietf.org> Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-Id: Date: Wed, 13 Aug 2003 16:25:07 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-00.txt The SSH and SFTP schemes look basically sane to me. Some comments on the rest: - SCP is a bit harder, because AIUI there's no requirement for absolute path names on an SCP server to begin with a slash, so the stated syntax is potentially ambiguous. (A Windows SCP server, for example, is at liberty to begin all its absolute path names with "c:\" and "d:\" and so on, I believe.) - In the parameters section, there is repeated text saying `This parameter MUST NOT add a mechanism to a configured list of default configured acceptable encryption types'. I can't immediately parse that. Does that mean that if an SSH client doesn't by default enable (say) "des-cbc", it must not enable it solely on the say-so of the URL? Does it in fact mean that the client should restrict its existing set of ciphers (or whatever) to the intersection of its preconfigured/default set and the set provided in the URL? If not, what does it mean? - I'm particularly concerned about the "fingerprint" parameter. I appreciate that the document already mentions that it makes a difference whether the URL's fingerprint was obtained through a trustworthy mechanism, but it strikes me that this might be fun to implement in the average software setup in which the web browser and the SSH client are separate, because if the client is just handed a URL it won't in general know how it was obtained. Perhaps a solution is for the web browser to allow separate configuration of SSH client commands for securely and insecurely obtained SSH URLs, and then those could be configured to be respectively `putty --trust-fingerprint-parameter ' and just plain `putty '. Less fundamental nits: - There may be more than one cipher/integrity/key-xchg parameter in a given URL, but if there is, what preference order does that imply? Or none? - Come to think of it, why must there not be more than one fingerprint parameter? A host might perfectly well have ssh-dss and ssh-rsa host keys, and want to supply the fingerprints of both because it can't predict which key exchange mechanisms the client supports. - `They fingerprint' -> `The fingerprint'. - Shouldn't there be references describing the protocols specified by the three schemes? (_Is_ there even a document describing SCP?) - Why is `Guidelines for new URL schemes' a normative reference? -- Simon Tatham "Imagine what the world would be like if there were no hypothetical situations..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 11:52:10 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 LAA23974 for ; Wed, 13 Aug 2003 11:52:09 -0400 (EDT) Received: (qmail 7740 invoked by uid 605); 13 Aug 2003 15:52:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7733 invoked from network); 13 Aug 2003 15:52:11 -0000 Received: from dewberry.cc.columbia.edu (128.59.59.68) by mail.netbsd.org with SMTP; 13 Aug 2003 15:52:11 -0000 Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7DFq8M9000628 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Aug 2003 11:52:09 -0400 (EDT) Message-ID: <3F3A5EA2.1070601@columbia.edu> Date: Wed, 13 Aug 2003 11:52:02 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Friedl CC: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: <02fb01c2f613$0220a2e0$4d00a8c0@galb.vandyke.com> <20030813104459.GA26607@folly> In-Reply-To: <20030813104459.GA26607@folly> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020603010802010008000900" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms020603010802010008000900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I would assume in most cases the break-length would be ignored. However, if the device is a serial port the application will need to determine the break length Jeffrey Altman Markus Friedl wrote: > On Sat, Mar 29, 2003 at 09:48:21AM -0700, Joseph Galbraith wrote: > >> uint32 break-length in milliseconds > > > what's the reason for including this in the protocol? > > shouldn't the server decide what break-length is reasonable? e.g. > depending on what kind of devices is attached? --------------ms020603010802010008000900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgxMzE1NTIwMlowIwYJKoZIhvcNAQkEMRYEFMlQ3C//brpS y9ogrucaa6B5/HoAMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAnybhA4vmg4y9XCbLKkOmP0hH2HDk 5YbvoATNAXQvX2GOXMLaofC8NLso/AlkXti5a1DuvN/qGyPWA/BeTAd3nBXkGqJQd4DNyPIT GxpCTKlItGksEvsZY5R6bqFO3tTY9n52kbBijVF52XuaqX5jJelBnNpWp+IXTPwBOb7A1nWy +GPMXfOTiMCUS5ml863U+IfGKEy5ZlcioihMkG8xGxcD44FMpTDf+qkBmtbcL/mDxFLYenS+ pU1D8b+2m9XkfEig6nVwPtwSSrhGIYLnyPBX5sJDhsPY3CPWsPawuQAej4/xoShAp2gsZ+3F uGJm88fnFlsbFfN8EPne5y/JlQAAAAAAAA== --------------ms020603010802010008000900-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 13:34: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 NAA26815 for ; Wed, 13 Aug 2003 13:34:45 -0400 (EDT) Received: (qmail 10947 invoked by uid 605); 13 Aug 2003 17:34:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10940 invoked from network); 13 Aug 2003 17:34:42 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 13 Aug 2003 17:34:42 -0000 Received: by xanthine.gratuitous.org with local; Wed, 13 Aug 2003 13:34:40 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org In-reply-to: <200308131402.KAA19582@ietf.org> (Internet-Drafts@ietf.org) Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt References: <200308131402.KAA19582@ietf.org> Message-Id: Date: Wed, 13 Aug 2003 13:34:40 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is there a good reason to define scp URLs in addition to sftp URLs? I don't think explicitly specifying port 22 in all cases where the URL doesn't specify a port number is correct; what about SRV DNS records? What is the rationale for allowing the URL to specify information about ciphers, integrity protection, etc? It seems allowing this to be specified might allow an attacker providing a URL to perform a downgrade attack, which at the very least should be mentioned in the security considerations section. There doesn't seem to be anything prohibiting an attacker from specifying ``none'', either. It looks to me like there is no mechanism for specifying the public key host key algorithm to be used, nor does the fingerprint contain that information. Combined with only allowing one fingerprint, that has the potential to cause interoperability problems: if I have a server with one ssh-rsa key, and one ssh-dss key, and some clients happen to prefer ssh-rsa over ssh-dss and others are the other way around, how do I provide a URL with a fingerprint that will work with both types of clients? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 13:44: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 NAA27440 for ; Wed, 13 Aug 2003 13:44:56 -0400 (EDT) Received: (qmail 16601 invoked by uid 605); 13 Aug 2003 17:44:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16589 invoked from network); 13 Aug 2003 17:44:57 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 13 Aug 2003 17:44:57 -0000 Received: by xanthine.gratuitous.org with local; Wed, 13 Aug 2003 13:44:56 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-fingerprint-01.txt Message-Id: Date: Wed, 13 Aug 2003 13:44:56 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list draft-ietf-secsh-fingerprint-01.txt seems to suggest that it applies not only to ssh-rsa and ssh-dss, but also to types such as pgp-sign-rsa and pgp-sign-dss. I think it might be better if that particular format does not apply to pgp-sign-rsa and pgp-sign-dss, because calculating the hash of the key blob will give different results depending on what certificates and subkeys are present, and there is already an existing fingerprint format for such keys which does not depend on anything other than the primary key. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 14:08: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 OAA28345 for ; Wed, 13 Aug 2003 14:08:06 -0400 (EDT) Received: (qmail 27250 invoked by uid 605); 13 Aug 2003 18:08:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27243 invoked from network); 13 Aug 2003 18:08:05 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 13 Aug 2003 18:08:05 -0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2003 11:14:32 -0700 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7DI837F019952; Wed, 13 Aug 2003 11:08:03 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA13988; Wed, 13 Aug 2003 11:08:02 -0700 (PDT) Date: Wed, 13 Aug 2003 11:08:02 -0700 (PDT) From: Chris Lonvick To: Jeffrey Altman cc: Markus Friedl , Joseph Galbraith , Subject: Re: Please publish attached draft-ietf-secsh-break-01 In-Reply-To: <3F3A5EA2.1070601@columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I've been told that some chipsets may be assigned a timelength for sending a BREAK. And, as the draft says, if they are not assigned a value then they use their default value. Over the years, that value has moved around with a low end of 100ms and a high end of 1 second. Pairing up a server that sends a 100ms BREAK to a console (or whatever) that expects a break to last 1000ms will probably not achieve the expectations. Setting a default to 500ms at least gives everyone a point to shoot at. Allowing the value to be sent in the protocol gives SSH terminal server manufacturors a chance to meet the requirements of their customers with specific needs. {Speaking for myself and not my company. ..as in; I don't even _know_ the people in my company who do serial port chips or programming of them but I think it's a good feature to have. :-} Thanks, Chris On Wed, 13 Aug 2003, Jeffrey Altman wrote: > I would assume in most cases the break-length would be ignored. > However, if the device is a serial port the application will need to > determine the break length > > Jeffrey Altman > > > Markus Friedl wrote: > > > On Sat, Mar 29, 2003 at 09:48:21AM -0700, Joseph Galbraith wrote: > > > >> uint32 break-length in milliseconds > > > > > > what's the reason for including this in the protocol? > > > > shouldn't the server decide what break-length is reasonable? e.g. > > depending on what kind of devices is attached? > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 14:09:29 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 OAA28381 for ; Wed, 13 Aug 2003 14:09:28 -0400 (EDT) Received: (qmail 28044 invoked by uid 605); 13 Aug 2003 18:09:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28037 invoked from network); 13 Aug 2003 18:09:28 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 13 Aug 2003 18:09:28 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Aug 2003 11:09:30 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7DI9Mtp000192; Wed, 13 Aug 2003 11:09:23 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 11:10:44 -0700 From: "Joseph Salowey" To: "'Simon Tatham'" , Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 11:06:38 -0700 Message-ID: <015501c361c5$a469baf0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Aug 2003 18:10:44.0632 (UTC) FILETIME=[36BD9980:01C361C6] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Simon Tatham > Sent: Wednesday, August 13, 2003 8:25 AM > To: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > wrote: > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri- > > 00.txt > > The SSH and SFTP schemes look basically sane to me. Some > comments on the rest: > > - SCP is a bit harder, because AIUI there's no requirement for > absolute path names on an SCP server to begin with a slash, so > the stated syntax is potentially ambiguous. (A Windows SCP > server, for example, is at liberty to begin all its absolute path > names with "c:\" and "d:\" and so on, I believe.) > I'm not sure, but I believe it is acceptable for the absolute path section to contain C: or d:. Scp://c:/file.txt Do you see an issue with this? > - In the parameters section, there is repeated text saying `This > parameter MUST NOT add a mechanism to a configured list of > default configured acceptable encryption types'. I can't > immediately parse that. Does that mean that if an SSH client > doesn't by default enable (say) "des-cbc", it must not enable it > solely on the say-so of the URL? [Joe] Yes > Does it in fact mean that the > client should restrict its existing set of ciphers (or whatever) > to the intersection of its preconfigured/default set and the set > provided in the URL? If not, what does it mean? > [Joe] Yes > - I'm particularly concerned about the "fingerprint" parameter. I > appreciate that the document already mentions that it makes a > difference whether the URL's fingerprint was obtained through a > trustworthy mechanism, but it strikes me that this might be fun > to implement in the average software setup in which the web > browser and the SSH client are separate, because if the client is > just handed a URL it won't in general know how it was obtained. > > Perhaps a solution is for the web browser to allow separate > configuration of SSH client commands for securely and insecurely > obtained SSH URLs, and then those could be configured to be > respectively `putty --trust-fingerprint-parameter ' and just > plain `putty '. > [Joe] This would be good, although I'm not sure you could achieve this configuration in current web browsers and mail clients. I was thinkin that this could also involve user participation in the verification as well. Perhaps a prompt indicating "the host key from the server matches (or does not match) the fingerprint in the URL; do you want to proceed?" > Less fundamental nits: > > - There may be more than one cipher/integrity/key-xchg parameter in > a given URL, but if there is, what preference order does that > imply? Or none? > [Joe] they should be listed in order of preference. > - Come to think of it, why must there not be more than one > fingerprint parameter? A host might perfectly well have ssh-dss > and ssh-rsa host keys, and want to supply the fingerprints of > both because it can't predict which key exchange mechanisms the > client supports. > [Joe] Good point. > - `They fingerprint' -> `The fingerprint'. > > - Shouldn't there be references describing the protocols specified > by the three schemes? (_Is_ there even a document describing SCP?) > > - Why is `Guidelines for new URL schemes' a normative reference? > > -- > Simon Tatham "Imagine what the world would be like if > there were no hypothetical situations..." > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 14:17: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 OAA28634 for ; Wed, 13 Aug 2003 14:17:54 -0400 (EDT) Received: (qmail 2899 invoked by uid 605); 13 Aug 2003 18:17:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2892 invoked from network); 13 Aug 2003 18:17:55 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 13 Aug 2003 18:17:55 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19n0By-0002gF-00; Wed, 13 Aug 2003 19:17:50 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <015501c361c5$a469baf0$0300000a@amer.cisco.com> To: "Joseph Salowey" Cc: Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-Id: Date: Wed, 13 Aug 2003 19:17:50 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I wrote: >> - SCP is a bit harder, because AIUI there's no requirement for >> absolute path names on an SCP server to begin with a slash, so >> the stated syntax is potentially ambiguous. (A Windows SCP >> server, for example, is at liberty to begin all its absolute path >> names with "c:\" and "d:\" and so on, I believe.) "Joseph Salowey" wrote: > I'm not sure, but I believe it is acceptable for the absolute path > section to contain C: or d:. > > Scp://c:/file.txt > > Do you see an issue with this? Well, the URI definition said scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] [ ; parameter = value ] [ abs_path ] So the `abs_path' section starts immediately after the host name, and hence it is expected to begin with a slash: scp://hostname/usr/bin/thingy ^^^^^^^^^^^^^^^ If the abs_path doesn't begin with a slash, you get scp://hostnamec:\bin\thingy which is clearly useless (and that's without even going into the backslash issue). -- Simon Tatham "_shin_, n. An ingenious device for finding tables and chairs in the dark." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 14:21: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 OAA28695 for ; Wed, 13 Aug 2003 14:21:00 -0400 (EDT) Received: (qmail 5010 invoked by uid 605); 13 Aug 2003 18:21:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4999 invoked from network); 13 Aug 2003 18:21:01 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by mail.netbsd.org with SMTP; 13 Aug 2003 18:21:01 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7DIKupp012899; Wed, 13 Aug 2003 11:20:56 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 11:25:01 -0700 From: "Joseph Salowey" To: "'Joel N. Weber II'" , Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 11:20:55 -0700 Message-ID: <015801c361c7$a3058520$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Aug 2003 18:25:01.0294 (UTC) FILETIME=[3559D8E0:01C361C8] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joel N. Weber II > Sent: Wednesday, August 13, 2003 10:35 AM > To: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > Is there a good reason to define scp URLs in addition to sftp URLs? > [Joe] SCP is is use today, we thought it would be useful. > I don't think explicitly specifying port 22 in all cases > where the URL doesn't specify a port number is correct; what > about SRV DNS records? [Joe] So the suggestion would be something like: If the URL doesn't specify a port number the it should check for a SRV DNS record if it is available, if it is not then it should use port 22. > > What is the rationale for allowing the URL to specify > information about ciphers, integrity protection, etc? It > seems allowing this to be specified might allow an attacker > providing a URL to perform a downgrade attack, which at the > very least should be mentioned in the security considerations > section. There doesn't seem to be anything prohibiting an > attacker from specifying ``none'', either. [Joe] This was added as an afterthought to the fingerprint parameter. The thought was that the this would allow the URL to specify what parameters should be used. However for parameters that are negotiated such as cipher, integrity, etc. It's not clear that they add much value. The list should not add to what is configured as acceptable to the client confiuration. If the client allows none in its default configuration there is a potential problem whether the URL speficies it or not. Perhaps it would be better to let the SSH negotiation take care of this and remove it from the URL. > It looks to me like there is no mechanism for specifying the > public key host key algorithm to be used, nor does the > fingerprint contain that information. Combined with only > allowing one fingerprint, that has the potential to cause > interoperability problems: if I have a server with one > ssh-rsa key, and one ssh-dss key, and some clients happen to > prefer ssh-rsa over ssh-dss and others are the other way > around, how do I provide a URL with a fingerprint that will > work with both types of clients? > [Joe] Yes, I didn't think about this. There should be a way to accomplish this. It seems like we may need to allow for multiple fingerprints and multiple host algortihms. Perhaps the fingerprint parameter should be something like fingerprint=:; > > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 14:36:09 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 OAA29783 for ; Wed, 13 Aug 2003 14:36:08 -0400 (EDT) Received: (qmail 14040 invoked by uid 605); 13 Aug 2003 18:36:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14033 invoked from network); 13 Aug 2003 18:36:07 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 13 Aug 2003 18:36:07 -0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2003 11:42:33 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7DIa1LH019098; Wed, 13 Aug 2003 11:36:01 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 11:40:05 -0700 From: "Joseph Salowey" To: "'Simon Tatham'" Cc: Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 11:35:59 -0700 Message-ID: <015e01c361c9$be5777f0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Aug 2003 18:40:06.0128 (UTC) FILETIME=[50AC8F00:01C361CA] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sorry I goofed up my response So how about scp://hostname/c:/bin/thingy Isn't there current a similar problem with ftp urls? It would seem that in order to form the URL you would have to convert path-separators into / to fit into URL syntax. I think this is what is done with FTP. Currently I don't have access to a windows FTP server to test out this theory. I guess the difference is that in FTP you have an explicit change directory command that you can interpret each path element to be an argumant for. I'm not sure if SCP has this concept. In any case we will have to be a bit more specific about the handling of path elements SCP and probably SFTP as well. Joe > -----Original Message----- > From: Simon Tatham [mailto:simon@ixion.tartarus.org] On > Behalf Of Simon Tatham > Sent: Wednesday, August 13, 2003 11:18 AM > To: Joseph Salowey > Cc: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > > I wrote: > >> - SCP is a bit harder, because AIUI there's no requirement for > >> absolute path names on an SCP server to begin with a slash, so > >> the stated syntax is potentially ambiguous. (A Windows SCP > >> server, for example, is at liberty to begin all its > absolute path > >> names with "c:\" and "d:\" and so on, I believe.) > > "Joseph Salowey" wrote: > > I'm not sure, but I believe it is acceptable for the absolute path > > section to contain C: or d:. > > > > Scp://c:/file.txt > > > > Do you see an issue with this? > > Well, the URI definition said > > scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] > [ ; parameter = value ] [ abs_path ] > > So the `abs_path' section starts immediately after the host > name, and hence it is expected to begin with a slash: > > scp://hostname/usr/bin/thingy > ^^^^^^^^^^^^^^^ > > If the abs_path doesn't begin with a slash, you get > > scp://hostnamec:\bin\thingy > > which is clearly useless (and that's without even going into > the backslash issue) > > -- > Simon Tatham "_shin_, n. An ingenious device for > finding tables and chairs in the dark." > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 16:44:25 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 QAA05255 for ; Wed, 13 Aug 2003 16:44:24 -0400 (EDT) Received: (qmail 25817 invoked by uid 605); 13 Aug 2003 20:44:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25810 invoked from network); 13 Aug 2003 20:44:18 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 13 Aug 2003 20:44:18 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7DKiHFs027500; Wed, 13 Aug 2003 13:44:17 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DKiHtK011039; Wed, 13 Aug 2003 16:44:17 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7DKiG8Q027644; Wed, 13 Aug 2003 16:44:16 -0400 (EDT) Message-Id: <200308132044.h7DKiG8Q027644@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 In-Reply-To: Your message of "Wed, 13 Aug 2003 12:44:59 +0200." <20030813104459.GA26607@folly> Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Aug 2003 16:44:16 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > On Sat, Mar 29, 2003 at 09:48:21AM -0700, Joseph Galbraith wrote: > > uint32 break-length in milliseconds > > what's the reason for including this in the protocol? > > shouldn't the server decide what break-length is reasonable? e.g. > depending on what kind of devices is attached? [wg chair hat off; i also have no no strong opinion on this .. I'm just attempting to inject data into the discussion] Telnet has had BREAK since the dawn of time, and it doesn't have a break-length parameter. I just looked at rfc2217 (telnet COM port control) which has a few more extensive features. I can't seem to find a timed-break feature, but it has a slightly different approach, which is to have separate "assert break"/"release break"; but it seems that using this to get a timed break would be tricky given unpredictable network and server-side crypto latencies.. Oh, and if I remember I'll ask the guy down the hall from me who used to work on terminal servers in a past job for an opinion.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 17:19:53 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 RAA06252 for ; Wed, 13 Aug 2003 17:19:53 -0400 (EDT) Received: (qmail 16363 invoked by uid 605); 13 Aug 2003 21:19:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16356 invoked from network); 13 Aug 2003 21:19:55 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 13 Aug 2003 21:19:55 -0000 Received: by xanthine.gratuitous.org with local; Wed, 13 Aug 2003 17:19:43 -0400 From: "Joel N. Weber II" To: Chris Lonvick CC: Jeffrey Altman , Markus Friedl , Joseph Galbraith , In-reply-to: (message from Chris Lonvick on Wed, 13 Aug 2003 11:08:02 -0700 (PDT)) Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: Message-Id: Date: Wed, 13 Aug 2003 17:19:43 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list It seems like setting the break length in the same place you set the baud rate, number of data and stop bits, parity, etc would probably be appropriate. Is there a draft for setting all these other timing parameters on a serial port in the ssh protocol that I'm not aware of? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 17:39:10 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 RAA07189 for ; Wed, 13 Aug 2003 17:39:09 -0400 (EDT) Received: (qmail 27391 invoked by uid 605); 13 Aug 2003 21:39:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27383 invoked from network); 13 Aug 2003 21:39:11 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 13 Aug 2003 21:39:11 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7DLciFs000317; Wed, 13 Aug 2003 14:38:44 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DLcibO004755; Wed, 13 Aug 2003 15:38:44 -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 h7DLZJQx025737; Wed, 13 Aug 2003 14:35:19 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7DLZIfx025736; Wed, 13 Aug 2003 14:35:18 -0700 (PDT) Date: Wed, 13 Aug 2003 14:35:18 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'Joel N. Weber II'" , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-ID: <20030813213514.GA25731@binky.central.sun.com> References: <015801c361c7$a3058520$0300000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015801c361c7$a3058520$0300000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Aug 13, 2003 at 11:20:55AM -0700, Joseph Salowey wrote: > > I don't think explicitly specifying port 22 in all cases > > where the URL doesn't specify a port number is correct; what > > about SRV DNS records? > [Joe] So the suggestion would be something like: > > If the URL doesn't specify a port number the it should check for a SRV > DNS record if it is available, if it is not then it should use port 22. Then you need to describe this in detail (e.g., SRV RR naming). And the fact that DNS is often deployed in insecure configurations is definitely something to point out in the security considerations section - that is, if the SRV lookup cannot be done securely then 22 should be used, IMO. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 17:55: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 RAA07764 for ; Wed, 13 Aug 2003 17:55:56 -0400 (EDT) Received: (qmail 6077 invoked by uid 605); 13 Aug 2003 21:55:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6070 invoked from network); 13 Aug 2003 21:55:56 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 13 Aug 2003 21:55:56 -0000 Received: by xanthine.gratuitous.org with local; Wed, 13 Aug 2003 17:55:55 -0400 From: "Joel N. Weber II" To: "Joseph Salowey" CC: In-reply-to: <015801c361c7$a3058520$0300000a@amer.cisco.com> (jsalowey@cisco.com) Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt References: <015801c361c7$a3058520$0300000a@amer.cisco.com> Message-Id: Date: Wed, 13 Aug 2003 17:55:55 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > > Is there a good reason to define scp URLs in addition to sftp URLs? > > > [Joe] SCP is is use today, we thought it would be useful. I guess I'm not really clear on what the working group and ssh implementors think should be the future of scp vs sftp. If there is a desire to depreciate scp in favor of sftp, it may be best to not define a URL scheme for scp to encourage the use of sftp. > > I don't think explicitly specifying port 22 in all cases > > where the URL doesn't specify a port number is correct; what > > about SRV DNS records? > [Joe] So the suggestion would be something like: > > If the URL doesn't specify a port number the it should check for a SRV > DNS record if it is available, if it is not then it should use port 22. It might be better to come up with language along the lines that if the port number is specified in the URL, it is used, otherwise the port number to use is determined by what is specified in the other secsh documents. However, it seems like there's a little bit of vagueness there; the transport draft says that ssh normally listens on port 22, and there's no mention of SRV records anywhere in the secsh documents, as far as I can tell. > > What is the rationale for allowing the URL to specify > > information about ciphers, integrity protection, etc? It > > seems allowing this to be specified might allow an attacker > > providing a URL to perform a downgrade attack, which at the > > very least should be mentioned in the security considerations > > section. There doesn't seem to be anything prohibiting an > > attacker from specifying ``none'', either. > > [Joe] This was added as an afterthought to the fingerprint parameter. > The thought was that the this would allow the URL to specify what > parameters should be used. However for parameters that are negotiated > such as cipher, integrity, etc. It's not clear that they add much value. > The list should not add to what is configured as acceptable to the > client confiuration. If the client allows none in its default > configuration there is a potential problem whether the URL speficies it > or not. Perhaps it would be better to let the SSH negotiation take care > of this and remove it from the URL. I can have a client which is set up to accept AES, or if that is not available, single DES, or if that is not available, none. As long as I'm properly verifying the host key, the client allowing that fallback will not reduce security in the cases where the server does support AES, because the signature made with the host key is against a hash that includes all of the cipher algorithms that both sides offered. But I do agree that letting ssh negotiation decide these things makes sense. (The only times I can remember I've overridden a list of algorithms that my ssh client had by default were testing pgp-sign-* support before I'd written the code to add those algorithms to the default proposal list, and overriding the cipher when doing a long file transfer between relatively slow machines over ethernet. And if the latter problem is worth fixing, it should be done with careful consideration of which ciphers are both fast and secure, and putting such a cipher at the begining of the list for all file transfers.) > > It looks to me like there is no mechanism for specifying the > > public key host key algorithm to be used, nor does the > > fingerprint contain that information. Combined with only > > allowing one fingerprint, that has the potential to cause > > interoperability problems: if I have a server with one > > ssh-rsa key, and one ssh-dss key, and some clients happen to > > prefer ssh-rsa over ssh-dss and others are the other way > > around, how do I provide a URL with a fingerprint that will > > work with both types of clients? > > > [Joe] Yes, I didn't think about this. There should be a way to > accomplish this. It seems like we may need to allow for multiple > fingerprints and multiple host algortihms. Perhaps the fingerprint > parameter should be something like > fingerprint=:; I'm not sure that there's necessarily a need to allow for multiple fingerprints. If you are getting an ssh:// url from a trusted source, you could just use an ssh-dss key, and all clients will support that. The set of characters that can theoretically be used in the name of a host key algorithm is probably a superset of what you want to allow in a URL, so there probably needs to be an escaping mechanism, sigh. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 17:57: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 RAA07832 for ; Wed, 13 Aug 2003 17:57:18 -0400 (EDT) Received: (qmail 7232 invoked by uid 605); 13 Aug 2003 21:57:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7225 invoked from network); 13 Aug 2003 21:57:20 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 13 Aug 2003 21:57:20 -0000 Received: by xanthine.gratuitous.org with local; Wed, 13 Aug 2003 17:57:17 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Joseph Salowey , "'Joel N. Weber II'" , ietf-ssh@NetBSD.org In-reply-to: <20030813213514.GA25731@binky.central.sun.com> (message from Nicolas Williams on Wed, 13 Aug 2003 14:35:18 -0700) Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt References: <015801c361c7$a3058520$0300000a@amer.cisco.com> <20030813213514.GA25731@binky.central.sun.com> Message-Id: Date: Wed, 13 Aug 2003 17:57:17 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Then you need to describe this in detail (e.g., SRV RR naming). And the > fact that DNS is often deployed in insecure configurations is definitely > something to point out in the security considerations section - that is, > if the SRV lookup cannot be done securely then 22 should be used, IMO. While we're at it, maybe we should say that if the A lookup can't be done securely, then you have to use 127.0.0.1? :-P From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 18:00:05 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 SAA07953 for ; Wed, 13 Aug 2003 18:00:04 -0400 (EDT) Received: (qmail 9106 invoked by uid 605); 13 Aug 2003 22:00:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8892 invoked from network); 13 Aug 2003 22:00:01 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 13 Aug 2003 22:00:01 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7DLxpFs012922; Wed, 13 Aug 2003 14:59:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DLxpcm008003; Wed, 13 Aug 2003 15:59:51 -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 h7DLuQQx025774; Wed, 13 Aug 2003 14:56:26 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7DLuQec025773; Wed, 13 Aug 2003 14:56:26 -0700 (PDT) Date: Wed, 13 Aug 2003 14:56:26 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Joseph Salowey , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-ID: <20030813215626.GB19288@binky.central.sun.com> References: <015801c361c7$a3058520$0300000a@amer.cisco.com> <20030813213514.GA25731@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Aug 13, 2003 at 05:57:17PM -0400, Joel N. Weber II wrote: > > Then you need to describe this in detail (e.g., SRV RR naming). And the > > fact that DNS is often deployed in insecure configurations is definitely > > something to point out in the security considerations section - that is, > > if the SRV lookup cannot be done securely then 22 should be used, IMO. > > While we're at it, maybe we should say that if the A lookup can't be > done securely, then you have to use 127.0.0.1? :-P Point taken :) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 19:23:17 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 TAA10845 for ; Wed, 13 Aug 2003 19:23:17 -0400 (EDT) Received: (qmail 20984 invoked by uid 605); 13 Aug 2003 23:23:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20977 invoked from network); 13 Aug 2003 23:23:18 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Aug 2003 23:23:18 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7DNNFWb007699; Wed, 13 Aug 2003 17:23:15 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DNNFfM020387; Wed, 13 Aug 2003 19:23:15 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7DNNE8Q028799; Wed, 13 Aug 2003 19:23:14 -0400 (EDT) Message-Id: <200308132323.h7DNNE8Q028799@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Salowey" cc: "'Simon Tatham'" , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt In-Reply-To: Your message of "Wed, 13 Aug 2003 11:35:59 PDT." <015e01c361c9$be5777f0$0300000a@amer.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Aug 2003 19:23:14 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > scp://hostname/c:/bin/thingy > > Isn't there current a similar problem with ftp urls? > > It would seem that in order to form the URL you would have to convert > path-separators into / to fit into URL syntax. I think this is what is > done with FTP. yep, that matches my (possibly lossy) understanding of ftp as well (shortly after NetBSD's ftp client was extended to take url's on the command line, there was a followup code change to do individual cd's for each URL component ..) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 19:25: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 TAA10894 for ; Wed, 13 Aug 2003 19:25:57 -0400 (EDT) Received: (qmail 22109 invoked by uid 605); 13 Aug 2003 23:25:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22102 invoked from network); 13 Aug 2003 23:25:57 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 13 Aug 2003 23:25:57 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19n509-0005Ib-00; Thu, 14 Aug 2003 00:25:57 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <015e01c361c9$be5777f0$0300000a@amer.cisco.com> Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-Id: Date: Thu, 14 Aug 2003 00:25:57 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Salowey wrote: > So how about > scp://hostname/c:/bin/thingy The difficulty with that is that you really want the SCP client to send the pathname 'c:/bin/thingy', without a leading slash. But when you say `scp://hostname/usr/bin/foo', you want the SCP client to send `/usr/bin/foo', _with_ the leading slash. So this design requires the _client_ to do something clever about conditionally stripping the leading slash. Surely? (Unless you're mandating that the _server_ in the 'c:/' case must be capable of throwing away a leading slash? But that seems like a requirement on server behaviour as well as URI format, which is fairly serious remit creep...) -- Simon Tatham "I'm going to pull his head off. Ear by ear." - a games teacher From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 19:37:00 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 TAA11257 for ; Wed, 13 Aug 2003 19:36:59 -0400 (EDT) Received: (qmail 28643 invoked by uid 605); 13 Aug 2003 23:37:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28633 invoked from network); 13 Aug 2003 23:37:00 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 13 Aug 2003 23:37:00 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7DNaxRv011343; Wed, 13 Aug 2003 16:37:00 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7DNaxtK010843; Wed, 13 Aug 2003 19:36:59 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7DNax8Q028896; Wed, 13 Aug 2003 19:36:59 -0400 (EDT) Message-Id: <200308132336.h7DNax8Q028896@thunk.east.sun.com> From: Bill Sommerfeld To: Simon Tatham cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt In-Reply-To: Your message of "Thu, 14 Aug 2003 00:25:57 BST." Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Aug 2003 19:36:58 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list (again, wg chair hat off..) > (Unless you're mandating that the _server_ in the 'c:/' case must be > capable of throwing away a leading slash? But that seems like a > requirement on server behaviour as well as URI format, which is > fairly serious remit creep...) An alternative (which would confuse a different set of people) would be to always eat the / after then hostname-part of the URL, so for unix systems, you'd see URL's like: scp://user@hostname/.login (referring to the .login in your home directory) scp://user@hostname//etc/passwd On the other hand, this would also make scp://user1@hostname/~user2/foo less of a special case. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 20:07: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 UAA12035 for ; Wed, 13 Aug 2003 20:07:19 -0400 (EDT) Received: (qmail 19848 invoked by uid 605); 14 Aug 2003 00:07:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19825 invoked from network); 14 Aug 2003 00:07:19 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 14 Aug 2003 00:07:19 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7E07Jph016566 for ; Wed, 13 Aug 2003 18:07:19 -0600 (MDT) Received: from islay (vpn-129-150-18-231.SFBay.Sun.COM [129.150.18.231]) by jurassic.eng.sun.com (8.12.10.Beta3+Sun/8.12.10.Beta3) with ESMTP id h7E07IF6360507 for ; Wed, 13 Aug 2003 17:07:18 -0700 (PDT) Date: Wed, 13 Aug 2003 17:07:59 -0700 (PDT) From: Darren J Moffat To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 14 Aug 2003, Simon Tatham wrote: > (Unless you're mandating that the _server_ in the 'c:/' case must be > capable of throwing away a leading slash? But that seems like a > requirement on server behaviour as well as URI format, which is > fairly serious remit creep...) Keeping in mind that scp is really just the rcp protocol over the SSH transport. Since rcp is a historically a UNIX protocol it doesn't (at least to me, but probably not to everyone) seem unreasonable that a server providing access via rcp should do the work of mapping UNIX style names to its style. Isn't that the case with '/' vs '\' on Windows anyway ? How would one specify an scp URI that was accessing a resource mounted from a remote Windows filesystem (IIRC double slashes are required). Bill Sommerfeld wrote: > An alternative (which would confuse a different set of people) would > be to always eat the / after then hostname-part of the URL, so for > unix systems, you'd see URL's like: > scp://user@hostname/.login (referring to the .login in your home directory) > scp://user@hostname//etc/passwd Given the user@ part that actually seems reasonable, and it makes it similar to the following cli syntax for scp(1): $ scp user@hostname:.login $ scp user@hostname:/etc/passwd The double // requirement could be confusing in a case where "userinfo@" isn't specified. For example: scp://hostname/etc/passwd or scp://hostname//etc/passwd Based on the behaviour of http I would personally have expected these to be equivalent, however they wouldn't necessarily be. What is the username on the remote host when "userinfo@" isn't specified (which is where the home directory is inferred from). -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 21:56:39 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 VAA14242 for ; Wed, 13 Aug 2003 21:56:38 -0400 (EDT) Received: (qmail 21330 invoked by uid 605); 14 Aug 2003 01:56:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21323 invoked from network); 14 Aug 2003 01:56:37 -0000 Received: from dewberry.cc.columbia.edu (128.59.59.68) by mail.netbsd.org with SMTP; 14 Aug 2003 01:56:37 -0000 Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7E1uRM9019543 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Aug 2003 21:56:28 -0400 (EDT) Message-ID: <3F3AEC49.8030605@columbia.edu> Date: Wed, 13 Aug 2003 21:56:25 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Markus Friedl , Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: <200308132044.h7DKiG8Q027644@thunk.east.sun.com> In-Reply-To: <200308132044.h7DKiG8Q027644@thunk.east.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000805060101060005060100" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms000805060101060005060100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > Telnet has had BREAK since the dawn of time, and it doesn't have a > break-length parameter. Telnet BREAK is not in any way associated with serial port break signals. > I just looked at rfc2217 (telnet COM port control) which has a few > more extensive features. I can't seem to find a timed-break feature, > but it has a slightly different approach, which is to have separate > "assert break"/"release break"; but it seems that using this to get a > timed break would be tricky given unpredictable network and server-side crypto > latencies.. Yes, this is a major flaw in RFC2217. There is no way to get the desired behavior due to the variability of network communications and the inability to force a packet to be sent on the network. > Oh, and if I remember I'll ask the guy down the hall from me who used > to work on terminal servers in a past job for an opinion.. > > - Bill Kermit software has supported since the early 80s both a Short Break and Long Break. A break less than 300ms is short; a break greater than 700ms is long. These due have meanings for some modems and some terminal servers. Jeffrey Altman --------------ms000805060101060005060100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDAxNTYyNVowIwYJKoZIhvcNAQkEMRYEFGZbHN4inVN1 4/42C8kCVTvKHLzIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEADR45ftkLkHsiBeOLsAwmDOgUbo27 q4U35UPQ6OrcU20rL3L3GOzbQUgNMSP2Vr/dwEV6BokVlIblk0EbCnE6mA7ggddM5SYBIXx0 Nwx4W8dIMkunC2EjFNQo8YGfWN6x9gAy2wK+mFwU3+qVysVniJyGfzD5u5ltRZEz0MC0T717 wY3ipmCYpv6+NK1i+cGSgTXhPgYiB6f8E3FHNyrxDB4xUi0ac0eoSppi9rHT8f48bVhdjRRF 06viZAwhZ/fqnmPV/MtgR/o1PDUEPPFrHSxyzf7n8OprxSQthVAy0DfNGa3lEC+eIAnAPUVR uF6gJcQwJFEj0DgyZ4XWtk3YtgAAAAAAAA== --------------ms000805060101060005060100-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 21:58: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 VAA14273 for ; Wed, 13 Aug 2003 21:58:29 -0400 (EDT) Received: (qmail 22428 invoked by uid 605); 14 Aug 2003 01:58:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22278 invoked from network); 14 Aug 2003 01:58:06 -0000 Received: from dewberry.cc.columbia.edu (128.59.59.68) by mail.netbsd.org with SMTP; 14 Aug 2003 01:58:06 -0000 Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7E1vtM9019870 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Aug 2003 21:57:56 -0400 (EDT) Message-ID: <3F3AECA2.5000105@columbia.edu> Date: Wed, 13 Aug 2003 21:57:54 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel N. Weber II" CC: Chris Lonvick , Markus Friedl , Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020900010603040901090601" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms020900010603040901090601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The receiver of the break signal may behavior differently depending on the length of the break. That is the reason for allowing the value to be set. Jeffrey Altman Joel N. Weber II wrote: > It seems like setting the break length in the same place you set the > baud rate, number of data and stop bits, parity, etc would probably be > appropriate. Is there a draft for setting all these other timing > parameters on a serial port in the ssh protocol that I'm not aware of? > --------------ms020900010603040901090601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDAxNTc1NFowIwYJKoZIhvcNAQkEMRYEFE+iqmAbrUxd /EmDB78V9lILQ9UEMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEARTXex57t3YGXJ1pjiy5MWQotQ0os y/K84E0yn77en1N1LFIYzzN0I6hX/Dyun+HnAZ11MqLa7D9gmYnfcOVPhoG4xJ38e1IsXxoA aKOi6FGFe4fwMoCklHZic5fpiCFiGcvo/1r3B53S9Nrp5yg9grk4UMm6lBX27cfE5RF5ddQo t99LKvpxoe7hkx7dgP9LqFJR2Q+Bc8predRlFe8okNO449yIHs5l5CH2RG+VJV6orEVe6yKi CEWo+ik+mqj2JmVF/8k8fG0cI3d3ClHmo662RYctsNutuuOkdrKE5h9DZK/hw/nt8OMkCVoL hRGDJ+eYxrMMFnkWUyw0i26rtwAAAAAAAA== --------------ms020900010603040901090601-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 13 22:04:05 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 WAA14382 for ; Wed, 13 Aug 2003 22:04:05 -0400 (EDT) Received: (qmail 29195 invoked by uid 605); 14 Aug 2003 02:04:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29188 invoked from network); 14 Aug 2003 02:04:06 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 14 Aug 2003 02:04:06 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7E244Rv014897; Wed, 13 Aug 2003 19:04:04 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7E243tK027351; Wed, 13 Aug 2003 22:04:03 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7E2428Q001235; Wed, 13 Aug 2003 22:04:02 -0400 (EDT) Message-Id: <200308140204.h7E2428Q001235@thunk.east.sun.com> From: Bill Sommerfeld To: Jeffrey Altman cc: Markus Friedl , Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 In-Reply-To: Your message of "Wed, 13 Aug 2003 21:56:25 EDT." <3F3AEC49.8030605@columbia.edu> Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Aug 2003 22:04:02 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Telnet BREAK is not in any way associated with serial port break > signals. It is common for terminal servers used for console access to emit a serial BREAK upon receiving a telnet BREAK. It's definitely associated in many implementations. > Kermit software has supported since the early 80s both a Short Break and > Long Break. A break less than 300ms is short; a break greater than > 700ms is long. These due have meanings for some modems and some > terminal servers. I assume there's also a minimal length for "short break". From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 00:59:21 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 AAA17034 for ; Thu, 14 Aug 2003 00:59:21 -0400 (EDT) Received: (qmail 12047 invoked by uid 605); 14 Aug 2003 04:59:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12040 invoked from network); 14 Aug 2003 04:59:22 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 14 Aug 2003 04:59:22 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2003 22:05:54 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7E4xJtp016111; Wed, 13 Aug 2003 21:59:20 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 22:03:24 -0700 From: "Joseph Salowey" To: "'Simon Tatham'" , Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 21:59:18 -0700 Message-ID: <01ad01c36220$d1b40fa0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Aug 2003 05:03:24.0976 (UTC) FILETIME=[641FE300:01C36221] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit URI's have a pretty specific format detailed in RFC 2396. Here is my interpretation For SCP/SFTP we are defining Abolute URI AbsoluteURI = scheme ":" (hier_part | opaque_part) If we deicide that SCP URIs are hierarchical in nature and will be parsed by a URI parser then we use a hier_part. Hier-Part = "//authority [abs_path] Abs_path = "/" path_segments In this case we use the standard URI definitions to define the authority (User@host:port). Along with this comes the leading '/' and the use of '/' as a path separator. This means that SCP will have to have a minimal URI paser. This means the C:\mywindows\files may be represented as Scp://host/c:/mywindows/files If we choose to make them opaque then what comes after scp: is defined and parsed by SCP then the URI for the above file might look like (other parsing schemes are possible, the point is they do not have to adhere to URI parsing). Scp:user:@host::c:\mywindows\files In general since filesystems have a hierachical structure it is probably better to go with hierarchical naming. This makes it possible to use relative URLs and reference a resource in different ways. Thanks, Joe > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Simon Tatham > Sent: Wednesday, August 13, 2003 4:26 PM > To: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > Joseph Salowey wrote: > > So how about > > scp://hostname/c:/bin/thingy > > The difficulty with that is that you really want the SCP > client to send the pathname 'c:/bin/thingy', without a > leading slash. But when you say `scp://hostname/usr/bin/foo', > you want the SCP client to send `/usr/bin/foo', _with_ the > leading slash. So this design requires the _client_ to do > something clever about conditionally stripping the leading > slash. Surely? > > (Unless you're mandating that the _server_ in the 'c:/' case > must be capable of throwing away a leading slash? But that > seems like a requirement on server behaviour as well as URI > format, which is fairly serious remit creep...) > > -- > Simon Tatham "I'm going to pull his head off. Ear by ear." > - a games teacher > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 01:16: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 BAA17372 for ; Thu, 14 Aug 2003 01:16:25 -0400 (EDT) Received: (qmail 20543 invoked by uid 605); 14 Aug 2003 05:16:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20536 invoked from network); 14 Aug 2003 05:16:25 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 14 Aug 2003 05:16:25 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7E5GMLH021684; Wed, 13 Aug 2003 22:16:23 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 22:20:27 -0700 From: "Joseph Salowey" To: "'Darren J Moffat'" , Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 22:16:21 -0700 Message-ID: <01ae01c36223$33899d60$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Aug 2003 05:20:28.0108 (UTC) FILETIME=[C5F570C0:01C36223] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Comments inline > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Darren J Moffat > Sent: Wednesday, August 13, 2003 5:08 PM > To: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > On Thu, 14 Aug 2003, Simon Tatham wrote: > > > (Unless you're mandating that the _server_ in the 'c:/' > case must be > > capable of throwing away a leading slash? But that seems like a > > requirement on server behaviour as well as URI format, > which is fairly > > serious remit creep...) > > Keeping in mind that scp is really just the rcp protocol over > the SSH transport. Since rcp is a historically a UNIX > protocol it doesn't (at least to me, but probably not to > everyone) seem unreasonable that a server providing access > via rcp should do the work of mapping UNIX style names to its > style. Isn't that the case with '/' vs '\' on Windows anyway ? > [Joe] URI syntax dictates the leading '/' and the use of '/' as a separator in a hierarcical namespace. > How would one specify an scp URI that was accessing a > resource mounted from a remote Windows filesystem (IIRC > double slashes are required). > [Joe] Okay, my brain hurts. Scp://hostname/\\remotehostname\directory\file > Bill Sommerfeld wrote: > > > An alternative (which would confuse a different set of > people) would > > be to always eat the / after then hostname-part of the URL, so for > > unix systems, you'd see URL's like: > > > scp://user@hostname/.login (referring to the .login in > your home directory) > > scp://user@hostname//etc/passwd > > Given the user@ part that actually seems reasonable, and it > makes it similar to the following cli syntax for scp(1): > > $ scp user@hostname:.login > $ scp user@hostname:/etc/passwd > > The double // requirement could be confusing in a case where > "userinfo@" isn't specified. For example: > [Joe] The "//" is part of URL syntax and is required if we are using hierarcical naming > scp://hostname/etc/passwd or scp://hostname//etc/passwd > > Based on the behaviour of http I would personally have > expected these to be equivalent, however they wouldn't > necessarily be. What is the username on the remote host when > "userinfo@" isn't specified (which is where the home > directory is inferred from). > [Joe] There is madness in the method In general scp://hostname/etc/passwd means cd etc (not /etc) get the file passwd (this would probably get you the passwd file under the etc directory in your home directory) Scp://hostname//etc/passwd means cd cd etc Get the file passwd (this would probably get you the passwd file under the etc directory in your home directory) Scp://hostname/%2Fetc/passwd means cd /etc Get the file passwd (this would get you the file /etc/passwd, note that the '/' must be escaped as %2F since it is a reserved character in hierarchical URLs) This is detailed in http://www.ietf.org/internet-drafts/draft-hoffkohn-rfc1738bis-00.txt section 2.2.2. I expect we need a similar description for SCP and SFTP. > -- > Darren J Moffat > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 01:19: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 BAA17401 for ; Thu, 14 Aug 2003 01:19:17 -0400 (EDT) Received: (qmail 21978 invoked by uid 605); 14 Aug 2003 05:19:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21962 invoked from network); 14 Aug 2003 05:19:17 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by mail.netbsd.org with SMTP; 14 Aug 2003 05:19:17 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7E5JEpp029818; Wed, 13 Aug 2003 22:19:15 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 22:23:20 -0700 From: "Joseph Salowey" To: "'Simon Tatham'" Cc: Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 22:19:13 -0700 Message-ID: <01af01c36223$9a1b3e80$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Aug 2003 05:23:20.0172 (UTC) FILETIME=[2C8452C0:01C36224] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > > Do you see an issue with this? > > Well, the URI definition said > > scp_URI = "scp://" [ userinfo "@" ] host [ ":" port ] > [ ; parameter = value ] [ abs_path ] > > So the `abs_path' section starts immediately after the host > name, and hence it is expected to begin with a slash: [Joe] So abs_path is defined in RFC2396 as Abs_path = '/' path_segments We will need to include ABNF refernces in the next revision. > > scp://hostname/usr/bin/thingy > ^^^^^^^^^^^^^^^ > > If the abs_path doesn't begin with a slash, you get > > scp://hostnamec:\bin\thingy > > which is clearly useless (and that's without even going into > the backslash issue). > > -- > Simon Tatham "_shin_, n. An ingenious device for > finding tables and chairs in the dark." > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 01:20: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 BAA17425 for ; Thu, 14 Aug 2003 01:20:52 -0400 (EDT) Received: (qmail 23767 invoked by uid 605); 14 Aug 2003 05:20:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23759 invoked from network); 14 Aug 2003 05:20:51 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 14 Aug 2003 05:20:51 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7E5KnuG010155; Wed, 13 Aug 2003 22:20:49 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.92]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Aug 2003 22:24:54 -0700 From: "Joseph Salowey" To: "'Simon Tatham'" , Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Wed, 13 Aug 2003 22:20:48 -0700 Message-ID: <01b001c36223$d23dd1b0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Aug 2003 05:24:54.0360 (UTC) FILETIME=[64A84580:01C36224] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Simon Tatham > Sent: Wednesday, August 13, 2003 4:26 PM > To: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > Joseph Salowey wrote: > > So how about > > scp://hostname/c:/bin/thingy > > The difficulty with that is that you really want the SCP > client to send the pathname 'c:/bin/thingy', without a > leading slash. But when you say `scp://hostname/usr/bin/foo', > you want the SCP client to send `/usr/bin/foo', _with_ the > leading slash. So this design requires the _client_ to do > something clever about conditionally stripping the leading > slash. Surely? > [Joe] Yes the client needs to implement a URI parser. > (Unless you're mandating that the _server_ in the 'c:/' case > must be capable of throwing away a leading slash? But that > seems like a requirement on server behaviour as well as URI > format, which is fairly serious remit creep...) > > -- > Simon Tatham "I'm going to pull his head off. Ear by ear." > - a games teacher > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 08:33:41 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 IAA07816 for ; Thu, 14 Aug 2003 08:33:40 -0400 (EDT) Received: (qmail 6065 invoked by uid 605); 14 Aug 2003 12:33:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6058 invoked from network); 14 Aug 2003 12:33:33 -0000 Received: from satva.skalasoft.com (212.36.10.173) by mail.netbsd.org with SMTP; 14 Aug 2003 12:33:33 -0000 Received: (qmail 15951 invoked from network); 14 Aug 2003 11:35:28 -0000 Received: from satva.int.skalasoft.com (HELO roumenpetrov.info) (192.168.0.100) by satva.int.skalasoft.com with SMTP; 14 Aug 2003 11:35:28 -0000 Message-ID: <3F3B8192.1030306@roumenpetrov.info> Date: Thu, 14 Aug 2003 15:33:22 +0300 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: bg, ru, de, en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: Joseph Salowey , "'Simon Tatham'" , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt References: <200308132323.h7DNNE8Q028799@thunk.east.sun.com> Content-Type: multipart/mixed; boundary="------------030806060201040401010904" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------030806060201040401010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit What about syntax: secsh_URI := secsh_scheme "://" [secsh_userinfo] "@" ] host [ ":" port ] [; params] [abs_path] secsh_scheme := {ssh|scp|sftp} abs_path := "/" path_segments path_segments := ["/"] segment [ "/" segment] params := parameter=value [, parameter=value] - when path_segments begin with "/" or "%2F" => path is relative to "/" or "My Computer(?)" :) for windows otherwise to user home directory. - when parameter is not supported by scheme should be ignored - as example typecode for ssh. Misc.: I hope that attached shell script "ftp-url-test.sh" will help to understand ftp urls. Script use two programs wget and curl. Before to run we should create directory "c:" in user home "${HOME}" and in root "/" and file path.txt in them, i.e.: ----------------------------------------------------------------------------- $ cd $ mkdir 'c:' $ cd 'c:' $ pwd > path.txt $ su - # cd / # mkdir 'c:' # cd 'c:' # pwd > path.txt ----------------------------------------------------------------------------- output from script is similar to: ----------------------------------------------------------------------------- === port:= ===[ftp://test:change_it@localhost/c:/path.txt]=== wget->/home/test/c: curl->/home/test/c: ===[ftp://test:change_it@localhost/c%3A/path.txt]=== wget->/home/test/c: curl->/home/test/c: ===[ftp://test:change_it@localhost//c:/path.txt]=== wget->/c: curl->/c: ===[ftp://test:change_it@localhost//c%3A/path.txt]=== wget->/c: curl->/c: ===[ftp://test:change_it@localhost/%2Fc%3A/path.txt]=== wget->/c: curl->/c: === port:=21 ===[ftp://test:change_it@localhost:21/c:/path.txt]=== wget->/home/test/c: curl->/home/test/c: ===[ftp://test:change_it@localhost:21/c%3A/path.txt]=== wget->/home/test/c: curl->/home/test/c: ===[ftp://test:change_it@localhost:21//c:/path.txt]=== wget->/c: curl->/c: ===[ftp://test:change_it@localhost:21//c%3A/path.txt]=== wget->/c: curl->/c: ===[ftp://test:change_it@localhost:21/%2Fc%3A/path.txt]=== wget->/c: curl->/c: ----------------------------------------------------------------------------- Browsers: - Konqueror 3.0.x ( not tested with versions > 3.1 and < 3.0 ) always download "/c:/path.txt" :-( - ftp in Opera 6.0 (not tested with versions >= 6.1 and < 6) is not stable (problems with userinfo and ":" in path). - Gecko (not tested with versions < 1.0) - fine - IE - not tested. - Comunicator (Netcape 4.7x): - "ftp://user:pass@host" list user home dir and change url to ftp://user@host/path_to_user_home - "ftp://user:pass@host/" list root directory , i.e. depend from implementation :-( Bill Sommerfeld wrote: >>scp://hostname/c:/bin/thingy >> >>Isn't there current a similar problem with ftp urls? >> >>It would seem that in order to form the URL you would have to convert >>path-separators into / to fit into URL syntax. I think this is what is >>done with FTP. >> >> >yep, that matches my (possibly lossy) understanding of ftp as well >(shortly after NetBSD's ftp client was extended to take url's on the >command line, there was a followup code change to do individual >cd's for each URL component ..) > --------------030806060201040401010904 Content-Type: text/plain; name="ftp-url-test.sh" Content-Disposition: inline; filename="ftp-url-test.sh" Content-Transfer-Encoding: 7bit #!/bin/sh # Author: Roumen Petrov WGET="wget" WGET_OPT="--proxy=off -e verbose=off -e debug=off -e server_response=off --output-document=-" CURL="curl" CURL_OPT="" DEFAULT_PORT="21" # === scheme="ftp" user="${USER}" pass="change_it" userinfo="${user}:${pass}" host="localhost" for port in '' 21; do echo "=== port:=${port}" hostport="" #if test -n "${port}" -a "${port}" != "${DEFAULT_PORT}"; then if test -n "${port}"; then hostport="${host}:${port}" else hostport="${host}" fi for abs_path in \ 'c:/path.txt' \ 'c%3A/path.txt' \ '/c:/path.txt' \ '/c%3A/path.txt' \ '%2Fc%3A/path.txt' \ ; do URL="${scheme}://${userinfo}@${hostport}/${abs_path}" echo "===[${URL}]===" printf "wget->"; ${WGET} ${WGET_OPT} "${URL}" 2>/dev/null printf "curl->"; ${CURL} ${CURL_OPT} "${URL}" 2>/dev/null done done --------------030806060201040401010904-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 10:35:17 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 KAA12417 for ; Thu, 14 Aug 2003 10:35:17 -0400 (EDT) Received: (qmail 14755 invoked by uid 605); 14 Aug 2003 14:35:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14738 invoked from network); 14 Aug 2003 14:35:00 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 14 Aug 2003 14:35:00 -0000 Received: from extremenetworks.com (unknown [10.0.8.124]) by gnat.inet.org (Postfix) with ESMTP id F034567105; Thu, 14 Aug 2003 11:07:38 -0400 (EDT) Date: Thu, 14 Aug 2003 10:34:35 -0400 Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-ssh@NetBSD.org To: Darren J Moffat From: RJ Atkinson In-Reply-To: Message-Id: <6D2A9E78-CE64-11D7-8C7E-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, Aug 13, 2003, at 20:07 America/Montreal, Darren J Moffat wrote: > Since rcp is a historically a UNIX protocol it doesn't (at > least to me, but probably not to everyone) seem unreasonable that a > server providing access via rcp should do the work of mapping UNIX > style names to its style. To confirm and be more precise, RCP was invented at UC Berkeley as part of the BSD UNIX distributions. So the protocol has always been UNIX-centric for those reasons. It is far too late in the day to be proposing any changes to RCP in that regard. IMHO, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 14:53:09 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 OAA21819 for ; Thu, 14 Aug 2003 14:53:08 -0400 (EDT) Received: (qmail 13706 invoked by uid 605); 14 Aug 2003 18:53:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13699 invoked from network); 14 Aug 2003 18:53:07 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 14 Aug 2003 18:53:07 -0000 Received: by xanthine.gratuitous.org with local; Thu, 14 Aug 2003 14:53:06 -0400 From: "Joel N. Weber II" To: Jeffrey Altman CC: ietf-ssh@NetBSD.org In-reply-to: <3F3AEC49.8030605@columbia.edu> (message from Jeffrey Altman on Wed, 13 Aug 2003 21:56:25 -0400) Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: <200308132044.h7DKiG8Q027644@thunk.east.sun.com> <3F3AEC49.8030605@columbia.edu> Message-Id: Date: Thu, 14 Aug 2003 14:53:06 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Kermit software has supported since the early 80s both a Short Break and > Long Break. A break less than 300ms is short; a break greater than > 700ms is long. These due have meanings for some modems and some > terminal servers. Would it be reasonable to define a ``short break'' and a ``long break'' command in the ssh protocol, and not worry about sending the exact lengths of time? If the client sends an exact number of miliseconds, and some devices are pickier than others about the length of a break that they get, and you end up with different clients that have different defaults, keeping track of things and wondering why some people's clients send breaks that work and other people's clients send breaks that don't work is likely to get confusing. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 17:47: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 RAA27723 for ; Thu, 14 Aug 2003 17:47:27 -0400 (EDT) Received: (qmail 28733 invoked by uid 605); 14 Aug 2003 21:47:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28720 invoked from network); 14 Aug 2003 21:47:22 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 14 Aug 2003 21:47:22 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with SMTP id 299B11EB70; Thu, 14 Aug 2003 23:47:13 +0200 (CEST) Received: from 212.23.126.4 (SquirrelMail authenticated user sircus) by mail.siliconcircus.com with HTTP; Thu, 14 Aug 2003 23:47:13 +0200 (CEST) Message-ID: <5729.212.23.126.4.1060897633.squirrel@mail.siliconcircus.com> In-Reply-To: References: <200308132044.h7DKiG8Q027644@thunk.east.sun.com> <3F3AEC49.8030605@columbia.edu> Date: Thu, 14 Aug 2003 23:47:13 +0200 (CEST) Subject: Re: Please publish attached draft-ietf-secsh-break-01 From: "Jon Bright" To: "Joel N. Weber II" Cc: "Jeffrey Altman" , ietf-ssh@NetBSD.org Reply-To: jon@siliconcircus.com User-Agent: SquirrelMail/1.4.0 RC2a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Would it be reasonable to define a ``short break'' and a ``long > break'' command in the ssh protocol, and not worry about sending the > exact lengths of time? One could alternatively define 0 = server-chosen short break, 0xFFFFFFFF = server-chosen long break, other values = client-chosen break. I imagine most clients would then just implement the short/long options, leaving only those who really know what they're doing to specify an explicit length... -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 14 19:47: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 TAA02025 for ; Thu, 14 Aug 2003 19:47:54 -0400 (EDT) Received: (qmail 13506 invoked by uid 605); 14 Aug 2003 23:47:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13494 invoked from network); 14 Aug 2003 23:47:52 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 14 Aug 2003 23:47:52 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7ENlIjL007725; Thu, 14 Aug 2003 16:47:18 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.10.Beta3+Sun/8.12.10.Beta3) with ESMTP id h7ENlIF6641163; Thu, 14 Aug 2003 16:47:18 -0700 (PDT) Date: Thu, 14 Aug 2003 16:47:18 -0700 (PDT) From: Darren J Moffat To: cc: Subject: draft-ietf-secsh-assignednumbers-03.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: February 12, 2004 D. Moffat Sun Microsystems August 14, 2003 SSH Protocol Assigned Numbers draft-ietf-secsh-assignednumbers-03.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 February 12, 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 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. Lehtinen & Moffat Expires February 12, 2004 [Page 1] Internet-Draft SSH Protocol Assigned Numbers August 2003 Table of Contents 1. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Disconnect Codes . . . . . . . . . . . . . . . . . . . . . . 4 2. Service Names . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Authentication Method Names . . . . . . . . . . . . . . . . 5 2.2 Connection Protocol Assigned Names . . . . . . . . . . . . . 6 2.2.1 Connection Protocol Channel Types . . . . . . . . . . . . . 6 2.2.2 Connection Protocol Global Request Names . . . . . . . . . . 6 2.2.3 Connection Protocol Channel Request Names . . . . . . . . . 6 3. Key Exchange Method Names . . . . . . . . . . . . . . . . . 7 4. Assigned Algorithm Names . . . . . . . . . . . . . . . . . . 7 4.1 Encryption Algorithm Names . . . . . . . . . . . . . . . . . 7 4.2 MAC Algorithm Names . . . . . . . . . . . . . . . . . . . . 8 4.3 Public Key Algorithm Names . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 Lehtinen & Moffat Expires February 12, 2004 [Page 2] Internet-Draft SSH Protocol Assigned Numbers August 2003 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 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] Lehtinen & Moffat Expires February 12, 2004 [Page 3] Internet-Draft SSH Protocol Assigned Numbers August 2003 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] 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] Lehtinen & Moffat Expires February 12, 2004 [Page 4] Internet-Draft SSH Protocol Assigned Numbers August 2003 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 [SSH-TRANS] SSH_DISCONNECT_ILLEGAL_USER_NAME 15 [SSH-TRANS] 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] 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] Lehtinen & Moffat Expires February 12, 2004 [Page 5] Internet-Draft SSH Protocol Assigned Numbers August 2003 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. 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] 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] 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] Lehtinen & Moffat Expires February 12, 2004 [Page 6] Internet-Draft SSH Protocol Assigned Numbers August 2003 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] 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. 4.1 Encryption Algorithm Names Cipher name Reference ------------ --------- 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] Lehtinen & Moffat Expires February 12, 2004 [Page 7] Internet-Draft SSH Protocol Assigned Numbers August 2003 des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS 46-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] 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] References [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- ietf-architecture-14.txt, July 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-16.txt, July 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- ietf-userauth-17.txt, July 2003. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- ietf-connect-17.txt, July 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers- 03.txt, July 2003. [FIPS-46-3] U.S. Dept. of Commerce, ., "FIPS PUB 46-3, Data Lehtinen & Moffat Expires February 12, 2004 [Page 8] Internet-Draft SSH Protocol Assigned Numbers August 2003 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 Sun Microsystems 901 San Antonio Road Palo Alto 94303 USA EMail: Darren.Moffat@Sun.COM Lehtinen & Moffat Expires February 12, 2004 [Page 9] Internet-Draft SSH Protocol Assigned Numbers August 2003 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 assigns. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lehtinen & Moffat Expires February 12, 2004 [Page 10] -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 04:36: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 EAA21748 for ; Fri, 15 Aug 2003 04:36:27 -0400 (EDT) Received: (qmail 29409 invoked by uid 605); 15 Aug 2003 08:36:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29400 invoked from network); 15 Aug 2003 08:36:21 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Aug 2003 08:36:21 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa14102; 15 Aug 2003 4:35 EDT Date: Fri, 15 Aug 2003 04:35:34 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org cc: "Joel N. Weber II" , Joseph Salowey Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-ID: <103050000.1060936534@minbar.fac.cs.cmu.edu> In-Reply-To: References: <015801c361c7$a3058520$0300000a@amer.cisco.com> 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 Wednesday, August 13, 2003 17:55:55 -0400 "Joel N. Weber II" wrote: >> > I don't think explicitly specifying port 22 in all cases >> > where the URL doesn't specify a port number is correct; what >> > about SRV DNS records? >> [Joe] So the suggestion would be something like: >> >> If the URL doesn't specify a port number the it should check for a SRV >> DNS record if it is available, if it is not then it should use port 22. > > It might be better to come up with language along the lines that if > the port number is specified in the URL, it is used, otherwise the > port number to use is determined by what is specified in the other > secsh documents. However, it seems like there's a little bit of > vagueness there; the transport draft says that ssh normally listens on > port 22, and there's no mention of SRV records anywhere in the secsh > documents, as far as I can tell. Indeed, the behavior should be exactly as if the user ran the ssh client without specifying a port. For most (all?) ssh clients, that means connecting to port 22. RFC2782 is fairly clear on this: Service SRV records SHOULD NOT be used in the absence of such specification. That is, if the SSH protocol spec does not specify the use of SRV records, then their use by implementations is explicitly NOT RECOMMENDED by RFC2782. In the present case, we're defining a URL syntax for a protocol which is primarily accessed by means other than URL's. It would seem inappropriate in such a context to specify the use of SRV records when the underlying protocol does not do so. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 12:50:58 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 MAA03199 for ; Fri, 15 Aug 2003 12:50:57 -0400 (EDT) Received: (qmail 14030 invoked by uid 605); 15 Aug 2003 16:50:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14023 invoked from network); 15 Aug 2003 16:50:44 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 15 Aug 2003 16:50:44 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03138; Fri, 15 Aug 2003 12:50:39 -0400 (EDT) Message-Id: <200308151650.MAA03138@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-weber-secsh-pgp-sign-00.txt Date: Fri, 15 Aug 2003 12:50:38 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Shell 'pgp-sign-*' Public Key Algorithms Author(s) : J. Weber Filename : draft-weber-secsh-pgp-sign-00.txt Pages : 6 Date : 2003-8-15 This document clarifies details of using OpenPGP keys as host keys and user authentication keys in the Secure Shell protocol. Preventing man in the middle attacks is an important part of security, and in many circumstances verifying the authenticity of an OpenPGP key will be easier than verifying the authenticity of an ssh- rsa or ssh-dss key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weber-secsh-pgp-sign-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-pgp-sign-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-pgp-sign-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-8-15123927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-weber-secsh-pgp-sign-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-weber-secsh-pgp-sign-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15123927.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 12:51:25 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 MAA03283 for ; Fri, 15 Aug 2003 12:51:25 -0400 (EDT) Received: (qmail 14682 invoked by uid 605); 15 Aug 2003 16:51:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14672 invoked from network); 15 Aug 2003 16:51:18 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 15 Aug 2003 16:51: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 MAA03271; Fri, 15 Aug 2003 12:51:13 -0400 (EDT) Message-Id: <200308151651.MAA03271@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-03.txt Date: Fri, 15 Aug 2003 12:51:13 -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 Protocol Assigned Numbers Author(s) : S. Lehtinen, D. Moffat Filename : draft-ietf-secsh-assignednumbers-03.txt Pages : 10 Date : 2003-8-15 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-03.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-03.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-03.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-8-15124051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15124051.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 13:00:48 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 NAA03832 for ; Fri, 15 Aug 2003 13:00:47 -0400 (EDT) Received: (qmail 21441 invoked by uid 605); 15 Aug 2003 17:00:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21434 invoked from network); 15 Aug 2003 17:00:47 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 15 Aug 2003 17:00:47 -0000 Received: by xanthine.gratuitous.org with local; Fri, 15 Aug 2003 13:00:43 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org, Joseph Salowey In-reply-to: <103050000.1060936534@minbar.fac.cs.cmu.edu> (message from Jeffrey Hutzelman on Fri, 15 Aug 2003 04:35:34 -0400) Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt References: <015801c361c7$a3058520$0300000a@amer.cisco.com> <103050000.1060936534@minbar.fac.cs.cmu.edu> Message-Id: Date: Fri, 15 Aug 2003 13:00:43 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > > It might be better to come up with language along the lines that if > > the port number is specified in the URL, it is used, otherwise the > > port number to use is determined by what is specified in the other > > secsh documents. However, it seems like there's a little bit of > > vagueness there; the transport draft says that ssh normally listens on > > port 22, and there's no mention of SRV records anywhere in the secsh > > documents, as far as I can tell. > > Indeed, the behavior should be exactly as if the user ran the ssh client > without specifying a port. Yep, and the URL spec should say that > For most (all?) ssh clients, that means > connecting to port 22. and not mention port 22, so that we don't have to update the URL spec in the future if this changes. > RFC2782 is fairly clear on this: > > Service SRV records SHOULD NOT be used in the absence > of such specification. > > That is, if the SSH protocol spec does not specify the use of SRV records, > then their use by implementations is explicitly NOT RECOMMENDED by RFC2782. > In the present case, we're defining a URL syntax for a protocol which is > primarily accessed by means other than URL's. It would seem inappropriate > in such a context to specify the use of SRV records when the underlying > protocol does not do so. Interesting. I'm aware of some ssh SRV records that a friend set up, so I assumed that using them was correct. RFC2782 doesn't seem to offer any guidance about which protocols should use SRV, and which shouldn't. Is not using SRV in ssh a delibrate decision? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 13:03: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 NAA03867 for ; Fri, 15 Aug 2003 13:03:50 -0400 (EDT) Received: (qmail 24820 invoked by uid 605); 15 Aug 2003 17:03:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24790 invoked from network); 15 Aug 2003 17:03:25 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 15 Aug 2003 17:03:25 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7FH3Mtp007605; Fri, 15 Aug 2003 10:03:23 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.226.240]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Aug 2003 10:07:28 -0700 From: "Joseph Salowey" To: "'Darren J Moffat'" , Cc: Subject: RE: draft-ietf-secsh-assignednumbers-03.txt Date: Fri, 15 Aug 2003 10:03:20 -0700 Message-ID: <023601c3634f$222ce680$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 15 Aug 2003 17:07:28.0956 (UTC) FILETIME=[B52AE7C0:01C3634F] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I didn't see compression methods listed in this document. Should they be? Joe From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 13:17:11 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 NAA05428 for ; Fri, 15 Aug 2003 13:17:09 -0400 (EDT) Received: (qmail 3268 invoked by uid 605); 15 Aug 2003 17:17:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3261 invoked from network); 15 Aug 2003 17:17:11 -0000 Received: from mx03.forces.gc.ca (131.137.245.203) by mail.netbsd.org with SMTP; 15 Aug 2003 17:17:11 -0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 4E5EF20660D for ; Fri, 15 Aug 2003 13:15:28 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19nhoO-0001my-Ao for ietf-announce-list@asgard.ietf.org; Fri, 15 Aug 2003 12:52:24 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19nhmn-0001k2-86 for all-ietf@asgard.ietf.org; Fri, 15 Aug 2003 12:50:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03138; Fri, 15 Aug 2003 12:50:39 -0400 (EDT) Message-Id: <200308151650.MAA03138@ietf.org> To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-weber-secsh-pgp-sign-00.txt Date: Fri, 15 Aug 2003 12:50:38 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+65750_7657446512562_74911721118" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --MIMEStream=_0+65750_7657446512562_74911721118 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Shell 'pgp-sign-*' Public Key Algorithms Author(s) : J. Weber Filename : draft-weber-secsh-pgp-sign-00.txt Pages : 6 Date : 2003-8-15 This document clarifies details of using OpenPGP keys as host keys and user authentication keys in the Secure Shell protocol. Preventing man in the middle attacks is an important part of security, and in many circumstances verifying the authenticity of an OpenPGP key will be easier than verifying the authenticity of an ssh- rsa or ssh-dss key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weber-secsh-pgp-sign-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-pgp-sign-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-pgp-sign-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. --MIMEStream=_0+65750_7657446512562_74911721118 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+11470_020396339513176_8762206489" --MIMEStream=_1+11470_020396339513176_8762206489 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-15123927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-weber-secsh-pgp-sign-00.txt --MIMEStream=_1+11470_020396339513176_8762206489 Content-Type: Message/External-body; name="draft-weber-secsh-pgp-sign-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-15123927.I-D@ietf.org> --MIMEStream=_1+11470_020396339513176_8762206489-- --MIMEStream=_0+65750_7657446512562_74911721118-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 13:56: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 NAA06795 for ; Fri, 15 Aug 2003 13:56:40 -0400 (EDT) Received: (qmail 25304 invoked by uid 605); 15 Aug 2003 17:56:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25297 invoked from network); 15 Aug 2003 17:56:38 -0000 Received: from mail.braingia.org (HELO netserver.braingia.org) (65.169.213.77) by mail.netbsd.org with SMTP; 15 Aug 2003 17:56:38 -0000 Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10]) by netserver.braingia.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7FHuMnt015753 for ; Fri, 15 Aug 2003 12:56:22 -0500 Received: (from suehring@localhost) by netserver.braingia.org (8.12.3/8.12.3/Debian-6.4) id h7FHuA41015732 for ietf-ssh@netbsd.org; Fri, 15 Aug 2003 12:56:10 -0500 Date: Fri, 15 Aug 2003 12:56:10 -0500 From: Steve Suehring To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-ID: <20030815175610.GA14087@mail.braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org References: <015801c361c7$a3058520$0300000a@amer.cisco.com> <103050000.1060936534@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Aug 15, 2003 at 01:00:43PM -0400, Joel N. Weber II wrote: > > Indeed, the behavior should be exactly as if the user ran the ssh client > > without specifying a port. > > Yep, and the URL spec should say that I guess I'm just not sure if we need to get more specific about the port. In looking at RFC 2396, "If the port is omitted, the default port number is assumed." The wording as it stands in the draft is "If the port is not included, port 22 is assumed." Therefore, should we just change it to: "If the port is not included, the default port is assumed."? I personally like it as is with the specific port included, but I'm not against changing it. Steve From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 14:26: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 OAA07604 for ; Fri, 15 Aug 2003 14:26:54 -0400 (EDT) Received: (qmail 16928 invoked by uid 605); 15 Aug 2003 18:26:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16921 invoked from network); 15 Aug 2003 18:26:53 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Aug 2003 18:26:53 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa16207; 15 Aug 2003 14:26 EDT Date: Fri, 15 Aug 2003 14:26:05 -0400 From: Jeffrey Hutzelman To: "Joel N. Weber II" cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org, Joseph Salowey Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-ID: <193900000.1060971965@minbar.fac.cs.cmu.edu> In-Reply-To: References: <015801c361c7$a3058520$0300000a@amer.cisco.com> <103050000.1060936534@minbar.fac.cs.cmu.edu> 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 >> For most (all?) ssh clients, that means >> connecting to port 22. > > and not mention port 22, so that we don't have to update the URL spec > in the future if this changes. Agree. >> RFC2782 is fairly clear on this: >> >> Service SRV records SHOULD NOT be used in the absence >> of such specification. >> >> That is, if the SSH protocol spec does not specify the use of SRV >> records, then their use by implementations is explicitly NOT >> RECOMMENDED by RFC2782. In the present case, we're defining a URL >> syntax for a protocol which is primarily accessed by means other than >> URL's. It would seem inappropriate in such a context to specify the >> use of SRV records when the underlying protocol does not do so. > > Interesting. I'm aware of some ssh SRV records that a friend set up, > so I assumed that using them was correct. Well, "MUST is for implementors", so YMMV. > RFC2782 doesn't seem to offer any guidance about which protocols > should use SRV, and which shouldn't. Correct. It doesn't offer a lot of guidance to protocol designers as to when it makes sense to specify the use of SRV records and when it does not. IMHO, SRV records are appropriate for services where you're likely to want to find a canonical instance of a service for a particular site (such as Kerberos KDC's), or where service may be provided by a set of redundant machines (such as mail exchangers). It doesn't make sense for host-directed interactive services like telnet and ssh, except perhaps in a small number of cases. The guidance that RFC2782 _does_ provide is to implementors, particularly of clients -- it RECOMMENDs that SRV records not be used unless specified. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 15:30: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 PAA10577 for ; Fri, 15 Aug 2003 15:30:02 -0400 (EDT) Received: (qmail 25481 invoked by uid 605); 15 Aug 2003 19:30:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25434 invoked from network); 15 Aug 2003 19:30:00 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Aug 2003 19:30:00 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7FJTod6013200; Fri, 15 Aug 2003 13:29:50 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7FJTntK003041; Fri, 15 Aug 2003 15:29:49 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7FJTm8Q014539; Fri, 15 Aug 2003 15:29:49 -0400 (EDT) Message-Id: <200308151929.h7FJTm8Q014539@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Salowey" cc: "'Darren J Moffat'" , internet-drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-assignednumbers-03.txt In-Reply-To: Your message of "Fri, 15 Aug 2003 10:03:20 PDT." <023601c3634f$222ce680$0300000a@amer.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 15 Aug 2003 15:29:48 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > From: "Joseph Salowey" > To: "'Darren J Moffat'" , > Cc: > Subject: RE: draft-ietf-secsh-assignednumbers-03.txt > Date: Fri, 15 Aug 2003 10:03:20 -0700 > > I didn't see compression methods listed in this document. Should they > be? Argh. Yes. Darren: Please add a new section 4.4: 4.4 Compression algorithm names Algorithm name Reference --------------- --------- none [SSH-TRANS, Section 4.2] zlib [SSH-TRANS, Section 4.2] and respin. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 17:16:10 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 RAA14128 for ; Fri, 15 Aug 2003 17:16:10 -0400 (EDT) Received: (qmail 13800 invoked by uid 605); 15 Aug 2003 21:16:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13789 invoked from network); 15 Aug 2003 21:16:11 -0000 Received: from firebird.cisco.com (HELO fire.cisco.com) (171.68.227.73) by mail.netbsd.org with SMTP; 15 Aug 2003 21:16:11 -0000 Received: from REMAKERW2K (remaker-w2k.cisco.com [171.69.103.51]) by fire.cisco.com (8.11.7+Sun/8.8.8) with SMTP id h7FL8JO25249; Fri, 15 Aug 2003 14:08:19 -0700 (PDT) Message-ID: <084e01c36371$5a4966c0$336745ab@amer.cisco.com> From: "Phillip Remaker" To: "Markus Friedl" , "Joseph Galbraith" Cc: References: <02fb01c2f613$0220a2e0$4d00a8c0@galb.vandyke.com> <20030813104459.GA26607@folly> Subject: Re: Please publish attached draft-ietf-secsh-break-01 Date: Fri, 15 Aug 2003 14:08:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > On Sat, Mar 29, 2003 at 09:48:21AM -0700, Joseph Galbraith wrote: > > uint32 break-length in milliseconds > > what's the reason for including this in the protocol? > > shouldn't the server decide what break-length is reasonable? e.g. > depending on what kind of devices is attached? Historically, there are some devices which will react differently to a short break or a long break (KERMIT has two different break lengths, for example: 250ms and 1500ms). In order that the varied break length has a means to be transmitted, the break-length field is added. Conceivabely, it could be a long break or short break boolean, but for maximum flexibility, the length field was added. For Cisco devices, the break length is hard coded at 500ms, so Cisco servers will ignore the field when present. SSH servers providing RS-232 port access can deal with the field as they feel appropriate. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 17:23: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 RAA14667 for ; Fri, 15 Aug 2003 17:23:22 -0400 (EDT) Received: (qmail 18481 invoked by uid 605); 15 Aug 2003 21:20:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18457 invoked from network); 15 Aug 2003 21:20:26 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 Aug 2003 21:20:26 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7FLKO6Q019638; Fri, 15 Aug 2003 15:20:24 -0600 (MDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.10.Beta3+Sun/8.12.10.Beta3) with ESMTP id h7FLKOF6865929; Fri, 15 Aug 2003 14:20:24 -0700 (PDT) Date: Fri, 15 Aug 2003 14:20:23 -0700 (PDT) From: Darren J Moffat Reply-To: To: cc: Subject: draft-ietf-secsh-assignednumbers-04.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: February 13, 2004 D. Moffat Sun Microsystems August 15, 2003 SSH Protocol Assigned Numbers draft-ietf-secsh-assignednumbers-04.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 February 13, 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 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. Lehtinen & Moffat Expires February 13, 2004 [Page 1] Internet-Draft SSH Protocol Assigned Numbers August 2003 Table of Contents 1. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Disconnect Codes . . . . . . . . . . . . . . . . . . . . . . 4 2. Service Names . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Authentication Method Names . . . . . . . . . . . . . . . . 5 2.2 Connection Protocol Assigned Names . . . . . . . . . . . . . 6 2.2.1 Connection Protocol Channel Types . . . . . . . . . . . . . 6 2.2.2 Connection Protocol Global Request Names . . . . . . . . . . 6 2.2.3 Connection Protocol Channel Request Names . . . . . . . . . 6 3. Key Exchange Method Names . . . . . . . . . . . . . . . . . 7 4. Assigned Algorithm Names . . . . . . . . . . . . . . . . . . 7 4.1 Encryption Algorithm Names . . . . . . . . . . . . . . . . . 7 4.2 MAC Algorithm Names . . . . . . . . . . . . . . . . . . . . 8 4.3 Public Key Algorithm Names . . . . . . . . . . . . . . . . . 8 4.4 Compression Algorithm Names . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 Lehtinen & Moffat Expires February 13, 2004 [Page 2] Internet-Draft SSH Protocol Assigned Numbers August 2003 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 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] Lehtinen & Moffat Expires February 13, 2004 [Page 3] Internet-Draft SSH Protocol Assigned Numbers August 2003 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] 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] Lehtinen & Moffat Expires February 13, 2004 [Page 4] Internet-Draft SSH Protocol Assigned Numbers August 2003 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 [SSH-TRANS] SSH_DISCONNECT_ILLEGAL_USER_NAME 15 [SSH-TRANS] 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] 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] Lehtinen & Moffat Expires February 13, 2004 [Page 5] Internet-Draft SSH Protocol Assigned Numbers August 2003 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. 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] 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] 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] Lehtinen & Moffat Expires February 13, 2004 [Page 6] Internet-Draft SSH Protocol Assigned Numbers August 2003 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] 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. 4.1 Encryption Algorithm Names Cipher name Reference ------------ --------- 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] Lehtinen & Moffat Expires February 13, 2004 [Page 7] Internet-Draft SSH Protocol Assigned Numbers August 2003 des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS 46-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] 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] 4.4 Compression Algorithm Names Algorithm name Reference --------------- --------- none [SSH-TRANS, Section 4.2] zlib [SSH-TRANS, Section 4.2] References [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- ietf-architecture-14.txt, July 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-16.txt, July 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- ietf-userauth-17.txt, July 2003. Lehtinen & Moffat Expires February 13, 2004 [Page 8] Internet-Draft SSH Protocol Assigned Numbers August 2003 [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- ietf-connect-17.txt, July 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft-ietf-secsh-assignednumbers- 03.txt, July 2003. [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 Sun Microsystems 901 San Antonio Road Palo Alto 94303 USA EMail: Darren.Moffat@Sun.COM Lehtinen & Moffat Expires February 13, 2004 [Page 9] Internet-Draft SSH Protocol Assigned Numbers August 2003 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 assigns. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Lehtinen & Moffat Expires February 13, 2004 [Page 10] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 17:25:49 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 RAA14732 for ; Fri, 15 Aug 2003 17:25:47 -0400 (EDT) Received: (qmail 19861 invoked by uid 605); 15 Aug 2003 21:21:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19843 invoked from network); 15 Aug 2003 21:21:27 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 15 Aug 2003 21:21:27 -0000 Received: by ietf.org (8.9.1a/8.9.1a) id RAA14618; Fri, 15 Aug 2003 17:21:20 -0400 (EDT) Date: Fri, 15 Aug 2003 17:21:20 -0400 (EDT) Message-Id: <200308152121.RAA14618@ietf.org> To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-assignednumbers-04.txt References: In-Reply-To: X-URL: http://www.ietf.org/ Reply-to: nsyracus@ietf.org Subject: Autoreply from Internet Draft Submission Manager From: ietfauto@ietf.org (Internet Draft Submission Manager) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Greetings: This message is being sent to acknowledge receipt of your Internet-Draft submission or message to internet-drafts@ietf.org. If you submitted an Internet-Draft, then it will be posted on the Internet-Drafts page of the IETF Web site, and an I-D Action message will be sent to the IETF Announcement List. Please note that all Internet-Drafts offered for publication as RFCs must conform to the requirements specified in ID Nits (http://www.ietf.org/ID-nits.html) or they will be returned to the author(s) for revision. Therefore, the IETF Secretariat strongly recommends that you address all of the issues raised in this document before submitting a request to publish your Internet-Draft to the IESG. The IETF Secretariat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 15 20:02: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 UAA18359 for ; Fri, 15 Aug 2003 20:02:05 -0400 (EDT) Received: (qmail 3067 invoked by uid 605); 16 Aug 2003 00:02:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3060 invoked from network); 16 Aug 2003 00:02:05 -0000 Received: from intra.cyclades.com (64.186.161.6) by mail.netbsd.org with SMTP; 16 Aug 2003 00:02:04 -0000 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 990E622EF15 for ; Fri, 15 Aug 2003 17:01:43 -0700 (PDT) Received: from cyclades.com (unknown [192.168.46.189]) by intra.cyclades.com (Postfix) with ESMTP id 6CFF422EEDD for ; Fri, 15 Aug 2003 20:01:43 -0400 (EDT) Message-ID: <3F3D7459.AE266F1@cyclades.com> Date: Fri, 15 Aug 2003 17:01:29 -0700 From: Ivan Passos Organization: Cyclades Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: <200308140204.h7E2428Q001235@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > > Kermit software has supported since the early 80s both a Short Break and > > Long Break. A break less than 300ms is short; a break greater than > > 700ms is long. These due have meanings for some modems and some > > terminal servers. > > I assume there's also a minimal length for "short break". A serial break is defined as the assertion of the TxD signal to '0' (Space) for a period longer than a character time. So, for 9600 bps, the minimal break length would be: 1 / 9600 x (8 data + 1 start + 1 stop) = 1ms For 115200bps, the minimal break lentgh would then be 87us (!!!). So, to guarantee the serial break works in _any_ baud rate, communication programs usually define the break length as larger than any baud rate possibly used. Since in the old, old, old days people actually used 50bps as a valid baud rate, then the minimal "universal" break would have to be larger than 200ms. That's where the 300ms definition in Kermit came from. And yes, some UARTs are capable of detecting the break length (not just the break condition) and differentiate between short breaks and long breaks. There is no standard as to what exact length makes a break short or long. Sorry if this has been just boring, useless information, but I thought I should mention it. :o) Later, -- Ivan Passos Phone: 510-771-6202 Product Marketing Manager Cell: 510-468-3515 Cyclades Corporation Fax: 510-771-6200 ivan.passos@cyclades.com http://www.cyclades.com "Everywhere with Linux" From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 16 12:15: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 MAA14101 for ; Sat, 16 Aug 2003 12:15:54 -0400 (EDT) Received: (qmail 28717 invoked by uid 605); 16 Aug 2003 16:15:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28320 invoked from network); 16 Aug 2003 16:15:29 -0000 Received: from above.proper.com (208.184.76.39) by mail.netbsd.org with SMTP; 16 Aug 2003 16:15:29 -0000 Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GGFRqu010922 for ; Sat, 16 Aug 2003 09:15:28 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sat, 16 Aug 2003 09:16:33 -0700 To: ietf-ssh@NetBSD.org From: Paul Hoffman / VPNC Subject: Session_id in SSH? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ietf-ssh-owner@NetBSD.org Precedence: list Greetings again. I'm trying to figure out the key exchange in SSH from reading secsh-transport-16 and have hit a roadblock. Section 5.2 has you doing hashes over strings that include "session_id", but that is never defined in the document. The text in the first paragraph of 5.2 says: 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 sounds like session_id and H are the same thing, but that makes no sense when looking at the contents of the hashed strings. Why would you include the contents of "H" twice? Any help would be appreciated. --Paul From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 16 19:18:25 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 TAA21000 for ; Sat, 16 Aug 2003 19:18:24 -0400 (EDT) Received: (qmail 8652 invoked by uid 605); 16 Aug 2003 23:18:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8642 invoked from network); 16 Aug 2003 23:18:18 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 16 Aug 2003 23:18:18 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa21904; 16 Aug 2003 19:17 EDT Date: Sat, 16 Aug 2003 19:17:59 -0400 From: Jeffrey Hutzelman To: Paul Hoffman / VPNC , ietf-ssh@NetBSD.org Subject: Re: Session_id in SSH? Message-ID: <291210000.1061075879@minbar.fac.cs.cmu.edu> In-Reply-To: References: 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 Saturday, August 16, 2003 09:16:33 -0700 "Paul Hoffman / VPNC" wrote: > Greetings again. I'm trying to figure out the key exchange in SSH from > reading secsh-transport-16 and have hit a roadblock. Section 5.2 has you > doing hashes over strings that include "session_id", but that is never > defined in the document. > > The text in the first paragraph of 5.2 says: > 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 sounds like session_id and H are the same thing, but that makes no > sense when looking at the contents of the hashed strings. Why would you > include the contents of "H" twice? "H" is the exchange hash resulting from the key exchange just completed, and is used to tie the encryption keys to the key exchange, and thus to the host authentication. It changes each time key exchange is performed (that is, during every rekey operation) "session_id" is the exchange hash resulting from the _first_ key exchange on a given session. For that first exchange, it is the same as "H", but unlike "H", the "session_id" does not change during a rekey. It is used to tie authentication operations to a particular session. I believe the first paragraph of section 5.2 spells this out, but it might be a little less clear than it could be about the distinction. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 18 11:14: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 LAA22306 for ; Mon, 18 Aug 2003 11:14:54 -0400 (EDT) Received: (qmail 29352 invoked by uid 605); 18 Aug 2003 15:14:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29345 invoked from network); 18 Aug 2003 15:14:53 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 18 Aug 2003 15:14:53 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22293; Mon, 18 Aug 2003 11:14:47 -0400 (EDT) Message-Id: <200308181514.LAA22293@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-04.txt Date: Mon, 18 Aug 2003 11:14:47 -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 Protocol Assigned Numbers Author(s) : S. Lehtinen, D. Moffat Filename : draft-ietf-secsh-assignednumbers-04.txt Pages : 10 Date : 2003-8-18 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-04.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-04.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-04.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-8-18112822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-18112822.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 18 12:01: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 MAA24906 for ; Mon, 18 Aug 2003 12:01:01 -0400 (EDT) Received: (qmail 24699 invoked by uid 605); 18 Aug 2003 16:01:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24690 invoked from network); 18 Aug 2003 16:01:01 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 18 Aug 2003 16:01:00 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7IG0rD7008247; Mon, 18 Aug 2003 09:00:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7IG0rtK027780; Mon, 18 Aug 2003 12:00:53 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7IG0rD9002116; Mon, 18 Aug 2003 12:00:53 -0400 (EDT) Message-Id: <200308181600.h7IG0rD9002116@thunk.east.sun.com> From: Bill Sommerfeld To: Steve Suehring cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt In-Reply-To: Your message of "Fri, 15 Aug 2003 12:56:10 CDT." <20030815175610.GA14087@mail.braingia.org> Reply-to: sommerfeld@east.sun.com Date: Mon, 18 Aug 2003 12:00:53 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I guess I'm just not sure if we need to get more specific about the port. > In looking at RFC 2396, "If the port is omitted, the default port number > is assumed." The wording as it stands in the draft is "If the port is not > included, port 22 is assumed." Therefore, should we just change it to: > "If the port is not included, the default port is assumed."? I personally > like it as is with the specific port included, but I'm not against > changing it. one alternate wording making it clear this document isn't inventing anything: "if the port is not included, the default port (22) is assumed" However, the ssh clients I'm familiar with generally include the ability to have a local configuration override which can replace both port number and ip address on a host-by-host basis -- this does throw something of a monkey wrench into the mix. In the past, I've used this to good effect (in combination with other kludgy bits of duct tape and bailing wire) to work around connectivity abnormalities of various sorts.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 19 18:52: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 SAA14331 for ; Tue, 19 Aug 2003 18:52:12 -0400 (EDT) Received: (qmail 2030 invoked by uid 605); 19 Aug 2003 22:52:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2023 invoked from network); 19 Aug 2003 22:52:07 -0000 Received: from firebird.cisco.com (HELO fire.cisco.com) (171.68.227.73) by mail.netbsd.org with SMTP; 19 Aug 2003 22:52:07 -0000 Received: from REMAKERW2K (remaker-w2k.cisco.com [171.69.103.51]) by fire.cisco.com (8.11.7+Sun/8.8.8) with SMTP id h7JMq7O24086; Tue, 19 Aug 2003 15:52:07 -0700 (PDT) Message-ID: <058901c366a4$83b717b0$336745ab@amer.cisco.com> From: "Phillip Remaker" To: Cc: Subject: BREAK OVER SSH: draft-ietf-secsh-break-02 Date: Tue, 19 Aug 2003 15:52:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I submit for your comments the second (third? Did we start at zero?) draft of "break over SSH." - Split normative/non-normative references - Added verbage on cascaded connections and dealing with BREAK on psuedo-ttys - Added a brief security considerations section. - Updated references to latest SSH drafts. Also, does anyone have a good, normative reference on the definition of a physical BREAK signal? It doesn't seem to show in any ITU docs, but I did point to a good website that treats the issue comprehensively as an Informative reference. (Does mailing to the list constitute an official submission? Or are there more steps I need to take?) -------------------------------------------------- Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: February 17, 2004 P. Remaker Cisco Systems, Inc August 19, 2003 Session Channel Break Extension draft-ietf-secsh-break-02.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 February 17, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Session Channel Break Extension provides a means to send a BREAK signal [2] over an SSH terminal session [5]. Galbraith & Remaker Expires February 17, 2004 [Page 1] Internet-Draft Session Channel Break Extension August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Break Request . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 Informative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . 9 Galbraith & Remaker Expires February 17, 2004 [Page 2] Internet-Draft Session Channel Break Extension August 2003 1. Introduction The SSH session channel provides a mechanism for the client-user to interactively enter commands and receive output from a remote host while taking advantage of the SSH transport's privacy and integrity features. SSH is increasingly being used to replace telnet for terminal access applications. A common application of the telnet protocol is the "Console Server" [2] whereby a telnet NVT can be connected to a physical RS-232/V.24 asynchronous port, making the telnet NVT appear as a locally attached terminal to that port, and making that physical port appear as a network addressable device. A number of major computer equipment vendors provide high level administrative functions through an asynchronous serial port and generally expect the attached terminal to be capable of send a BREAK signal. A BREAK signal is defined as the TxD signal being held in a SPACE ("0") state for a time greater than a whole character time. In practice, a BREAK signal is typically 250 to 500 ms in length. The telnet protocol furnishes a means to send a "BREAK" signal, which RFC0854 defines as a "a signal outside the USASCII set which is currently given local meaning within many systems." [1] Console Server vendors interpret the TELNET BREAK signal as a physical BREAK signal, which can then allow access to the full range of adminisrative functions available on an asynchronous serial console port. The lack of a similar facility in the SSH session channel has forced users to continue the use of telnet for the "Console Server" function. Galbraith & Remaker Expires February 17, 2004 [Page 3] Internet-Draft Session Channel Break Extension August 2003 2. The Break Request The following following channel specific request can be sent to request that the remote host perform a BREAK operation. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "break" boolean want_reply uint32 break-length in milliseconds If the BREAK length cannot be controlled by the application receiving this request, the BREAK length parameter SHOULD be ignored and the default BREAK signal length of the chipset or underlying chipset driver SHOULD be sent. If the application receiving this request can control the BREAK-length, the following suggestions are made regarding BREAK duration. If a BREAK duration request of greater than 3000ms is received, it SHOULD be processed as a 3000ms BREAK, in order to prevent an unreasonably long BREAK request causing the port to become unavailable for as long as 49.7 days while executing the BREAK. Applications that require a longer BREAK may choose to ignore this requirement. If BREAK duration request of less than 500ms, is requested a BREAK of 500ms SHOULD be sent since most devices will recognize a BREAK of that length. In the event that an application needs a shorter BREAK, this suggestion can be ignored. If the BREAK-length parameter is 0, the BREAK SHOULD be sent as 500ms or the default BREAK signal length of the chipset or underlying chipset driver. If the SSH connection does not terminate on a physical serial port, the BREAK indication SHOULD be handled in an implementation-defined manner consistent with the general use of BREAK as an attention/ interrupt signal; for instance, a service processor could use some other out-of-band facility to get the attention of a system it manages. In a case where an SSH connection cascades to another connection, the BREAK SHOULD be passed along the cascaded connection. For example, a telnet session from an SSH shell should carry along an SSH initiated BREAK and an SSH client initited from a telnet connection SHOULD pass a BREAK indication from the telnet connection. If the want_reply boolean is set, the server MUST reply using SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [5] messages. If a BREAK of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be sent. If no BREAK was preformed, SSH_MSG_CHANNEL_FAILURE MUST be Galbraith & Remaker Expires February 17, 2004 [Page 4] Internet-Draft Session Channel Break Extension August 2003 sent. This operation SHOULD be supported by any general purpose SSH client. Galbraith & Remaker Expires February 17, 2004 [Page 5] Internet-Draft Session Channel Break Extension August 2003 3. Security Considerations Many computer systems treat serial consoles as local and secured, and interpret a BREAK signal as an instruction to halt execution of the operating system or to enter priviliged configuration modes. Because of this, extra care should be taken to ensure that SSH access to BREAK-enabled ports are limited to users with appropriate priviliges to execute such functions. Alternatively, support for the BREAK facility MAY be imlemented configurable or a per port or per server basis. Implementations that literally intepret the BREAK length parameter without imposing the suggested BREAK time limit may cause a denial of service to or unexpected results from attached devices receiving the very long BREAK signal. Galbraith & Remaker Expires February 17, 2004 [Page 6] Internet-Draft Session Channel Break Extension August 2003 Normative References [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. Galbraith & Remaker Expires February 17, 2004 [Page 7] Internet-Draft Session Channel Break Extension August 2003 Informative References [2] Harris, D., "Greater Scroll of Console Knowledge", April 2003. [3] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-14 (work in progress), July 2003. [4] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-16 (work in progress), July 2003. [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-17 (work in progress), July 2003. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Phillip Remaker Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95120 US EMail: remaker@cisco.com Galbraith & Remaker Expires February 17, 2004 [Page 8] Internet-Draft Session Channel Break Extension August 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. 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. 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 Galbraith & Remaker Expires February 17, 2004 [Page 9] Internet-Draft Session Channel Break Extension August 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Remaker Expires February 17, 2004 [Page 10] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 20 11:04:47 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 LAA12584 for ; Wed, 20 Aug 2003 11:04:47 -0400 (EDT) Received: (qmail 9611 invoked by uid 605); 20 Aug 2003 15:04:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9604 invoked from network); 20 Aug 2003 15:04:46 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 20 Aug 2003 15:04:46 -0000 Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 83DD667114; Wed, 20 Aug 2003 11:32:59 -0400 (EDT) Date: Wed, 20 Aug 2003 11:04:37 -0400 Subject: Re: BREAK OVER SSH: draft-ietf-secsh-break-02 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Phillip Remaker" From: RJ Atkinson In-Reply-To: <058901c366a4$83b717b0$336745ab@amer.cisco.com> Message-Id: <9DB9E6CA-D31F-11D7-8BC5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, Aug 19, 2003, at 18:52 America/Montreal, Phillip Remaker wrote: > (Does mailing to the list constitute an official submission? Or are > there > more steps I need to take?) Official submissions are sent to . The IETF Secretariat folks will, when time permits, then publish the submitted I-D to the online I-D archives. I-D submissions that have the approval of the WG Chair should have a filename of draft-ietf-secsh-*.txt. Individual proposals should have a filename of draft--*.txt. Normally, stuff starts off as an individual proposal, then becomes a WG official document later on after some WG discussion. (I'm copying the whole list since others probably wonder about the same questions.) Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 20 12:58: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 MAA19546 for ; Wed, 20 Aug 2003 12:58:32 -0400 (EDT) Received: (qmail 12029 invoked by uid 605); 20 Aug 2003 16:58:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12022 invoked from network); 20 Aug 2003 16:58:35 -0000 Received: from intra.cyclades.com (64.186.161.6) by mail.netbsd.org with SMTP; 20 Aug 2003 16:58:35 -0000 Received: from intra.cyclades.com (localhost.localdomain [127.0.0.1]) by intra.cyclades.com (Postfix) with SMTP id 1EECC22F0FE; Wed, 20 Aug 2003 09:56:13 -0700 (PDT) Received: from cyclades.com (unknown [192.168.46.189]) by intra.cyclades.com (Postfix) with ESMTP id D38C422F328; Wed, 20 Aug 2003 12:56:08 -0400 (EDT) Message-ID: <3F43A828.9638070F@cyclades.com> Date: Wed, 20 Aug 2003 09:56:08 -0700 From: Ivan Passos Organization: Cyclades Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Phillip Remaker Cc: ietf-ssh@NetBSD.org, galb-list@vandyke.com Subject: Re: BREAK OVER SSH: draft-ietf-secsh-break-02 References: <058901c366a4$83b717b0$336745ab@amer.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello, Phil! Phillip Remaker wrote: > > Also, does anyone have a good, normative reference on the definition of a > physical BREAK signal? It doesn't seem to show in > any ITU docs, but I did point to a good website that treats the issue > comprehensively as an Informative reference. Where is the pointer to that web site?? I couldn't find it in the draft you attached to your original msg. Did you send it in some other msg?? Anyhow, I would guess that the EIA-232E standard document has the formal definition of a BREAK signal. However, I tried to find that document through the 'Net to no avail (the company who sells EIA standards -- Global Engineering Documents, at the Information Handling Services (IHS) , http://global.ihs.com/ -- doesn't seem to have it in their EIA section ... :-/ ...). I know this is not worth much, but I can assure you that the definition I provided earlier is correct. :)) That is: a serial BREAK is the assertion of the TxD signal to '0' (Space) for a period longer than a character time. Hope this helps!! Later, -- Ivan Passos Phone: 510-771-6202 Product Marketing Manager Cell: 510-468-3515 Cyclades Corporation Fax: 510-771-6200 ivan.passos@cyclades.com http://www.cyclades.com "Everywhere with Linux" From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 20 13:02: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 NAA19861 for ; Wed, 20 Aug 2003 13:02:36 -0400 (EDT) Received: (qmail 14213 invoked by uid 605); 20 Aug 2003 17:02:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14206 invoked from network); 20 Aug 2003 17:02:39 -0000 Received: from mail.braingia.org (HELO netserver.braingia.org) (65.169.213.77) by mail.netbsd.org with SMTP; 20 Aug 2003 17:02:39 -0000 Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10]) by netserver.braingia.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h7KH2Mnt012445 for ; Wed, 20 Aug 2003 12:02:27 -0500 Received: (from suehring@localhost) by netserver.braingia.org (8.12.3/8.12.3/Debian-6.4) id h7KH2GYl012410 for ietf-ssh@netbsd.org; Wed, 20 Aug 2003 12:02:16 -0500 Date: Wed, 20 Aug 2003 12:02:16 -0500 From: Steve Suehring To: ietf-ssh@NetBSD.org Subject: secsh-sftp-scp-uri draft Message-ID: <20030820170216.GB10505@mail.braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hello, Based on the emails over the past week, Joe and I (mostly Joe) have compiled a list of the issues and nits that need to be addressed with the secsh-sftp-scp-uri draft so that we can redraft. 1. Default port issue Status: Proposed change- "If the port is not included, the default port (22) is assumed." 2. Specifying ciphers etc as parameters Status: Looking for consensus. 3. More formal SCP SFTP URL definition Status: Looking for consensus. 4. Multiple host key algorithms and fingerprints Status: Looking for consensus. 5. Security considerations in trusted vs. untrusted URLS Status: I'll be revisiting the security considerations section but I'm wary of a slippery slope here. 6. Nits Status: Simon Tatham had some nits that I'll be addressing and I'll probably find others as well. ABNF references, for a reminder to me. If there are other issues outstanding, please let me know. Steve From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 20 14:01: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 OAA26084 for ; Wed, 20 Aug 2003 14:01:55 -0400 (EDT) Received: (qmail 13854 invoked by uid 605); 20 Aug 2003 18:01:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13847 invoked from network); 20 Aug 2003 18:01:56 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 20 Aug 2003 18:01:56 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id EB7447FD67; Wed, 20 Aug 2003 21:01:46 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id E8E927FD07; Wed, 20 Aug 2003 21:01:46 +0300 (EEST) Date: Wed, 20 Aug 2003 21:01:46 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@NetBSD.org Cc: Steve Suehring Subject: Re: secsh-sftp-scp-uri draft In-Reply-To: <20030820170216.GB10505@mail.braingia.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hello, My few cents: On Wed, 20 Aug 2003, Steve Suehring wrote: > 1. Default port issue > > Status: Proposed change- "If the port is not included, the default port > (22) is assumed." Sounds reasonable. > 2. Specifying ciphers etc as parameters I fail to see the need for these. Client already has a list of preferred algorithms and server can dictate use of a specific cipher as the drafts stand. Only place I can find this useful is when server wants to use a cipher not allowed by the default client policy (say, des or none). I'd be very wary allowing such action. Educate me, if I've missed something. [snip] > > 4. Multiple host key algorithms and fingerprints I'd like to see fingerprints removed from the draft. I think it's calling for trouble in a way of man-in-the-middle or impersonation attacks. > 5. Security considerations in trusted vs. untrusted URLS Is there such a thing as trusted URL? I doubt it. Maybe the source can be verified, but there's no validity protection on the URL itself. Consider someone being able to post content on a trusted site. Or an attacker tricking some trusted user to send crafted URL in e-mail. An employee gone bad and sending a malicious URL. It's hard to get it right, and in my opinion, the risks far outweigh the benefits (maybe some anonymous SFTP scheme?). My suggestion: Let the SSH/SCP/SFTP URIs be location pointers, and remove connection parameters altogether. Treat all URIs as 'untrusted' and let SSH handle the decissions over connection setup. Best regards, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 20 17:42:24 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 RAA12925 for ; Wed, 20 Aug 2003 17:42:23 -0400 (EDT) Received: (qmail 27931 invoked by uid 605); 20 Aug 2003 21:42:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27749 invoked from network); 20 Aug 2003 21:42:20 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 20 Aug 2003 21:42:20 -0000 Received: by xanthine.gratuitous.org with local; Wed, 20 Aug 2003 17:42:19 -0400 From: "Joel N. Weber II" To: Steve Suehring CC: ietf-ssh@NetBSD.org In-reply-to: <20030820170216.GB10505@mail.braingia.org> (message from Steve Suehring on Wed, 20 Aug 2003 12:02:16 -0500) Subject: Re: secsh-sftp-scp-uri draft References: <20030820170216.GB10505@mail.braingia.org> Message-Id: Date: Wed, 20 Aug 2003 17:42:19 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > 1. Default port issue > > Status: Proposed change- "If the port is not included, the default port > (22) is assumed." I'd prefer to see something along the lines of ``If the port is not included, the default port that is used when the user does not specify a port is assumed.'' In particular, I would like the text to have the property that if the ssh protocol were changed to support SRV in the future, that ssh URLs would automagically start using SRV records when the port is not specified, without needing to update the URL spec. > 2. Specifying ciphers etc as parameters > > Status: Looking for consensus. I would like to see the URL scheme not provide a way to specify any of the cihper etc parameters that were specified in the original draft, because they facilitate downgrade attacks, and I don't think anyone has argued that they actually would get any value out of using these parameters. > 4. Multiple host key algorithms and fingerprints > > Status: Looking for consensus. I have rather mixed feelings about this. I do think if we are going to support host key fingerprints in URLs at all, we should allow multiple fingerprints to be included, and we should have an explicit algorithm identifier. Are there any implementors who intend to implement the host key fingerprints? Do these implementors have confidence that they can distinguish between trusted and untrusted URLs? (Like, are there any web browsers they're going to interact with that provide enough information to determine this when passing a URL to the ssh client? Or is there a reasonable expectation that browser APIs would gain this functionality?) If https://evil.example.com has a link to ssh://goodguy.example.com where the ssh URL on evil.example.com's webpage has a fingerprint, is that going to make things less secure than if we omit fingerprints from the ssh URL? Do we suspect that there are a non-trivial number of cases where people can deal with getting for their web page an X.509 certificate that is in some useful way certified, but they can't deal with getting an X.509 certificate for their ssh server? (I've seen fas.harvard.edu be an example of being able to deal with X.509 for ``the web'' but not for ssh, but this may be mostly a matter of poor documentation being made available to the sysadmins, along with a lack of support for certificates in at least one popular ssh implementation, although I think the implementation they were using when I was paying attention to this does support certificates. In particular, their helpdesk insisted that I was being too paranoid when I asked them for some way to cryptographically verify their host key. Eventually they sent me completely unauthenticated mail with the fingerprint, but that didn't really solve the problem I cared about the way I wanted it solved.) (Also, I'm handwaving a bit in assuming that the web is always secured using X.509, but at the moment, it basically is; I don't think my web browser will do either krb5 or OpenPGP.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 20 19:09:11 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 TAA18057 for ; Wed, 20 Aug 2003 19:09:10 -0400 (EDT) Received: (qmail 18567 invoked by uid 605); 20 Aug 2003 23:09:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18559 invoked from network); 20 Aug 2003 23:09:08 -0000 Received: from blueberry.cc.columbia.edu (128.59.59.156) by mail.netbsd.org with SMTP; 20 Aug 2003 23:09:08 -0000 Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by blueberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7KN8kh0026411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Aug 2003 19:08:53 -0400 (EDT) Message-ID: <3F43FF7C.5020204@columbia.edu> Date: Wed, 20 Aug 2003 19:08:44 -0400 From: Jeffrey Altman Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phillip Remaker CC: ietf-ssh@NetBSD.org, galb-list@vandyke.com Subject: Re: BREAK OVER SSH: draft-ietf-secsh-break-02 References: <058901c366a4$83b717b0$336745ab@amer.cisco.com> In-Reply-To: <058901c366a4$83b717b0$336745ab@amer.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050101010104080201050205" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms050101010104080201050205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit The following is from the DEC VT100 manual: "BREAK – Typing the BREAK key causes the transmission line to be forced to its zero state for 0.2333 seconds ± 10 percent. If either SHIFT key is down, the time is increased to 3.5 seconds ± 10 percent. Data Terminal Ready is also deasserted during this interval. At the conclusion of the 3.5 second interval Data Terminal Ready will again be asserted. "The SHIFT and BREAK keys typed together provide the long-break-disconnect function. Used with properly configured modems with RS-232-C levels, it will cause both the local and remote data sets to disconnect. For modems that are connected via the 20 mA current loop, issuing the long space may disconnect the remote data set only. "The CTRL and BREAK keys typed together cause the transmission of the answerback message. "The BREAK key does not function when the VT100 is in LOCAL mode." Phillip Remaker wrote: > I submit for your comments the second (third? Did we start at zero?) draft > of "break over SSH." > > - Split normative/non-normative references > - Added verbage on cascaded connections and dealing with BREAK on > psuedo-ttys > - Added a brief security considerations section. > - Updated references to latest SSH drafts. > > Also, does anyone have a good, normative reference on the definition of a > physical BREAK signal? It doesn't seem to show in > any ITU docs, but I did point to a good website that treats the issue > comprehensively as an Informative reference. > > (Does mailing to the list constitute an official submission? Or are there > more steps I need to take?) --------------ms050101010104080201050205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMDgyMDIzMDg0NFowIwYJKoZIhvcNAQkEMRYEFEPqiBMBzVEG 6NXKvr7BCrMo/OMiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAT+ZrVQHPOkyndX/d4nLLSNyiEaIw 49900rB3yHC97ASCdn04DX0rrnXIlHq8QCRTgAzVHB27+jrvj3FS4Sj7kzuNbQ4nLUVLChD8 fH7wajbSGZcjPo6iw8WabrDP8h/ZNrR9ah/79qVLYShJDEGdS6zaD3/Vdec0rzP2bjekytod GRPbVEHrhP6tJVWTwU6PQNWx/jOvbaE9IQe3GyfjMQLcNlqxo7jfcXU1K68SBZEalyeQSErZ UdetdGHuHAfOvO7eE4M+Ttwnr0b7ylxr3O6rAhyxTxtI5u9jlywjOJcTeswSaSHy3jCbTjHD aj/m3A7dxhzat6cY5+RqRI7DxgAAAAAAAA== --------------ms050101010104080201050205-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 01:28:11 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 BAA04510 for ; Thu, 21 Aug 2003 01:28:11 -0400 (EDT) Received: (qmail 26895 invoked by uid 605); 21 Aug 2003 05:28:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26887 invoked from network); 21 Aug 2003 05:28:10 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 21 Aug 2003 05:28:10 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 20 Aug 2003 22:28:10 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7L5S77b023064; Wed, 20 Aug 2003 22:28:08 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.96.116]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Aug 2003 22:32:17 -0700 From: "Joseph Salowey" To: "'Heikki Nousiainen'" , Cc: "'Steve Suehring'" Subject: RE: secsh-sftp-scp-uri draft Date: Wed, 20 Aug 2003 22:28:06 -0700 Message-ID: <004701c367a5$00ba9b00$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 21 Aug 2003 05:32:17.0569 (UTC) FILETIME=[95B8D910:01C367A5] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > > 2. Specifying ciphers etc as parameters > > I fail to see the need for these. Client already has a list > of preferred > algorithms and server can dictate use of a specific cipher as > the drafts > stand. > Only place I can find this useful is when server wants to use > a cipher not > allowed by the default client policy (say, des or none). I'd be > very wary allowing such action. > > Educate me, if I've missed something. > [Joe] I think there is plenty of consensus to remove this from the draft. > > [snip] > > > > 4. Multiple host key algorithms and fingerprints > > I'd like to see fingerprints removed from the draft. I think > it's calling > for trouble in a way of man-in-the-middle or impersonation attacks. > [Joe] Don't think that fingerprints in the URI make these problems any worse. I think they can actually help. If I receive a URL in a signed email from someone that I know I can rely on the fact that the fingerprint is accurate. If I have a web page with a list of SSH URLs that is delivered over a secure connection from a trusted source then the fingerprints in the URIs are very useful. If the finger print doesn't match then I know there is a problem (see below). > > > 5. Security considerations in trusted vs. untrusted URLS > > Is there such a thing as trusted URL? I doubt it. Maybe the > source can be > verified, but there's no validity protection on the URL > itself. Consider > someone being able to post content on a trusted site. >Or an attacker > tricking some trusted user to send crafted URL in e-mail. An > employee gone > bad and sending a malicious URL. > [Joe] You are correct in that trusted URLs do not exists, but trusted sources do. It is entirely possible that a trusted source is compromised, that is why the URL should never overwrite a locally configured fingerprint. If you don't have a locally configured finger print then the URL information is better than nothing at all. However there is probably danger in the automation of the connection. If for example an SSH client by default puts up a message that says "host key for server x is gobble-gobble-gobble and is not in you database do you want to connect?" when invoked without a URL and doesn't put up a message when it is invoked by a URL then there could be a problem since currently there really is no way for the client to know the source of the URL. If the key matches it probably should by default put up a message like "host key for server x is gobble-gobble-gobble and is not in your database, however it matches the fingerprint in the URL, do you want to connect?" Even better if the fingerprint in the URL does not match the host key and there is no locally configured value you can refuse to connect by default "The host key for server x does not match the fingerprint in the URL and is not in the local database so the connection is not allowed." I think this provides value. Perhaps the security considerations should instead give some guidance along these lines. > It's hard to get it right, and in my opinion, the risks far > outweigh the > benefits (maybe some anonymous SFTP scheme?). > > > My suggestion: > Let the SSH/SCP/SFTP URIs be location pointers, and remove connection > parameters altogether. Treat all URIs as 'untrusted' and let > SSH handle the decissions over connection setup. > > > Best regards, > Heikki Nousiainen > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 02:49: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 CAA19720 for ; Thu, 21 Aug 2003 02:49:51 -0400 (EDT) Received: (qmail 15095 invoked by uid 605); 21 Aug 2003 06:49:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15083 invoked from network); 21 Aug 2003 06:49:52 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 21 Aug 2003 06:49:52 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id B03ED1EB70; Thu, 21 Aug 2003 08:49:44 +0200 (CEST) Message-ID: <3F446C1E.6010207@siliconcircus.com> Date: Thu, 21 Aug 2003 08:52:14 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel N. Weber II" Cc: Steve Suehring , ietf-ssh@NetBSD.org Subject: Re: secsh-sftp-scp-uri draft References: <20030820170216.GB10505@mail.braingia.org> In-Reply-To: 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 Joel N. Weber II wrote: >>1. Default port issue >> >>Status: Proposed change- "If the port is not included, the default port >>(22) is assumed." > > > I'd prefer to see something along the lines of ``If the port is not > included, the default port that is used when the user does not specify > a port is assumed.'' In particular, I would like the text to have the > property that if the ssh protocol were changed to support SRV in the > future, that ssh URLs would automagically start using SRV records when > the port is not specified, without needing to update the URL spec. Perhaps "If the port is not included, the port should be as specified in [SSH-TRANS] (section 3.1)"? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 12:07:58 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 MAA11881 for ; Thu, 21 Aug 2003 12:07:57 -0400 (EDT) Received: (qmail 13967 invoked by uid 605); 21 Aug 2003 16:07:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13960 invoked from network); 21 Aug 2003 16:07:52 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 21 Aug 2003 16:07:52 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 19pryW-0004eS-00; Thu, 21 Aug 2003 17:07:48 +0100 Date: Thu, 21 Aug 2003 17:07:48 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Message-ID: <20030821160748.GA15282@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: <015801c361c7$a3058520$0300000a@amer.cisco.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Salowey writes: > [Joel N. Weber II:] > > Is there a good reason to define scp URLs in addition to sftp URLs? > > [Joe] SCP is is use today, we thought it would be useful. How should filenames containing spaces be represented in scp: URLs? Backslashes? The scp "protocol" requires that such filenames be quoted in some unspecified way (often using Unix shell quoting, but presumably server-dependent). IME, with many current clients it's up to the user to know the quoting convention on the particular server. Either the quoting will have to be embedded in URLs (and hence specified), or quoting becomes the client's responsibility and the standardisation of the URL format will not do much to achieve interoperability. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 14:21:12 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 OAA19135 for ; Thu, 21 Aug 2003 14:21:11 -0400 (EDT) Received: (qmail 3840 invoked by uid 605); 21 Aug 2003 18:20:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3807 invoked from network); 21 Aug 2003 18:20:31 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 21 Aug 2003 18:20:31 -0000 Received: by xanthine.gratuitous.org with local; Thu, 21 Aug 2003 14:20:30 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt] Message-Id: Date: Thu, 21 Aug 2003 14:20:30 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I believe this probably should have been sent here, and hasn't yet been. (Also, this way of forwarding probably screws up the MIMEness.) ------- Start of forwarded message ------- To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt Date: Wed, 20 Aug 2003 15:08:16 -0400 - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, J. Van Dyke, C. McClure Filename : draft-galb-secsh-publickey-subsystem-02.txt Pages : 12 Date : 2003-8-20 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 a Shell or a Command''. The subsystem name used with this protocol is 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 a mandatory command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-subsystem-02.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-galb-secsh-publickey-subsystem-02.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-galb-secsh-publickey-subsystem-02.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-8-20114444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-galb-secsh-publickey-subsystem-02.txt - --OtherAccess Content-Type: Message/External-body; name="draft-galb-secsh-publickey-subsystem-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20114444.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of forwarded message ------- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 14:49: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 OAA21769 for ; Thu, 21 Aug 2003 14:49:01 -0400 (EDT) Received: (qmail 21346 invoked by uid 605); 21 Aug 2003 18:49:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21339 invoked from network); 21 Aug 2003 18:49:02 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 21 Aug 2003 18:49:02 -0000 Received: by xanthine.gratuitous.org with local; Thu, 21 Aug 2003 14:49:01 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org In-reply-to: <200308201908.PAA00764@ietf.org> (Internet-Drafts@ietf.org) Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt References: <200308201908.PAA00764@ietf.org> Message-Id: Date: Thu, 21 Aug 2003 14:49:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Under ``2.1 Opening the Public-Key Subsystem'', it is said that clients SHOULD reject a request for this subsystem. I suspect that that should instead be a MUST. Under ``2.2 Requests'', is there a good reason to disallow a client sending more than one request and expecting that the server will respond to them in order? (If there is, I think the draft should probably have a sentence explaining what problem that requirement is solving; if not, pipelined requests should be allowed.) Editorial nitpicking: ``3. Public-Key Subsystem Operations'' says that four requests are defined, including ``command'', but I think ``command'' got absorbed into the key attributes. A case-insensitive grep for ``secsh'' in the core drafts doesn't appear to find any places where the protocol's proper name is ``SECSH''. I believe that ``the Secure Shell protocol'' and ``the SSH protocol'' both appear, though. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 16:05: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 QAA26734 for ; Thu, 21 Aug 2003 16:05:26 -0400 (EDT) Received: (qmail 1523 invoked by uid 605); 21 Aug 2003 20:03:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1516 invoked from network); 21 Aug 2003 20:03:12 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 21 Aug 2003 20:03:12 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7LK3B5q021365 for ; Thu, 21 Aug 2003 13:03:12 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7LK3BtK005070 for ; Thu, 21 Aug 2003 16:03:11 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7LK3BD9007282 for ; Thu, 21 Aug 2003 16:03:11 -0400 (EDT) Message-Id: <200308212003.h7LK3BD9007282@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: draft minutes from IETF57 secure shell meeting. Reply-to: sommerfeld@east.sun.com Date: Thu, 21 Aug 2003 16:03:11 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Send comments/corrections/etc to me by next week.. - Bill Secure Shell WG Meeting - IETF 57 - 7/16/2003 Chair: Bill Sommerfeld Summary of IETF57 Secure Shell WG meeting. The actual meeting was short, mostly largely of document status updates. Attendance was very light. There was brief discussion of open issues with several of the documents. One document is now in the IESG's hands: draft-ietf-secsh-dns-04.txt (SSH key fingerprints in DNS). The core draft update to resolve IESG issues missed publication deadline for this meeting, but editing is now done and the documents should reappear shortly. This will hopefully break the logjam and get the rest of the documents moving. There are few open issues at present -- mostly editorial nits. Starting with this IETF, the AD has requested that I list the actions expected before the next IETF meeting (November 9-14, 2003, in Minneapolis). Expected within next month: [responsible party] Creation of issue tracking database for the WG. [chair] core drafts reissued with revised sec-cons [moffat] draft-ietf-secsh-dh-group-exchange-04.txt [provos/friedl] reissued with nit fixed [provos/friedl] to AD for IETF-wide Last Call [chair] core drafts back to IESG review. [chair] Completion of WG last call period on draft-ietf-secsh-gsskeyex-06.txt [jhutz] draft-ietf-secsh-auth-kbdinteract-05.txt [cusack/forssen] Expected before next IETF: Reissue of extensions drafts with WG chair's nits fixed, and run WG last call: draft-ietf-secsh-break-00.txt [galbraith/remaker] draft-ietf-secsh-filexfer-04.txt [galbraith] draft-ietf-secsh-fingerprint-01.txt [friedl] draft-ietf-secsh-publickeyfile-03.txt [galbraith] Discussion and resolution of technical issues with extension drafts: draft-ietf-secsh-agent-01 [lehtinen] Issue: moving keys to root agent vs. moving requests to keys. draft-ietf-secsh-newmodes-00.txt [kohno] Issue: Tweak/prune algorithm list? Discussion of whether to accept individual submissions as WG items: draft-galb-secsh-publickey-subsystem-01.txt [mcclure] Detailed minutes: WG Chair Bill Sommerfeld opened the meeting with the traditional agenda bashing/blue sheet dispersal. Bill said that he sent a flurry of email out last night, saying that he believes most of the documents are ready for the IESG. General items: - WG Chair was busy since the last IETF. - Chair would like to use an issue tracking system (if anyone has preferences, let him know) [Subsequent to this, we adopted RT, at rt.psg.com] - Flurry of notes last night included various nits. Recent active discussions - File Transfer Performance (mostly resolved) - Pipelining the requests - Use large channel windows - GSS Key Exchange Nits - Comments from the document author? (none) General nits for all drafts: - References split (normative/nonnormative) - Claim is that this helps documents move faster once they leave the IESG (this helps out RFC editor). - Security considerations section - Looks REALLY lame if the security area forgets that - IESG has gotten really picky lately. - IANA Considerations sections - ID Nits - see ID-Nits web page - IPR references if made need to follow 2026 - IETF dos not make judgements on IPR claims - BAD: There is a patent/trademark - GOOD: "There may be IPR claims" Core Drafts: - Bounced from IESG for security considerations work - Revised sections drafted and last-called - Just missed deadline for this IETF (DSL failure delayed them) - All five sent out late Monday (one bounced, will be resent) - One more nit found (X11 cookies) - Will be sent to IESG once remaining items are cleaned up. draft-ietf-secsh-dns-04.txt - Survived IETF-wide Last Call - Stuck somewhere in IESG - unjammed by AD Other extensions drafts revised to fix nits: Keyboard-interactive - Now has a security-considerations section - Started WGLC last night GSSAPI - Started WGLC DH Group Exchange - Lost somewhere in the wash before last IETF - Needed references split, done by authors Still in need of revisions: Public key file format - missing security considerations SSH Fingerprint Format Agent Forwarding - Should be implementable, and the usual nits File Transfer - Usual nits, and vaguer IPR text Issue tracking: Several systems out there being used successfully: - Bugzilla (Chair believes that is too complex) - RT (run by Randy Bush) - Roundup - Seems to use termology that matches IETF process, might be worth a closer look Strong options/preferences, please notify WG chair. Jeff Hutzelman: Noted that KRB-WG tried to use RT for issue tracking, and we fell flat on our face. Needs strong direction from WG leadership Sam H: Note that if your process is already working, an issue tracker may slow you down. Paul Hoffman: In IPsec, one person controls the issue tracker, instead of document authors, and it works well. Bill notes that part of the motivation is to give him a list of things to bug document authors. New modes/transport fixes: - draft-ietf-secsh-newmodes-00.txt - Submitted by Tadayoshi Kohno (tkohno@cs.ucsd.edu) - Usual nits, needs a respin - Opinions of working group: Should we go this way? (lots of algorithms versus few). WG members should send comments to the list. Jeff Hutzelman notes that a lot of algorithms are recommended: do we really need all of them? GSSAPI: Document author thinks it's done, so WGLC has been started. Significant keyex discussion (claimed problems with gss-keyex negotiation and keyex and in general). Jeff H: Admits that he's been lame and hasn't followed the discussion. Bill: Sounds like a task for Jeff for next time. File Transfer: Significant discussion of performance problems; seems like that's been resolved, so this is getting close. Agent forwarding: If you do agent forwarding to a remote host, it pushes the long-term public key to the remote system. Draft is silent on this issue. Bill says at the very least the draft should talk about this issue. "Please send draft": X509/PKIX support: Steve Hanna Line mode - Thor Simon Performance analysis - Bill Squier With no further comments, Bill closed the meeting. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 21 16:22: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 QAA27700 for ; Thu, 21 Aug 2003 16:22:36 -0400 (EDT) Received: (qmail 12574 invoked by uid 605); 21 Aug 2003 20:22:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12565 invoked from network); 21 Aug 2003 20:22:38 -0000 Received: from www.isc.netbsd.org (HELO narn.netbsd.org) (204.152.185.215) by mail.netbsd.org with SMTP; 21 Aug 2003 20:22:38 -0000 Received: from onmo1737.com (host-216-252-167-246.interpacket.net [216.252.167.246]) by narn.netbsd.org (Postfix) with SMTP id 4490211153 for ; Thu, 21 Aug 2003 20:22:32 +0000 (UTC) From: "Vincent Bongo" Reply-To: vince@idncafe.com To: ietf-ssh@NetBSD.org Date: Mon, 21 Aug 2006 20:22:55 +0000 Subject: I Need Your Co-operation X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <20030821202232.4490211153@narn.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Dear=2C My name is Vincent Bongo=2C a Ghanaian and i work as an Administrative Secretary with Global Security Company Ltd=2C Accra Ghana=2E I decided to contact you believing that by the grace of God you will be my partner in this business which i am about to introduce to you=2E I have worked with this company for nine years and within this period=2Ci watched with meticulous precision on how some African Heads of States and government functionaries have been moving huge sums of money to their foreign partners=2E They bring in these consignments of cash and secretly declare the content as Family Treasure or Documents etc=2E These people have consignments deposited with our company and their foreign partners=2C relatives and next of kins are claiming most of these consignment and a lot more are lying here unclaimed for as much as 7 years=2E Since the inception of the year 2001=2C Global Security Company Ltd Management changed the procedure of claiming of consignments=2E As soon as one is able to produce all the secret information as contained in the secret file of the company as regard to a particular consignment=2C it will be released to you upon demand=2E We have a consignment belonging to Mr=2E Francis Carden a Zimbabwean=2C who was a campaign manager for President Robert Mugabe during his re-election campaign in 1999=2E Mr=2E F=2E Carden deposited a consignment early last year 2001 after he absconded with =28$7=2EmUSD=29=2E Unfortunately=2C Mr=2E Francis Carden died in the Terrorist attack that hit the world trade centre=2ESince his death=2C no one knows about this transaction with our company Global Security Company Ltd=2E Now i want you to claim the consignment as the next of Kin to Mr=2E Francis Carden=2E If you can handle this project i will give you every detailed information as regard the consignment=2EI will suggest upon conclusion=2C that we share the money 60%-40%=2E More also you will make an arrangement on investing my share in your country for me=2EI assure you that this business is very secured and risk free=2E I'm looking forward to your reply=2E Yours sincerely=2C Vincent Bongo From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 00:12: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 AAA19376 for ; Fri, 22 Aug 2003 00:12:27 -0400 (EDT) Received: (qmail 15831 invoked by uid 605); 22 Aug 2003 04:10:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15824 invoked from network); 22 Aug 2003 04:10:16 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 22 Aug 2003 04:10:16 -0000 Received: from vger.corp.google.com (vger.corp.google.com [10.32.60.132]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h7M4ADGg029835; Thu, 21 Aug 2003 21:10:13 -0700 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id h7M4AD725372; Thu, 21 Aug 2003 21:10:13 -0700 Date: Thu, 21 Aug 2003 21:10:13 -0700 From: Frank Cusack To: openssh-unix-dev@mindrot.org, ietf-ssh@NetBSD.org Subject: Re-using RSA1 keys as RSA Message-ID: <20030821211013.B25360@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is there a security issue with turning an RSA1 key into an RSA key? One might want to do this, e.g., to move to protocol 2 without having to update authorized_keys files. I thought there was a problem with this, but Google doesn't find anything. thanks /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 01:39:12 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 BAA22546 for ; Fri, 22 Aug 2003 01:39:11 -0400 (EDT) Received: (qmail 2127 invoked by uid 605); 22 Aug 2003 05:39:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2113 invoked from network); 22 Aug 2003 05:39:11 -0000 Received: from dsl081-064-164.sfo1.dsl.speakeasy.net (HELO hackerdojo.com) (64.81.64.164) by mail.netbsd.org with SMTP; 22 Aug 2003 05:39:11 -0000 Received: from doxpara.com (fire [127.0.0.1]) by hackerdojo.com (Postfix) with ESMTP id A922A83A25; Thu, 21 Aug 2003 21:54:11 -0700 (PDT) Message-ID: <3F45AC7B.40808@doxpara.com> Date: Thu, 21 Aug 2003 23:39:07 -0600 From: Dan Kaminsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Frank Cusack Cc: openssh-unix-dev@mindrot.org, ietf-ssh@NetBSD.org Subject: Re: Re-using RSA1 keys as RSA References: <20030821211013.B25360@google.com> In-Reply-To: <20030821211013.B25360@google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Frank Cusack wrote: >Is there a security issue with turning an RSA1 key into an RSA key? One >might want to do this, e.g., to move to protocol 2 without having to >update authorized_keys files. > >I thought there was a problem with this, but Google doesn't find anything. > >thanks >/fc > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev@mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > It's been a while since I went over this, but I believe the reason you can't do this is: SSHv1 uses RSA keys for encryption -- I send you data encrypted with your pubkey, you send it back to me decrypted. SSHv2 uses RSA keys for verification -- I send you data, you send it back to me signed, I test to see if the data was signed correctly. There are potential attacks involving the use of one mode against the other. They're not as simple as what I once thought they were; i.e. the private key for decrypting is the public key for verifying -- but I think it was a problem nonetheless. That being said, there really needs to be a mode to check all known host key types for one that matches. This is a _real_ security requirement, people! If we checked the SSHv1 key before accepting a new SSHv2 key, we'd be _alot_ better off for the migrators. --Dan From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 11:32:47 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 LAA03165 for ; Fri, 22 Aug 2003 11:32:46 -0400 (EDT) Received: (qmail 27751 invoked by uid 605); 22 Aug 2003 15:30:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27744 invoked from network); 22 Aug 2003 15:30:52 -0000 Received: from dhcp-fh8-9.it.su.se (HELO nutcracker.stacken.kth.se) (130.237.152.9) by mail.netbsd.org with SMTP; 22 Aug 2003 15:30:52 -0000 Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id 02CA2F3C1E; Fri, 22 Aug 2003 16:06:31 +0200 (CEST) To: ietf-ssh@NetBSD.org Subject: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> From: Love Date: Fri, 22 Aug 2003 16:06:27 +0200 In-Reply-To: <200308212003.h7LK3BD9007282@thunk.east.sun.com> (Bill Sommerfeld's message of "Thu, 21 Aug 2003 16:03:11 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= Content-Transfer-Encoding: quoted-printable I've pointed out this to the authors privatly, so I'll repeat this publicly. I consider gss userauth to be broken since it doesn't verify the session id (using either mic or a channel bindings (like in CCM)). Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (NetBSD) iQEVAwUAP0YjZnW+NPVfDpmCAQLhtgf+JlgS+9CxATXsiqLS7z27LCmTv5oMQGRB WBnx78+Ep5ik/sPxYwhBuJV3fpa/XWwX7aFF8JSVwi2I4hDNqTwMYnX5CZE5y4RJ Is41tpMhAGMCREnSZ2ctmNHaVUiUysXTV7sZaxT70n97I2fhjjQNJDVh19RwV9zI JcXcyn7qp4em3ZyFrGFK9MEEy6rQl6eXfsvzR1c2tk50eLx9aOmyMqCU3JjMnkIw plp9dBpX4JIko6grdNYeMOnkpaeauW0h6PlaVhxERVXXzQOOSQLzl8aNo8qeR2lO g4MDxzvLcKEtyUINCfXuM4VWdZSqAxl3eqLi/7SN2VbU2gQhxtkE4g== =9jKv -----END PGP SIGNATURE----- --=-=-=-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 12:48: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 MAA06665 for ; Fri, 22 Aug 2003 12:48:42 -0400 (EDT) Received: (qmail 6604 invoked by uid 605); 22 Aug 2003 16:47:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6597 invoked from network); 22 Aug 2003 16:47:43 -0000 Received: from www.isc.netbsd.org (HELO narn.netbsd.org) (204.152.185.215) by mail.netbsd.org with SMTP; 22 Aug 2003 16:47:43 -0000 Received: from xanthine.gratuitous.org (xanthine.gratuitous.org [199.232.39.35]) by narn.netbsd.org (Postfix) with ESMTP id E111311151 for ; Fri, 22 Aug 2003 16:46:45 +0000 (UTC) Received: by xanthine.gratuitous.org with local; Fri, 22 Aug 2003 12:45:24 -0400 From: "Joel N. Weber II" To: Love Cc: ietf-ssh@NetBSD.org In-reply-to: (message from Love on Fri, 22 Aug 2003 16:06:27 +0200) Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> Message-Id: Date: Fri, 22 Aug 2003 12:45:24 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I've pointed out this to the authors privatly, so I'll repeat this > publicly. I consider gss userauth to be broken since it doesn't verify the > session id (using either mic or a channel bindings (like in CCM)). I'd not previously realized this, having not read that section of the gss spec, but that does appear to me to be true, and I do agree that it is something that should be fixed. (I'm sending this message primarily because my understanding is that ``me toos'' are useful in determining what the working group consensus is.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 13:01:05 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 NAA07189 for ; Fri, 22 Aug 2003 13:01:03 -0400 (EDT) Received: (qmail 13483 invoked by uid 605); 22 Aug 2003 17:01:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13476 invoked from network); 22 Aug 2003 17:01:05 -0000 Received: from www.isc.netbsd.org (HELO narn.netbsd.org) (204.152.185.215) by mail.netbsd.org with SMTP; 22 Aug 2003 17:01:05 -0000 Received: from xanthine.gratuitous.org (xanthine.gratuitous.org [199.232.39.35]) by narn.netbsd.org (Postfix) with ESMTP id 1678311151 for ; Fri, 22 Aug 2003 16:59:55 +0000 (UTC) Received: by xanthine.gratuitous.org with local; Fri, 22 Aug 2003 12:59:26 -0400 From: "Joel N. Weber II" To: Dan Kaminsky Cc: Frank Cusack , openssh-unix-dev@mindrot.org, ietf-ssh@NetBSD.org In-reply-to: <3F45AC7B.40808@doxpara.com> (message from Dan Kaminsky on Thu, 21 Aug 2003 23:39:07 -0600) Subject: Re: Re-using RSA1 keys as RSA References: <20030821211013.B25360@google.com> <3F45AC7B.40808@doxpara.com> Message-Id: Date: Fri, 22 Aug 2003 12:59:26 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > That being said, there really needs to be a mode to check all known host > key types for one that matches. This is a _real_ security requirement, > people! If we checked the SSHv1 key before accepting a new SSHv2 key, > we'd be _alot_ better off for the migrators. 1) That's only really true if most people haven't already migrated. I think it's been a year since I was really making significant use of sshv1; everything that really matters to me has already migrated to sshv2. 2) That's only really true if you have a fix for the habit people develop of reacting to the MitM attack warning by deleting the relevant known_hosts entries. (To some extent, there is also a sysadmin behavior problem; if I remember correctly, the sysadmins of one machine I use decided six or eight months ago to change the host key as a result of migrating to a new machine, and didn't send pgp signed mail with the new key when I asked. They also broke my authorized_keys entry, such that I couldn't even do a login that would prevent a man in the middle from forwarding my login to the real machine. But they didn't break my password.) 3) That said, having a mechanism to roll over sshv2 keys to other sshv2 keys more cleanly may well be worth having. I'm thinking something where a client lists the keys it trusts, and if the server has its old private keys, it can sign the session with an old host key, and then use SSH_MSG_HOSTKEYS (once we have that defined; I have a mostly written draft that I should submit real soon now) to send the new host key. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 17:03: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 RAA20369 for ; Fri, 22 Aug 2003 17:03:23 -0400 (EDT) Received: (qmail 2539 invoked by uid 605); 22 Aug 2003 21:03:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2443 invoked from network); 22 Aug 2003 21:03:24 -0000 Received: from mail-in-02.arcor-online.net (151.189.21.42) by mail.netbsd.org with SMTP; 22 Aug 2003 21:03:24 -0000 Received: from localhost.arcor.net (dsl-213-023-025-108.arcor-ip.net [213.23.25.108]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id E7F7C774B7; Fri, 22 Aug 2003 23:12:32 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id E97332D044; Fri, 22 Aug 2003 23:03:07 +0200 (CEST) Date: Fri, 22 Aug 2003 23:03:07 +0200 From: Markus Friedl To: Frank Cusack Cc: openssh-unix-dev@mindrot.org, ietf-ssh@NetBSD.org Subject: Re: Re-using RSA1 keys as RSA Message-ID: <20030822210307.GA25939@folly> References: <20030821211013.B25360@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821211013.B25360@google.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Aug 21, 2003 at 09:10:13PM -0700, Frank Cusack wrote: > Is there a security issue with turning an RSA1 key into an RSA key? One > might want to do this, e.g., to move to protocol 2 without having to > update authorized_keys files. in protocol 1 rsa keys are used for encryption, in protocol 2 they are used for signatures. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 17:27:21 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 RAA21547 for ; Fri, 22 Aug 2003 17:27:21 -0400 (EDT) Received: (qmail 15206 invoked by uid 605); 22 Aug 2003 21:27:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15175 invoked from network); 22 Aug 2003 21:27:23 -0000 Received: from dsl081-064-164.sfo1.dsl.speakeasy.net (HELO hackerdojo.com) (64.81.64.164) by mail.netbsd.org with SMTP; 22 Aug 2003 21:27:23 -0000 Received: from doxpara.com (fire [127.0.0.1]) by hackerdojo.com (Postfix) with ESMTP id 0D6B883A26; Fri, 22 Aug 2003 13:42:24 -0700 (PDT) Message-ID: <3F468AB9.2060108@doxpara.com> Date: Fri, 22 Aug 2003 15:27:21 -0600 From: Dan Kaminsky User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Friedl Cc: Frank Cusack , ietf-ssh@NetBSD.org, openssh-unix-dev@mindrot.org Subject: Re: Re-using RSA1 keys as RSA References: <20030821211013.B25360@google.com> <20030822210307.GA25939@folly> In-Reply-To: <20030822210307.GA25939@folly> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl wrote: >On Thu, Aug 21, 2003 at 09:10:13PM -0700, Frank Cusack wrote: > > >>Is there a security issue with turning an RSA1 key into an RSA key? One >>might want to do this, e.g., to move to protocol 2 without having to >>update authorized_keys files. >> >> > >in protocol 1 rsa keys are used for encryption, >in protocol 2 they are used for signatures. > > Markus-- In protocol 2, the RSA public key verifies a signature, as in protocol 1, a RSA public key encrypts a token. I'm not sure, but the only difference between the two may very well be the source of the token being operated upon -- SSHv1 has the client generate random data; SSHv2 has the server generate and hash it. Either way, client + pubkey authenticates server + privkey. I'm not saying it's safe to dual-purpose RSA; I'm just not entirely sure I've seen evidence it's dangerous to multipurpose the same RSA key. Have you seen any evidence to the contrary? --Dan From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 17:41: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 RAA22284 for ; Fri, 22 Aug 2003 17:41:46 -0400 (EDT) Received: (qmail 25829 invoked by uid 605); 22 Aug 2003 21:41:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25822 invoked from network); 22 Aug 2003 21:41:48 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 22 Aug 2003 21:41:48 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7MLfdPn020351; Fri, 22 Aug 2003 14:41:41 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.80.61]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Aug 2003 14:45:50 -0700 From: "Joseph Salowey" To: "'Joel N. Weber II'" , "'Love'" Cc: Subject: RE: gss userauth Date: Fri, 22 Aug 2003 14:41:38 -0700 Message-ID: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 22 Aug 2003 21:45:50.0598 (UTC) FILETIME=[C1037A60:01C368F6] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I'm in favor of using channel bindings for this purpose. CCM could be one approach to do this. http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt At first glance it seems a little complex, but I need to actaully read the spec. Joe > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Joel N. Weber II > Sent: Friday, August 22, 2003 9:45 AM > To: Love > Cc: ietf-ssh@NetBSD.org > Subject: Re: gss userauth > > > > I've pointed out this to the authors privatly, so I'll repeat this > > publicly. I consider gss userauth to be broken since it > doesn't verify > > the session id (using either mic or a channel bindings > (like in CCM)). > > I'd not previously realized this, having not read that > section of the gss spec, but that does appear to me to be > true, and I do agree that it is something that should be fixed. > > (I'm sending this message primarily because my understanding > is that ``me toos'' are useful in determining what the > working group consensus > is.) > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 19:22: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 TAA27347 for ; Fri, 22 Aug 2003 19:22:51 -0400 (EDT) Received: (qmail 26244 invoked by uid 605); 22 Aug 2003 23:22:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26237 invoked from network); 22 Aug 2003 23:22:52 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 22 Aug 2003 23:22:52 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa29349; 22 Aug 2003 19:22 EDT Date: Fri, 22 Aug 2003 19:22:18 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org cc: "'Love'" Subject: RE: gss userauth Message-ID: <1304330000.1061594538@minbar.fac.cs.cmu.edu> In-Reply-To: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> References: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> 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 Friday, August 22, 2003 14:41:38 -0700 Joseph Salowey wrote: > I'm in favor of using channel bindings for this purpose. > > CCM could be one approach to do this. > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt > > At first glance it seems a little complex, but I need to actaully read > the spec. CCM actually isn't what we want. It's a way of taking an app that uses GSSAPI's integrity and/or encryption features, and a mechanism that provides them, and essentially ripping out the mechanism's authentication and encryption and replacing them with that provided by some lower-layer protocol such as IPsec, on the theory that hardware acceleration is more likely to be available there. We don't need that functionality -- we don't ever use GSSAPI encryption features, and we currently send exactly one integrity-protected message (during key exchange). What we need is a way to bind user authentication to our application protocol's existing cryptographic context, not to some lower-layer protocol. We don't need a special GSS mechanism for that -- all we need to to require the client to send an integrity-protected copy (or checksum) of the exchange hash, just as we do in other user auth mechanisms, and as we do in the reverse direction during key exchange. I can think of two ways of doing this: (1) Use GSSAPI channel bindings. Unfortunately, some mechanisms require bindings to take a particular format, as described in RFC2744 section 3.11. In our case, we would want to use address types of GSS_C_AF_NULLADDR, since we very much do _not_ want to bind this authentication to network protocol addresses (that would gain nothing, and make it not work through NAT's). We could then include the session ID as "application data". (2) Add an additional step in which the client is required to send a MIC of the session ID before authentication can succeed. This is essentially the same as what we do in key exchange, but in the reverse direction. I find myself preferring option (2) for several reasons: - By my reading, RFC2743 does not appear to actually require that GSSAPI mechanisms _do_ anything with channel bindings. A mechanism could just choose to ignore them. - RFC2743 _does_ allow mechanisms to require bindings to take a particular, mechanism-dependent form. It does not specify what the behaviour might be if the provided bindings are not in a format acceptable to the mechanism. - Some mechanism might be unable or unwilling to provide integrity protection for channel bindings, and there is no way for them to signal this to the application. While it may be the case that a mechanism cannot support gss_get_mic, at least there is a flag to indicate that, and we can write appropriate requirements. - Using a separate message means we can maintain some amount of backward compatibility for sites that have already deployed earlier versions of this draft. Particularly, it allows for situations in which the client implements the new message, but the server does not. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 22 20:02: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 UAA29045 for ; Fri, 22 Aug 2003 20:02:54 -0400 (EDT) Received: (qmail 15370 invoked by uid 605); 23 Aug 2003 00:02:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15363 invoked from network); 23 Aug 2003 00:02:54 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 23 Aug 2003 00:02:54 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7N02q8s017233; Fri, 22 Aug 2003 17:02:52 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.80.61]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Aug 2003 17:07:02 -0700 From: "Joseph Salowey" To: "'Jeffrey Hutzelman'" , Cc: "'Love'" Subject: RE: gss userauth Date: Fri, 22 Aug 2003 17:02:50 -0700 Message-ID: <00b601c36909$e52eaf50$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <1304330000.1061594538@minbar.fac.cs.cmu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 23 Aug 2003 00:07:02.0964 (UTC) FILETIME=[7AEFEF40:01C3690A] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi Jeff, Okay, You reminded me of all the reasons why I don't like GSSAPI channel bindings. My only issue with MIC is that it might add an extra round trip. I think that this is outweighed by the fact that MIC would probably lead to more consistent implementations. In any case I agree that we do not want to bind addresses. Joe > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Jeffrey Hutzelman > Sent: Friday, August 22, 2003 4:22 PM > To: ietf-ssh@NetBSD.org > Cc: 'Love' > Subject: RE: gss userauth > > > On Friday, August 22, 2003 14:41:38 -0700 Joseph Salowey > wrote: > > > I'm in favor of using channel bindings for this purpose. > > > > CCM could be one approach to do this. > > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt > > > > At first glance it seems a little complex, but I need to > actaully read > > the spec. > > CCM actually isn't what we want. It's a way of taking an app > that uses > GSSAPI's integrity and/or encryption features, and a mechanism that > provides them, and essentially ripping out the mechanism's > authentication > and encryption and replacing them with that provided by some > lower-layer > protocol such as IPsec, on the theory that hardware > acceleration is more > likely to be available there. We don't need that > functionality -- we don't > ever use GSSAPI encryption features, and we currently send > exactly one > integrity-protected message (during key exchange). > > What we need is a way to bind user authentication to our application > protocol's existing cryptographic context, not to some lower-layer > protocol. We don't need a special GSS mechanism for that -- > all we need to > to require the client to send an integrity-protected copy (or > checksum) of > the exchange hash, just as we do in other user auth > mechanisms, and as we > do in the reverse direction during key exchange. > > I can think of two ways of doing this: > (1) Use GSSAPI channel bindings. Unfortunately, some > mechanisms require > bindings to take a particular format, as described in RFC2744 > section 3.11. > In our case, we would want to use address types of > GSS_C_AF_NULLADDR, since > we very much do _not_ want to bind this authentication to > network protocol > addresses (that would gain nothing, and make it not work > through NAT's). > We could then include the session ID as "application data". > > (2) Add an additional step in which the client is required to > send a MIC of > the session ID before authentication can succeed. This is > essentially the > same as what we do in key exchange, but in the reverse direction. > > I find myself preferring option (2) for several reasons: > - By my reading, RFC2743 does not appear to actually require > that GSSAPI > mechanisms _do_ anything with channel bindings. A mechanism > could just > choose to ignore them. > - RFC2743 _does_ allow mechanisms to require bindings to take > a particular, > mechanism-dependent form. It does not specify what the > behaviour might be > if the provided bindings are not in a format acceptable to > the mechanism. > - Some mechanism might be unable or unwilling to provide integrity > protection for channel bindings, and there is no way for them > to signal > this to the application. While it may be the case that a > mechanism cannot > support gss_get_mic, at least there is a flag to indicate > that, and we can > write appropriate requirements. > - Using a separate message means we can maintain some amount > of backward > compatibility for sites that have already deployed earlier > versions of this > draft. Particularly, it allows for situations in which the client > implements the new message, but the server does not. > > -- Jeff > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 23 00:16: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 AAA07679 for ; Sat, 23 Aug 2003 00:16:05 -0400 (EDT) Received: (qmail 23363 invoked by uid 605); 23 Aug 2003 04:09:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23355 invoked from network); 23 Aug 2003 04:09:52 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 23 Aug 2003 04:09:52 -0000 Received: by xanthine.gratuitous.org with local; Sat, 23 Aug 2003 00:09:46 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org, "'Love'" In-reply-to: <1304330000.1061594538@minbar.fac.cs.cmu.edu> (message from Jeffrey Hutzelman on Fri, 22 Aug 2003 19:22:18 -0400) Subject: Re: gss userauth References: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> <1304330000.1061594538@minbar.fac.cs.cmu.edu> Message-Id: Date: Sat, 23 Aug 2003 00:09:46 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list It is desireable, I think, to avoid increasing the requirements that gss userauth places on gssapi mechanisms. I think having the same requirements as key exchange is very much a good thing. I also think that making it as much like pubkey userauth as possible in terms of what data it signs would probably be a good thing, although pubkey probably signs more random data fields than there is any actual need to sign. I think the crucial key is that the session ID gets signed, and it is probably a good idea to include some other random data so that session key signatures used for different purposes sign different data. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 23 00:16:49 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 AAA07736 for ; Sat, 23 Aug 2003 00:16:49 -0400 (EDT) Received: (qmail 27509 invoked by uid 605); 23 Aug 2003 04:16:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27502 invoked from network); 23 Aug 2003 04:16:51 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 23 Aug 2003 04:16:51 -0000 Received: from mindrot.org (mothra.mindrot.org [203.217.30.82]) by shitei.mindrot.org (Postfix) with ESMTP id 8511827C188; Sat, 23 Aug 2003 14:14:17 +1000 (EST) Message-ID: <3F46EA62.4040905@mindrot.org> Date: Sat, 23 Aug 2003 14:15:30 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: Dan Kaminsky Cc: Markus Friedl , openssh-unix-dev@mindrot.org, Frank Cusack , ietf-ssh@NetBSD.org Subject: Re: Re-using RSA1 keys as RSA References: <20030821211013.B25360@google.com> <20030822210307.GA25939@folly> <3F468AB9.2060108@doxpara.com> In-Reply-To: <3F468AB9.2060108@doxpara.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Dan Kaminsky wrote: > I'm not saying it's safe to dual-purpose RSA; I'm just not entirely > sure I've seen evidence it's dangerous to multipurpose the same RSA > key. Have you seen any evidence to the contrary? You have this backwards, we need evidence that this is safe. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 23 05:59: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 FAA00162 for ; Sat, 23 Aug 2003 05:59:21 -0400 (EDT) Received: (qmail 29055 invoked by uid 605); 23 Aug 2003 09:56:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29048 invoked from network); 23 Aug 2003 09:56:02 -0000 Received: from nutcracker.wtf.stacken.kth.se (HELO nutcracker.stacken.kth.se) (130.237.237.2) by mail.netbsd.org with SMTP; 23 Aug 2003 09:56:02 -0000 Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id 6A460F3C1E; Sat, 23 Aug 2003 11:55:44 +0200 (CEST) To: "Joseph Salowey" , "'Jeffrey Hutzelman'" Cc: Subject: Re: gss userauth References: <00b601c36909$e52eaf50$0200000a@amer.cisco.com> From: Love Date: Sat, 23 Aug 2003 11:55:38 +0200 In-Reply-To: <00b601c36909$e52eaf50$0200000a@amer.cisco.com> (Joseph Salowey's message of "Fri, 22 Aug 2003 17:02:50 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= Content-Transfer-Encoding: quoted-printable "Joseph Salowey" writes: Hi Josepha and Jeff, > Okay, You reminded me of all the reasons why I don't like GSSAPI channel > bindings. My only issue with MIC is that it might add an extra round > trip. I think that this is outweighed by the fact that MIC would > probably lead to more consistent implementations.=20=20 > > In any case I agree that we do not want to bind addresses. I'm fine with that, using GSS_C_AF_NULLADDRs and stuff the session identifier in the application_data fields, the later is what CCM proposes, would work for all mechs that have working channel bindings would save you From=20the extra round trip. But then, channel bindings are useless (for ssh gssuserauth) because they are optional for the gss mechs. If the MIC is set with the last gss exchange packet, you would have 0 or 1 extra packets. 0 in the case where the last exchange packets is from the client and 1 when the last exchange packet is from the server. So I would argue that its not a extra roundtrip, but rather none (with more data) or a half. I would very much like to see mutual auth in the gss userauth layer, but sending MIC from client to server is ok with me. Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (NetBSD) iQEVAwUAP0c6IHW+NPVfDpmCAQIjVwf+MePuYpRptn6Ryz4k7cKqbLmPLcPowENs EkBxldcnZHJZpH5IMISr7VKbUBY16bzC10RWsacthBoXhavhrn23D26kAqja7YJ0 A6I/pB8tcxUaH3Mgx7pkYblrLUxI/LSu0ZEm6WFSXqpIITcURfYoqjSCRWQWY+3U la4JtxIfmwBOluom7weI7cfr/Yp0iBlDm6mxAMuJUSe0zrlJ/YrU/9HSBhpOZ9h3 bm549cfCVLWM0e9yb1qj3Wc+H8uZk3WS6ge+X6orqutukOig1PBHnduvl4aqLSDY aqfH0qwn1D9q4e0zG/WydgpMxSKBukIMU5raU33ZR6nZkFYhX+BP3w== =MV65 -----END PGP SIGNATURE----- --=-=-=-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 23 07:55: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 HAA04134 for ; Sat, 23 Aug 2003 07:55:32 -0400 (EDT) Received: (qmail 22243 invoked by uid 605); 23 Aug 2003 11:55:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22236 invoked from network); 23 Aug 2003 11:55:31 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 23 Aug 2003 11:55:31 -0000 Received: by xanthine.gratuitous.org with local; Sat, 23 Aug 2003 07:55:26 -0400 From: "Joel N. Weber II" To: Love CC: "Joseph Salowey" , "'Jeffrey Hutzelman'" , In-reply-to: (message from Love on Sat, 23 Aug 2003 11:55:38 +0200) Subject: Re: gss userauth References: <00b601c36909$e52eaf50$0200000a@amer.cisco.com> Message-Id: Date: Sat, 23 Aug 2003 07:55:26 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > If the MIC is set with the last gss exchange packet, you would have 0 or 1 > extra packets. 0 in the case where the last exchange packets is from the > client and 1 when the last exchange packet is from the server. So I would > argue that its not a extra roundtrip, but rather none (with more data) or a > half. I think with the way GSSAPI userauth happens to be defined, you can just piggyback the data on this packet that already gets sent anyway, and you never add round trips vs what the protocol already does: byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Aug 23 13:55:14 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 NAA19429 for ; Sat, 23 Aug 2003 13:55:14 -0400 (EDT) Received: (qmail 16222 invoked by uid 605); 23 Aug 2003 17:53:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16215 invoked from network); 23 Aug 2003 17:53:58 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 23 Aug 2003 17:53:58 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa30132; 23 Aug 2003 13:53 EDT Date: Sat, 23 Aug 2003 13:53:17 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Love cc: Joseph Salowey , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, 23 Aug 2003, Love wrote: > I'm fine with that, using GSS_C_AF_NULLADDRs and stuff the session > identifier in the application_data fields, the later is what CCM proposes, > would work for all mechs that have working channel bindings would save you > From the extra round trip. But then, channel bindings are useless (for ssh > gssuserauth) because they are optional for the gss mechs. Using channel bindings would also destroy backward-compatibility, in both directions. A client which sends channel bindings would not be able to establish a security context with a server that is not expecting to accept them. > If the MIC is set with the last gss exchange packet, you would have 0 or 1 > extra packets. 0 in the case where the last exchange packets is from the > client and 1 when the last exchange packet is from the server. So I would > argue that its not a extra roundtrip, but rather none (with more data) or a > half. In the gssapi userauth method we have defined, the last message is always sent by the client. Thus, we can define an alternate version of this message (currently always SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which contains the MIC. > I would very much like to see mutual auth in the gss userauth layer, but > sending MIC from client to server is ok with me. Why? The userauth layer isn't about authenticating the server to the client; we've already done that. Performing mutual auth in the userauth layer would restrict us to GSSAPI mechanisms that can _do_ mutual auth. I don't see any gain that justifies that restriction. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 11:01: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 LAA22592 for ; Mon, 25 Aug 2003 11:00:59 -0400 (EDT) Received: (qmail 4454 invoked by uid 605); 25 Aug 2003 15:00:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4447 invoked from network); 25 Aug 2003 15:00:55 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 25 Aug 2003 15:00:55 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1984654; Mon, 25 Aug 2003 09:00:54 -0600 Message-ID: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Jeffrey Hutzelman" , "Love" Cc: "Joseph Salowey" , References: Subject: Re: gss userauth Date: Mon, 25 Aug 2003 09:00:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > > I'm fine with that, using GSS_C_AF_NULLADDRs and stuff the session > > identifier in the application_data fields, the later is what CCM proposes, > > would work for all mechs that have working channel bindings would save you > > From the extra round trip. But then, channel bindings are useless (for ssh > > gssuserauth) because they are optional for the gss mechs. > > Using channel bindings would also destroy backward-compatibility, in both > directions. A client which sends channel bindings would not be able to > establish a security context with a server that is not expecting to accept > them. I'm a little concerned about compatability at these point-- I've got a shipping version -- which perhaps wasn't wise as we hadn't completed last call, but, never-the-less, I've got one. When we originally wrote the draft we talked about something like this but elected not to do it so that userauth wouldn't require integrity and mutual auth as the kex method does. I'm sure I'm being niave (or I just drove all night and my brain isn't working correctly yet), but, assuming the SSH layer is secure (and if you want to secure the SSH layer using gss, you can use the kex method), what attack does this prevent? Also, I don't think Microsoft supports channel bindings-- so I would definitely prefer not to require these. > > If the MIC is set with the last gss exchange packet, you would have 0 or 1 > > extra packets. 0 in the case where the last exchange packets is from the > > client and 1 when the last exchange packet is from the server. So I would > > argue that its not a extra roundtrip, but rather none (with more data) or a > > half. > > In the gssapi userauth method we have defined, the last message is always > sent by the client. Thus, we can define an alternate version of this > message (currently always SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which > contains the MIC. If this feature is required to prevent an attack, I would definitely prefer this solution. In fact, to prevent downgrade attacks based on compatibility with old versions, we might want to define "gssapi-2", which is identical to "gssapi" in all ways, except that SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains the MIC. > > I would very much like to see mutual auth in the gss userauth layer, but > > sending MIC from client to server is ok with me. > > Why? The userauth layer isn't about authenticating the server to the > client; we've already done that. Performing mutual auth in the userauth > layer would restrict us to GSSAPI mechanisms that can _do_ mutual auth. > I don't see any gain that justifies that restriction. I definitely agree. One of the major reasons for having a userauth method is that it isn't as demanding on the capabilities of the gss mech as key exchange is. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 11:50:17 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 LAA25086 for ; Mon, 25 Aug 2003 11:50:16 -0400 (EDT) Received: (qmail 9041 invoked by uid 605); 25 Aug 2003 15:50:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9029 invoked from network); 25 Aug 2003 15:50:19 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 25 Aug 2003 15:50:19 -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 h7PFjn4Z019845; Mon, 25 Aug 2003 17:45:49 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 7F2E72D003; Mon, 25 Aug 2003 17:45:32 +0200 (CEST) Date: Mon, 25 Aug 2003 17:45:32 +0200 From: Markus Friedl To: Joseph Galbraith Cc: Jeffrey Hutzelman , Love , Joseph Salowey , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030825154532.GB16491@folly> References: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Aug 25, 2003 at 09:00:54AM -0600, Joseph Galbraith wrote: > I'm sure I'm being niave (or I just drove all night > and my brain isn't working correctly yet), but, assuming > the SSH layer is secure (and if you want to secure the > SSH layer using gss, you can use the kex method), what > attack does this prevent? i don't know GSS API, but for pubkey auth the session id is used to 'bind' the signature to the connection. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 12:26: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 MAA26662 for ; Mon, 25 Aug 2003 12:26:54 -0400 (EDT) Received: (qmail 27578 invoked by uid 605); 25 Aug 2003 16:26:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27571 invoked from network); 25 Aug 2003 16:26:55 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 25 Aug 2003 16:26:55 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h7PGQq8T098691 for ; Mon, 25 Aug 2003 10:26:52 -0600 (MDT) Message-ID: <001f01c36b25$b15f9860$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: References: <200308201908.PAA00764@ietf.org> Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt Date: Mon, 25 Aug 2003 10:26:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.0 required=10.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joel, It looks like the version of this document posted to internet-drafts@ietf.org is out sync with a more recent version that Jon Bright posted to the working group on 7/25. There are a number of differences, including the fact that Jon's 7/25 version includes the often-neglected Security Considerations... We should probably iron that out. --Brent ----- Original Message ----- From: "Joel N. Weber II" To: Sent: Thursday, August 21, 2003 12:49 PM Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt > Under ``2.1 Opening the Public-Key Subsystem'', it is said that > clients SHOULD reject a request for this subsystem. I suspect that > that should instead be a MUST. > > Under ``2.2 Requests'', is there a good reason to disallow a client > sending more than one request and expecting that the server will > respond to them in order? (If there is, I think the draft should > probably have a sentence explaining what problem that requirement is > solving; if not, pipelined requests should be allowed.) > > Editorial nitpicking: > > ``3. Public-Key Subsystem Operations'' says that four requests are > defined, including ``command'', but I think ``command'' got absorbed > into the key attributes. > > A case-insensitive grep for ``secsh'' in the core drafts doesn't > appear to find any places where the protocol's proper name is > ``SECSH''. I believe that ``the Secure Shell protocol'' and ``the SSH > protocol'' both appear, though. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 12:29: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 MAA26749 for ; Mon, 25 Aug 2003 12:29:49 -0400 (EDT) Received: (qmail 28977 invoked by uid 605); 25 Aug 2003 16:29:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28970 invoked from network); 25 Aug 2003 16:29:52 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 25 Aug 2003 16:29:52 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 275451EB70; Mon, 25 Aug 2003 18:29:45 +0200 (CEST) Message-ID: <3F4A390D.4030303@siliconcircus.com> Date: Mon, 25 Aug 2003 18:27:57 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brent McClure Cc: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt References: <200308201908.PAA00764@ietf.org> <001f01c36b25$b15f9860$4900a8c0@galb.vandyke.com> In-Reply-To: <001f01c36b25$b15f9860$4900a8c0@galb.vandyke.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 Brent, Brent McClure wrote: > It looks like the version of this document posted to > internet-drafts@ietf.org is out sync with a more recent > version that Jon Bright posted to the working group on 7/25. > > There are a number of differences, including the fact that > Jon's 7/25 version includes the often-neglected Security Considerations... My bad, I posted that to internet-drafts. I'll look into how I managed to post the wrong version and get the right version posted to internet-drafts forthwith. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 12:33:38 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 MAA27318 for ; Mon, 25 Aug 2003 12:33:38 -0400 (EDT) Received: (qmail 2145 invoked by uid 605); 25 Aug 2003 16:33:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2138 invoked from network); 25 Aug 2003 16:33:41 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 25 Aug 2003 16:33:41 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7PGXfkD015296; Mon, 25 Aug 2003 09:33:41 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.10.Beta3+Sun/8.12.10.Beta3) with ESMTP id h7PGXeF6212571; Mon, 25 Aug 2003 09:33:40 -0700 (PDT) Date: Mon, 25 Aug 2003 09:33:40 -0700 (PDT) From: Darren J Moffat To: Brent McClure cc: Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt In-Reply-To: <001f01c36b25$b15f9860$4900a8c0@galb.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 25 Aug 2003, Brent McClure wrote: > It looks like the version of this document posted to > internet-drafts@ietf.org is out sync with a more recent > version that Jon Bright posted to the working group on 7/25. > > There are a number of differences, including the fact that > Jon's 7/25 version includes the often-neglected Security Considerations... > > We should probably iron that out. In addition to this didn't we have consensus that this was a working group item ? If so it should be called draft-ietf-secsh-publickey-subsystem-XX.txt -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 12:39:15 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 MAA27720 for ; Mon, 25 Aug 2003 12:39:14 -0400 (EDT) Received: (qmail 5648 invoked by uid 605); 25 Aug 2003 16:39:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5641 invoked from network); 25 Aug 2003 16:39:17 -0000 Received: from mail.siliconcircus.com (62.141.33.102) by mail.netbsd.org with SMTP; 25 Aug 2003 16:39:17 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 9A47B1EB70; Mon, 25 Aug 2003 18:39:15 +0200 (CEST) Message-ID: <3F4A3B47.20307@siliconcircus.com> Date: Mon, 25 Aug 2003 18:37:27 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren J Moffat Cc: Brent McClure , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt References: In-Reply-To: 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 Darren, Darren J Moffat wrote: > In addition to this didn't we have consensus that this was a working group > item ? If so it should be called draft-ietf-secsh-publickey-subsystem-XX.txt I mailed Bill both via the group and privately asking if this was to become a WG item - I've not yet had a reply (though I haven't followed up, I assume he's a busy man). The other open question is the naming of the subsystem if it becomes a WG item - i.e. should it still be @vandyke.com. Additionally, from the last minutes: Expected before next IETF: [...] Discussion of whether to accept individual submissions as WG items: draft-galb-secsh-publickey-subsystem-01.txt [mcclure] So, although I'd be happy to submit it under that name, I don't think there's yet consensus. I'll hold off for a day or so on submitting the completed version, to see if there's clarification of which name to submit it under :-) -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 14:57: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 OAA09403 for ; Mon, 25 Aug 2003 14:57:22 -0400 (EDT) Received: (qmail 25899 invoked by uid 605); 25 Aug 2003 18:57:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25891 invoked from network); 25 Aug 2003 18:57:23 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 25 Aug 2003 18:57:23 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7PIvIDr008820; Mon, 25 Aug 2003 11:57:18 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.80.61]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Aug 2003 12:01:30 -0700 From: "Joseph Salowey" To: "'Joseph Galbraith'" , "'Jeffrey Hutzelman'" , "'Love'" Cc: Subject: RE: gss userauth Date: Mon, 25 Aug 2003 11:57:16 -0700 Message-ID: <022101c36b3a$b493dbd0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 25 Aug 2003 19:01:30.0842 (UTC) FILETIME=[4B615BA0:01C36B3B] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, August 25, 2003 8:01 AM > To: Jeffrey Hutzelman; Love > Cc: Joseph Salowey; ietf-ssh@NetBSD.org > Subject: Re: gss userauth > > > > > I'm fine with that, using GSS_C_AF_NULLADDRs and stuff > the session > > > identifier in the application_data fields, the later is what CCM > proposes, > > > would work for all mechs that have working channel bindings would > > > save > you > > > From the extra round trip. But then, channel bindings are useless > > > (for > ssh > > > gssuserauth) because they are optional for the gss mechs. > > > > Using channel bindings would also destroy > backward-compatibility, in > > both directions. A client which sends channel bindings > would not be > > able to establish a security context with a server that is not > > expecting to accept them. > > I'm a little concerned about compatability at these > point-- I've got a shipping version -- which perhaps > wasn't wise as we hadn't completed last call, but, > never-the-less, I've got one. > > When we originally wrote the draft we talked about > something like this but elected not to do it so that > userauth wouldn't require integrity and mutual auth > as the kex method does. > > I'm sure I'm being niave (or I just drove all night > and my brain isn't working correctly yet), but, assuming > the SSH layer is secure (and if you want to secure the > SSH layer using gss, you can use the kex method), what > attack does this prevent? > [Joe] If the GSSAPI exchange is not bound to the session then you do not have assurance that the client actually was performing the GSSAPI exchange to authenticate itself to the SSH server. The client may actually be trying to authenticate to some other service in some other context and his authentication may be proxied by a third party. Part of the problem is that the target name suggested is "host@" which can be used by multiple services on a host. > Also, I don't think Microsoft supports channel bindings-- > so I would definitely prefer not to require these. > > > > If the MIC is set with the last gss exchange packet, you > would have > > > 0 or > 1 > > > extra packets. 0 in the case where the last exchange > packets is from > > > the client and 1 when the last exchange packet is from > the server. > > > So I > would > > > argue that its not a extra roundtrip, but rather none (with more > > > data) > or a > > > half. > > > > In the gssapi userauth method we have defined, the last message is > > always sent by the client. Thus, we can define an > alternate version > > of this message (currently always > > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which contains the MIC. > > If this feature is required to prevent an attack, I > would definitely prefer this solution. > > In fact, to prevent downgrade attacks based on > compatibility with old versions, we might want > to define "gssapi-2", which is identical to > "gssapi" in all ways, except that > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains the MIC. > > > > I would very much like to see mutual auth in the gss > userauth layer, > > > but sending MIC from client to server is ok with me. > > > > Why? The userauth layer isn't about authenticating the > server to the > > client; we've already done that. Performing mutual auth in the > > userauth layer would restrict us to GSSAPI mechanisms that can _do_ > > mutual auth. I don't see any gain that justifies that restriction. > > I definitely agree. One of the major reasons for having > a userauth method is that it isn't as demanding on the > capabilities of the gss mech as key exchange is. > > - Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 16:44: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 QAA15089 for ; Mon, 25 Aug 2003 16:44:19 -0400 (EDT) Received: (qmail 1374 invoked by uid 605); 25 Aug 2003 20:44:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1367 invoked from network); 25 Aug 2003 20:44:21 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 25 Aug 2003 20:44:21 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa12760; 25 Aug 2003 16:43 EDT Date: Mon, 25 Aug 2003 16:43:27 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , Love cc: Jeffrey Hutzelman , Joseph Salowey , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <1961590000.1061844207@minbar.fac.cs.cmu.edu> In-Reply-To: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> References: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> 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, August 25, 2003 09:00:54 -0600 Joseph Galbraith wrote: > When we originally wrote the draft we talked about > something like this but elected not to do it so that > userauth wouldn't require integrity and mutual auth > as the kex method does. Right. In a very early version of the userauth draft, before we merged userauth and keyex into one document, we had a requirement that the server send a MIC of the host key (or was it the session ID? I forget) to the client. The point of this was to "increase confidence" in the correctness of the host key. We dropped it because there was relatively little percieved gain, and we wanted not to have to require integrity and mutual auth from the underlying GSSAPI mechanism. What we're talking about now is similar, but different. The current proposal is to require the _client_ to send the _server_ a MIC of the session ID. This proves to the server that the client which has just authenticated to it is the same client that started the ssh connection, and not some intermediate attacker. I believe this is a real problem and worth solving; I also believe there is a solution which is quite trivial and does not break backward compatibility. > In fact, to prevent downgrade attacks based on > compatibility with old versions, we might want > to define "gssapi-2", which is identical to > "gssapi" in all ways, except that > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains > the MIC. I don't think it should actually be necessary to do this; it should be sufficient to use a new final message in place of the existing one. A new client would always send the new message, and fall back to sending the old one if it gets a SSH_MSG_UNIMPLEMENTED. This isn't really a "downgrade" as far as the client is concerned, since the only difference is that the "old" version causes the client to send _less_ data. A new server can choose to accept the old message or not, depending on a local policy decision about a tradeoff between security and compatibility with old clients. This approach gives us complete interoperability between old and new implementations, except in the case where a new server chooses not to support old clients for security reasons. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 17:55: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 RAA17915 for ; Mon, 25 Aug 2003 17:55:43 -0400 (EDT) Received: (qmail 12519 invoked by uid 605); 25 Aug 2003 21:55:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12489 invoked from network); 25 Aug 2003 21:55:39 -0000 Received: from adsl-68-73-81-151.dsl.emhril.ameritech.net (HELO flanders.mynet.net) (68.73.81.151) by mail.netbsd.org with SMTP; 25 Aug 2003 21:55:39 -0000 Received: from flanders.mynet.net (localhost [127.0.0.1]) by flanders.mynet.net (8.12.9/8.12.9) with ESMTP id h7PLtP5e000710; Mon, 25 Aug 2003 16:55:25 -0500 (CDT) Received: from localhost (smichaud@localhost) by flanders.mynet.net (8.12.9/8.12.9/Submit) with ESMTP id h7PLt7GF000707; Mon, 25 Aug 2003 16:55:12 -0500 (CDT) Date: Mon, 25 Aug 2003 16:55:07 -0500 (CDT) From: Steven Michaud X-X-Sender: smichaud@flanders.mynet.net To: jsalowey@cisco.com cc: galb-list@vandyke.com, jhutz@cmu.edu, lha@stacken.kth.se, ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list > [Joe] If the GSSAPI exchange is not bound to the session then you do > not have assurance that the client actually was performing the > GSSAPI exchange to authenticate itself to the SSH server. The > client may actually be trying to authenticate to some other service > in some other context and his authentication may be proxied by a > third party. Part of the problem is that the target name suggested > is "host@" which can be used by multiple services on a host. Are you talking about some kind of man-in-the-middle attack? If so, wouldn't the MITM have to break in after the key exchange had taken place, the session id had been negotiated, and encryption was already in effect? (Which is when gss userauth happens.) And wouldn't this be impossible? Or are you talking about the server somehow misunderstanding what the client was after? In this case wouldn't it be up to the client to leave no room for doubt? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 18:21: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 SAA20348 for ; Mon, 25 Aug 2003 18:21:24 -0400 (EDT) Received: (qmail 27372 invoked by uid 605); 25 Aug 2003 22:21:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27365 invoked from network); 25 Aug 2003 22:21:26 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 25 Aug 2003 22:21:26 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7PMLPpF004743; Mon, 25 Aug 2003 15:21:25 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.80.61]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Aug 2003 15:25:37 -0700 From: "Joseph Salowey" To: "'Steven Michaud'" Cc: , , , Subject: RE: gss userauth Date: Mon, 25 Aug 2003 15:21:23 -0700 Message-ID: <024701c36b57$388912e0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 25 Aug 2003 22:25:38.0155 (UTC) FILETIME=[CF5903B0:01C36B57] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Steven Michaud [mailto:smichaud@pobox.com] > Sent: Monday, August 25, 2003 2:55 PM > To: jsalowey@cisco.com > Cc: galb-list@vandyke.com; jhutz@cmu.edu; lha@stacken.kth.se; > ietf-ssh@NetBSD.org > Subject: Re: gss userauth > > > > [Joe] If the GSSAPI exchange is not bound to the session > then you do > > not have assurance that the client actually was performing > the GSSAPI > > exchange to authenticate itself to the SSH server. The client may > > actually be trying to authenticate to some other service in > some other > > context and his authentication may be proxied by a third > party. Part > > of the problem is that the target name suggested is "host@" > which can > > be used by multiple services on a host. > > Are you talking about some kind of man-in-the-middle attack? > If so, wouldn't the MITM have to break in after the key > exchange had taken place, the session id had been negotiated, > and encryption was already in effect? (Which is when gss > userauth happens.) And wouldn't this be impossible? > [Joe] It is a type of MITM attack, but the problem occurs before encryption is established. If the GSSAPI credentials are usable with another service besides SSH then an attacker intercepting this credential exchange which is not protected by SSH can then use it within an SSH exchange as if they were the valid client. As a further extension if a client is tricked into participating into an exchange with an invalid SSH server (ie. Fails to validate the host key properly) then the receiver of the invalid credential may be able to use it to authenticate to the valid server as the client. Binding the session ID into the GSSAPI exchange can help prevent these problems. > Or are you talking about the server somehow misunderstanding > what the client was after? > In this case wouldn't it be up to > the client to leave no room for doubt? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 19:08:24 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 TAA22157 for ; Mon, 25 Aug 2003 19:08:23 -0400 (EDT) Received: (qmail 29134 invoked by uid 605); 25 Aug 2003 23:08:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29122 invoked from network); 25 Aug 2003 23:08:21 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 25 Aug 2003 23:08:21 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa12921; 25 Aug 2003 19:08 EDT Date: Mon, 25 Aug 2003 19:08:10 -0400 From: Jeffrey Hutzelman To: Joseph Salowey , "'Tim Alsop'" , "'Joseph Galbraith'" , "'Love'" cc: "'Jeffrey Hutzelman'" , ietf-ssh@NetBSD.org Subject: RE: gss userauth Message-ID: <2009820000.1061852890@minbar.fac.cs.cmu.edu> In-Reply-To: <024d01c36b5a$a0a4a800$0200000a@amer.cisco.com> References: <024d01c36b5a$a0a4a800$0200000a@amer.cisco.com> 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, August 25, 2003 15:45:47 -0700 Joseph Salowey wrote: > It would help, especially in the case of kerberos. However it does not > completly solve the problem and I'm not sure it would help with other > GSSAPI mechanisms (with some mechanisms this mey not be a problem > anyway). I think sending the Session ID in the MIC is a better > solution. So do I. The use of the "host" service name for ssh is appropriate, and is exactly the sort of usage for which that service name was designed. For some mechanisms, such as Kerberos, changing it to something else would effectively require maintaining a separate set of 'ssh' service keys for each machine in addition to the 'host' keys they already have, creating a key management problem where we had hoped to solve one. It would also create a significant interoperability problem with currently-deployed clients and servers. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 20:17: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 UAA24193 for ; Mon, 25 Aug 2003 20:17:27 -0400 (EDT) Received: (qmail 10970 invoked by uid 605); 26 Aug 2003 00:17:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10961 invoked from network); 26 Aug 2003 00:17:25 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 26 Aug 2003 00:17:25 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7Q0HO45022607 for ; Mon, 25 Aug 2003 17:17:24 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.80.61]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Aug 2003 17:21:36 -0700 From: "Joseph Salowey" To: Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt Date: Mon, 25 Aug 2003 17:17:22 -0700 Message-ID: <025c01c36b67$6c3c23b0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20030821160748.GA15282@chiark.greenend.org.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 26 Aug 2003 00:21:36.0933 (UTC) FILETIME=[031A4550:01C36B68] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Jacob Nevins > Sent: Thursday, August 21, 2003 9:08 AM > To: ietf-ssh@NetBSD.org > Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-00.txt > > > Joseph Salowey writes: > > [Joel N. Weber II:] > > > Is there a good reason to define scp URLs in addition to > sftp URLs? > > > > [Joe] SCP is is use today, we thought it would be useful. > > How should filenames containing spaces be represented in scp: > URLs? Backslashes? > [Joe] In a URL spaces need to be escaped (%20) > The scp "protocol" requires that such filenames be quoted in > some unspecified way (often using Unix shell quoting, but > presumably server-dependent). IME, with many current clients > it's up to the user to know the quoting convention on the > particular server. Either the quoting will have to be > embedded in URLs (and hence specified), or quoting becomes > the client's responsibility and the standardisation of the > URL format will not do much to achieve interoperability. > [Joe] So if hierarchical URL format is used then either the SCP client or server will have to deal with converting the URL into the appropriate format. If we decide to use an opaque format then this portion of the URL would not be paresed by the URL parser and existing ways of formatting the pathname apply. It seems that using hierarcical URLs will require implementation work on SCP client and maybe SCP server which may not be desireable. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Aug 25 21:40: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 VAA26940 for ; Mon, 25 Aug 2003 21:40:32 -0400 (EDT) Received: (qmail 26897 invoked by uid 605); 26 Aug 2003 01:40:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26888 invoked from network); 26 Aug 2003 01:40:29 -0000 Received: from adsl-68-73-81-151.dsl.emhril.ameritech.net (HELO flanders.mynet.net) (68.73.81.151) by mail.netbsd.org with SMTP; 26 Aug 2003 01:40:29 -0000 Received: from flanders.mynet.net (localhost [127.0.0.1]) by flanders.mynet.net (8.12.9/8.12.9) with ESMTP id h7Q1eO5e001083; Mon, 25 Aug 2003 20:40:24 -0500 (CDT) Received: from localhost (smichaud@localhost) by flanders.mynet.net (8.12.9/8.12.9/Submit) with ESMTP id h7Q1eG7C001080; Mon, 25 Aug 2003 20:40:20 -0500 (CDT) Date: Mon, 25 Aug 2003 20:40:16 -0500 (CDT) From: Steven Michaud X-X-Sender: smichaud@flanders.mynet.net To: Joseph Salowey cc: galb-list@vandyke.com, jhutz@cmu.edu, lha@stacken.kth.se, ietf-ssh@NetBSD.org Subject: RE: gss userauth In-Reply-To: <024701c36b57$388912e0$0200000a@amer.cisco.com> Message-ID: References: <024701c36b57$388912e0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list > It is a type of MITM attack, but the problem [possible hijacking of > GSSAPI credentials] occurs before encryption is established. I'm still trying to wrap my head around the MITM attack(s) you describe ... so I still can't discuss the whole issue intelligently. But I think your statement above is false with respect to gss userauth (as described in section 3 of draft-ietf-secsh-gsskeyex). Though it does seem to be true of gss key exchange (as described in section 2). In gss key exchange, GSSAPI authentication occurs at the beginning of the key exchange process, while the transport layer is being negotiated. So yes, it will take place while the SSH conversation is still in the clear. But gss userauth is part of the authentication protocol. A standard key exchange (possibly a DH one) has already taken place, and the secure transport layer has already been negotiated. Now, of course, during the GSSAPI authentication process the ssh client may (from inside the Kerberos 5 mechanism) talk with the KDC (to get a TGT and/or a service ticket), and these conversations can't take place over SSH encryption, no matter when they occur. But the opaque tokens that are explicitly passed between the ssh client and the ssh server (as they repeatedly call gss_init_sec_context() and gss_accept_sec_context()) certainly _can_ travel over an SSH-encrypted pipe. Or have I completely misunderstood what you said? :-) On Mon, 25 Aug 2003, Joseph Salowey wrote: > > > > -----Original Message----- > > From: Steven Michaud [mailto:smichaud@pobox.com] > > Sent: Monday, August 25, 2003 2:55 PM > > To: jsalowey@cisco.com > > Cc: galb-list@vandyke.com; jhutz@cmu.edu; lha@stacken.kth.se; > > ietf-ssh@NetBSD.org > > Subject: Re: gss userauth > > > > > > > [Joe] If the GSSAPI exchange is not bound to the session > > then you do > > > not have assurance that the client actually was performing > > the GSSAPI > > > exchange to authenticate itself to the SSH server. The client may > > > actually be trying to authenticate to some other service in > > some other > > > context and his authentication may be proxied by a third > > party. Part > > > of the problem is that the target name suggested is "host@" > > which can > > > be used by multiple services on a host. > > > > Are you talking about some kind of man-in-the-middle attack? > > If so, wouldn't the MITM have to break in after the key > > exchange had taken place, the session id had been negotiated, > > and encryption was already in effect? (Which is when gss > > userauth happens.) And wouldn't this be impossible? > > > > [Joe] It is a type of MITM attack, but the problem occurs before > encryption is established. If the GSSAPI credentials are usable with > another service besides SSH then an attacker intercepting this > credential exchange which is not protected by SSH can then use it within > an SSH exchange as if they were the valid client. As a further > extension if a client is tricked into participating into an exchange > with an invalid SSH server (ie. Fails to validate the host key properly) > then the receiver of the invalid credential may be able to use it to > authenticate to the valid server as the client. Binding the session ID > into the GSSAPI exchange can help prevent these problems. > > > Or are you talking about the server somehow misunderstanding > > what the client was after? > > In this case wouldn't it be up to > > the client to leave no room for doubt? > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 10:05:58 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 KAA04905 for ; Tue, 26 Aug 2003 10:05:58 -0400 (EDT) Received: (qmail 15273 invoked by uid 605); 26 Aug 2003 14:05:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15259 invoked from network); 26 Aug 2003 14:05:58 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 26 Aug 2003 14:05:58 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04887; Tue, 26 Aug 2003 10:05:53 -0400 (EDT) Message-Id: <200308261405.KAA04887@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-publickeyfile-04.txt Date: Tue, 26 Aug 2003 10:05:52 -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 : SECSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-04.txt Pages : 11 Date : 2003-8-26 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-04.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-publickeyfile-04.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-publickeyfile-04.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-8-26102445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-26102445.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 11:51:09 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 LAA12092 for ; Tue, 26 Aug 2003 11:51:08 -0400 (EDT) Received: (qmail 11858 invoked by uid 605); 26 Aug 2003 15:51:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11848 invoked from network); 26 Aug 2003 15:51:07 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 26 Aug 2003 15:51:07 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h7QFp28T057025; Tue, 26 Aug 2003 09:51:02 -0600 (MDT) Message-ID: <00ee01c36be9$da6d8b30$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: Cc: "Joel N. Weber II" References: <200308201908.PAA00764@ietf.org> Subject: Re: I-D ACTION:draft-galb-secsh-publickey-subsystem-02.txt Date: Tue, 26 Aug 2003 09:51:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.3 required=10.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- > Under ``2.1 Opening the Public-Key Subsystem'', it is said that > clients SHOULD reject a request for this subsystem. I suspect that > that should instead be a MUST. It seems to me that leaving it SHOULD would be more consistent with at statement in draft-ietf-secsh-connect-17.txt, Section 4.5 "Starting a Shell or a Command". With regard to clients receiving subsystem requests, it just says "The client SHOULD ignore these messages". It also seems like a client receiving an open request for this subsytem falls into the category of being something abnormal rather than something that could expose a risk. The requests in that document that SHOULD be rejected seem to be the ones that don't make sense for a client (like receiving a "pty" or "session" request). The ones that MUST be rejected seem to be ones that may be indication of possible foul play (such as unsolicited X11 forwarding). I think this case is more the former. > > Under ``2.2 Requests'', is there a good reason to disallow a client > sending more than one request and expecting that the server will > respond to them in order? (If there is, I think the draft should > probably have a sentence explaining what problem that requirement is > solving; if not, pipelined requests should be allowed.) Our view was that this was the simplest thing to implement. And, given that this is a low-bandwidth and intermittently-used protocol, a one-request-at-a-time scenario seemed sufficient. Most of the time a client will get a listing of keys, add a new one or delete one and that's it. It could be argued that the one-at-a-time requests requires more state to be maintained than being able to shove a bunch of requests down a pipe, but if you are checking the results of each request then even the pipelined implementation is going to require state. Anyhow that was our take on it. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 14:25:12 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 OAA18666 for ; Tue, 26 Aug 2003 14:25:11 -0400 (EDT) Received: (qmail 16709 invoked by uid 605); 26 Aug 2003 18:25:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16691 invoked from network); 26 Aug 2003 18:25:01 -0000 Received: from adsl-68-78-101-70.dsl.emhril.ameritech.net (HELO flanders.mynet.net) (68.78.101.70) by mail.netbsd.org with SMTP; 26 Aug 2003 18:25:01 -0000 Received: from flanders.mynet.net (localhost [127.0.0.1]) by flanders.mynet.net (8.12.9/8.12.9) with ESMTP id h7QIOiYn000617; Tue, 26 Aug 2003 13:24:44 -0500 (CDT) Received: from localhost (smichaud@localhost) by flanders.mynet.net (8.12.9/8.12.9/Submit) with ESMTP id h7QIOYu3000614; Tue, 26 Aug 2003 13:24:34 -0500 (CDT) Date: Tue, 26 Aug 2003 13:24:34 -0500 (CDT) From: Steven Michaud X-X-Sender: smichaud@flanders.mynet.net To: Joseph Salowey cc: galb-list@vandyke.com, jhutz@cmu.edu, lha@stacken.kth.se, ietf-ssh@NetBSD.org Subject: RE: gss userauth In-Reply-To: Message-ID: References: <024701c36b57$388912e0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'm still not sure I've understood the MITM attacks you've described. But, as long as the GSSAPI client is using mutual authentication (and the underlying mechanism is using reasonably strong encryption), I don't think it's possible to hijack the user's GSSAPI credentials by sniffing the wire, no matter how much of the GSSAPI traffic has been intercepted (and even if none of it is protected by SSH encryption). As far as I can tell, the worst danger you face is that the GSSAPI authentication would be to some other service running on the same server that also used the "host@" service name. But this kind of ambiguity could (presumably) be eliminated by changing how the other service was set up. (I assume that if someone had rooted the server and replaced the "other" service with a malicious copy, he/she could have done the same with sshd.) That said, I see the point of having gss userauth "bind" the SSH session id: It seems like there's a way to do this ("sending the Session ID in the MIC") that won't "cost" much and can preserve backwards compatiblity. And, though perhaps redundant, it will help ensure against weaknesses in SSH or GSSAPI that haven't yet been discovered. But I don't think there's a "hole" that those who maintain current implementations of draft-ietf-secsh-gsskeyex (Simon Wilkinson's patch to OpenSSH, SecureCRT) need to scramble to "patch". Nor do I think that the OpenSSH maintainers, who are currently considering adding a partial implementation of Simon's patch (one that includes gss userauth but not gss key exchange), need to postpone this addition. (That isn't up to me, but I'm trying to convince the OpenSSH folks. I'm a big fan of Simon Wilkinson's patch and think adding even parts of it to standard OpenSSH would make GSSAPI authentication for SSH more widely available.) What I say above is based on the assumption that the GSSAPI protocol will do what it's supposed to -- most importantly, that its mutual authentation of client and server will really work, and that this will guarantee that the "wrong" "host@" service must be running on the same server as the "true" sshd (not on some other computer, with a spoofed ip address, running a malicious replacement for sshd). The only GSSAPI mechanism that I know reasonably well is Kerberos 5. It does (of course) support mutual authentication. And (if you're using strong encryption) it seems to guarantee that neither the client's secret key (derived from the "Kerberos password") nor his/her (short-lived) credentials (what's in the ticket cache) can be captured by network-sniffing alone (even if the attacker replays captured network traffic). Furthermore, because Kerberos 5's service principals take the form "servicename/fdqn@realm", the "host@" service to which the ssh client might mistakenly authenticate would have to be running on a server whose "true" name is "fdqn" (not a machine that was spoofing that address, because otherwise mutual authentication would fail) -- which presumably (if the admins were doing their job) would have to be the server on which the "true" sshd was also running. Very few other GSSAPI mechanisms exist. I know of the GSI mechanism that (I think) was developed by Douglas Engert, though I'm not very familiar with it. But I do believe it also supports mutual authentication. And I'd be surprised to find _any_ GSSAPI mechanism whose service principals don't include the host name. Slightly off topic: Would it be reasonable to make gss userauth fail if mutual authentication isn't available? On Mon, 25 Aug 2003, Steven Michaud wrote: > > It is a type of MITM attack, but the problem [possible hijacking of > > GSSAPI credentials] occurs before encryption is established. > > I'm still trying to wrap my head around the MITM attack(s) you > describe ... so I still can't discuss the whole issue intelligently. > > But I think your statement above is false with respect to gss userauth > (as described in section 3 of draft-ietf-secsh-gsskeyex). Though it > does seem to be true of gss key exchange (as described in section 2). > > In gss key exchange, GSSAPI authentication occurs at the beginning of > the key exchange process, while the transport layer is being > negotiated. So yes, it will take place while the SSH conversation is > still in the clear. > > But gss userauth is part of the authentication protocol. A standard > key exchange (possibly a DH one) has already taken place, and the > secure transport layer has already been negotiated. > > Now, of course, during the GSSAPI authentication process the ssh > client may (from inside the Kerberos 5 mechanism) talk with the KDC > (to get a TGT and/or a service ticket), and these conversations can't > take place over SSH encryption, no matter when they occur. But the > opaque tokens that are explicitly passed between the ssh client and > the ssh server (as they repeatedly call gss_init_sec_context() and > gss_accept_sec_context()) certainly _can_ travel over an SSH-encrypted > pipe. > > Or have I completely misunderstood what you said? :-) > > On Mon, 25 Aug 2003, Joseph Salowey wrote: > > > > > > > > -----Original Message----- > > > From: Steven Michaud [mailto:smichaud@pobox.com] > > > Sent: Monday, August 25, 2003 2:55 PM > > > To: jsalowey@cisco.com > > > Cc: galb-list@vandyke.com; jhutz@cmu.edu; lha@stacken.kth.se; > > > ietf-ssh@NetBSD.org > > > Subject: Re: gss userauth > > > > > > > > > > [Joe] If the GSSAPI exchange is not bound to the session then > > > > you do not have assurance that the client actually was > > > > performing the GSSAPI exchange to authenticate itself to the > > > > SSH server. The client may actually be trying to > > > > authenticate to some other service in some other context and > > > > his authentication may be proxied by a third party. Part of > > > > the problem is that the target name suggested is "host@" > > > > which can be used by multiple services on a host. > > > > > > Are you talking about some kind of man-in-the-middle attack? > > > If so, wouldn't the MITM have to break in after the key > > > exchange had taken place, the session id had been negotiated, > > > and encryption was already in effect? (Which is when gss > > > userauth happens.) And wouldn't this be impossible? > > > > > > > [Joe] It is a type of MITM attack, but the problem occurs before > > encryption is established. If the GSSAPI credentials are usable > > with another service besides SSH then an attacker intercepting > > this credential exchange which is not protected by SSH can then > > use it within an SSH exchange as if they were the valid client. > > As a further extension if a client is tricked into participating > > into an exchange with an invalid SSH server (ie. Fails to > > validate the host key properly) then the receiver of the invalid > > credential may be able to use it to authenticate to the valid > > server as the client. Binding the session ID into the GSSAPI > > exchange can help prevent these problems. > > > > > Or are you talking about the server somehow misunderstanding > > > what the client was after? In this case wouldn't it be up to > > > the client to leave no room for doubt? > > > > > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 14:44: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 OAA20875 for ; Tue, 26 Aug 2003 14:44:55 -0400 (EDT) Received: (qmail 27063 invoked by uid 605); 26 Aug 2003 18:44:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27056 invoked from network); 26 Aug 2003 18:44:56 -0000 Received: from adsl-68-78-101-70.dsl.emhril.ameritech.net (HELO flanders.mynet.net) (68.78.101.70) by mail.netbsd.org with SMTP; 26 Aug 2003 18:44:56 -0000 Received: from flanders.mynet.net (localhost [127.0.0.1]) by flanders.mynet.net (8.12.9/8.12.9) with ESMTP id h7QIiKYn000646; Tue, 26 Aug 2003 13:44:20 -0500 (CDT) Received: from localhost (smichaud@localhost) by flanders.mynet.net (8.12.9/8.12.9/Submit) with ESMTP id h7QIiGsA000643; Tue, 26 Aug 2003 13:44:16 -0500 (CDT) Date: Tue, 26 Aug 2003 13:44:16 -0500 (CDT) From: Steven Michaud X-X-Sender: smichaud@flanders.mynet.net To: Joseph Salowey cc: galb-list@vandyke.com, jhutz@cmu.edu, lha@stacken.kth.se, ietf-ssh@NetBSD.org Subject: RE: gss userauth In-Reply-To: Message-ID: References: <024701c36b57$388912e0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 26 Aug 2003, Steven Michaud wrote: > Slightly off topic: Would it be reasonable to make gss userauth fail > if mutual authentication isn't available? Fail on the client, that is -- if the client called gss_init_sec_context() and ret_flags indicated mutual authentication wasn't supported. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 15:00: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 PAA22083 for ; Tue, 26 Aug 2003 15:00:26 -0400 (EDT) Received: (qmail 9568 invoked by uid 605); 26 Aug 2003 18:59:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9552 invoked from network); 26 Aug 2003 18:59:30 -0000 Received: from smtp1.su.se (130.237.162.112) by mail.netbsd.org with SMTP; 26 Aug 2003 18:59:30 -0000 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 0FEF038640 for ; Tue, 26 Aug 2003 20:59:29 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14331-03 for ; Tue, 26 Aug 2003 20:59:28 +0200 (CEST) Received: from nutcracker.stacken.kth.se (nutcracker.it.su.se [130.237.95.69]) by smtp1.su.se (Postfix) with ESMTP id AB3093807E for ; Tue, 26 Aug 2003 20:59:28 +0200 (CEST) Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id B6693F38B1; Tue, 26 Aug 2003 20:59:20 +0200 (CEST) To: ietf-ssh@NetBSD.org Subject: Re: gss userauth From: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> In-Reply-To: (lha@stacken.kth.se's message of "Fri, 22 Aug 2003 16:06:27 +0200") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) Date: Tue, 26 Aug 2003 20:59:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Virus-Scanned: by amavisd-new at su.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= Content-Transfer-Encoding: quoted-printable Love writes: > I've pointed out this to the authors privatly, so I'll repeat this > publicly. I consider gss userauth to be broken since it doesn't verify the > session id (using either mic or a channel bindings (like in CCM)). So I would like to propose adding the following text (marked with !) in 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly break backward compability because I think the problem is important enough to (possibly) break backward compability. I've had a long chat with Jeff Hutzelman, and the solution that he and Sam Hartmans are talking about might be better then mine. I'm proposing this for a simple alternative solution to the problem. Love 3.4 GSSAPI session [...] ! The client MUST use the integ_avail in calls to ! GSS_Init_sec_context() to request credential and verify the flag ! is set then the negotiation is done. [...] 3.5 Client acknowledgement It is possible for the server to successfully complete the GSSAPI method and the client to fail. If the server simply assumed success on the part of the client and completed the authentication service, it is possible that the client would fail to complete the authentication method, but not be able to retry other methods because the server had already moved on. Therefore, the client MUST send the following message when it has successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE: byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE ! string MIC This message MUST be sent if and only if GSS_Init_sec_context() returned GSS_S_COMPLETE. If a token is returned then the SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one. ! The MIC is the result of the gss_get_mic over the following data, in the ! following order: ! ! string session identifier ! byte SSH_MSG_USERAUTH_REQUEST ! string user name (in ISO-10646 UTF-8 encoding) ! string service name (in US-ASCII) ! string "gssapi" (US-ASCII method name) ! uint32 n, the number of mechanism OIDs client supports ! string[n] mechanism OIDs --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (NetBSD) iQEVAwUAP0uuCHW+NPVfDpmCAQKyeQf/UR9Oez5etsgUsir66NctSW2f7JnWThoA RylLBWWVbtYncmrWLi+/BZ5TUNzeK2pVHPuVk6YLRAimToJR4+eRnRxK6csFNDyH 7K3E4cMLeJkKjiHW1Cgf/8VFF5JpwQH9nBDYkZUFp9qy31KTZVKHCRyHyU6VUOTm zC2q+dxEV4HVNAmGq6z72CkDpyLWAibLI9opJFVfjugE29u/3RCzfPDdrxnG3djG F7LnsknwCGyeB3EN1pUJdMk+e2YHs/33o21u0N7WbioA3xx560eAX/Eqq6FNRwZN ryR1tuSv5j4yvHngljFvJuuKoodYhfIwAMMPS5PSauRnO9IvOyFGcg== =eDeA -----END PGP SIGNATURE----- --=-=-=-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 15:22:05 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 PAA27240 for ; Tue, 26 Aug 2003 15:22:04 -0400 (EDT) Received: (qmail 26182 invoked by uid 605); 26 Aug 2003 19:22:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26175 invoked from network); 26 Aug 2003 19:22:01 -0000 Received: from stratton-two-sixty-two.mit.edu (HELO konishi-polis.mit.edu) (18.187.6.7) by mail.netbsd.org with SMTP; 26 Aug 2003 19:22:01 -0000 Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 0BAF5152023; Tue, 26 Aug 2003 15:22:00 -0400 (EDT) To: =?iso-8859-1?q?Love_H=F6rnquist_=C5strand?= Cc: ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> From: Sam Hartman Date: Tue, 26 Aug 2003 15:22:00 -0400 In-Reply-To: ( =?iso-8859-1?q?Love_H=F6rnquist_=C5strand's_message_of?= "Tue, 26 Aug 2003 20:59:11 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>>> "Love" == Love Hörnquist Åstrand writes: Love> So I would like to propose adding the following text (marked Love> with !) in 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly Love> break backward compability because I think the problem is Love> important enough to (possibly) break backward compability. Not surprisingly, I'd prefer not to break backward compatibility. My reason is simple. I don't really see this as a new vulnerability so much as an apparent decision on the part of the WG to change the threat model. When we originally wrote this draft, we invisioned the GSSAPI userauth mechanism would be used with some mechanisms that did not support mutual authentication or integrity protection. The mechanism does as good of a job as it can for such cases. In such cases, GSSAPI tokens are like one-time passwords. We know that if an attacker manages to tunnel them or otherwise get ahold of the token before the token reaches the server (and the server's replay cache), then the token can be used by the attacker. It's reasonable for us to now decide that we want to expand the threat model and to forbid use of GSSAPI mechanisms that support integrity. It's also reasonable to allow mechanisms that do not support integrity, but to use the integrity protection when it is available. I'm happy with either of these decisions. But people have deployed code based on our previous approach. If they believe that there threat model is acceptable--if they believe that one-time-password style mechanisms are acceptable to them--then we should at least provide them an upgrade path. I don't actually have an opinion on whether we should allow GSSAPI mechanisms without integrity. I do strongly agree that we should move to an environment where integrity protection is better. --Sam From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 16:39: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 QAA07566 for ; Tue, 26 Aug 2003 16:39:56 -0400 (EDT) Received: (qmail 21138 invoked by uid 605); 26 Aug 2003 20:39:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21131 invoked from network); 26 Aug 2003 20:39:57 -0000 Received: from smtp2.su.se (130.237.93.212) by mail.netbsd.org with SMTP; 26 Aug 2003 20:39:57 -0000 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id B930E200208; Tue, 26 Aug 2003 22:39:55 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17144-01; Tue, 26 Aug 2003 22:39:55 +0200 (CEST) Received: from nutcracker.stacken.kth.se (nutcracker.it.su.se [130.237.95.69]) by smtp2.su.se (Postfix) with ESMTP id 9B549200127; Tue, 26 Aug 2003 22:39:55 +0200 (CEST) Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id 7B138F38B1; Tue, 26 Aug 2003 22:39:47 +0200 (CEST) To: Sam Hartman Cc: ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> From: Love Date: Tue, 26 Aug 2003 22:39:29 +0200 In-Reply-To: (Sam Hartman's message of "Tue, 26 Aug 2003 15:22:00 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Virus-Scanned: by amavisd-new at su.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= Content-Transfer-Encoding: quoted-printable Sam Hartman writes: > The mechanism does as good of a job as it can for such cases. In such > cases, GSSAPI tokens are like one-time passwords. We know that if an > attacker manages to tunnel them or otherwise get ahold of the token > before the token reaches the server (and the server's replay cache), > then the token can be used by the attacker. It could do better if it did channel bindings with session identifier in application data using GSS_C_AF_NULLADDRs. Then gss mechs without integrity support but with (in gss spec optional) channel binding support would not be vulnerable to tunneling. But then again, this (also) would break backward compability. Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (NetBSD) iQEVAwUAP0vFk3W+NPVfDpmCAQKW8ggAll3Ut2O9yEQrYG0Xh2Pfv/SpwrIuS9rp 8jGRa0Z/eRpzlHLS9/na4WgbFlr5h+ZXDuvdgKL/rY3AO69rKw1iyWcTsQgMhO9n gGbSF6hRjqyqP98fUFAhxsWDPCzr9W1y0pddrw69iTjwvSwFURHjSvvCUntDI+7l YLcbqJet0sRzXathsyCfHEzqUXNG7b8kHFEVCLTQAgJOLS7MC/xijJ+NsChv1auR FTJWPaCas/M76qX6ObBH43GQR6QIzNq3QS/NWPSIWaxdPwLAOzmjDnRPUTMmb6X/ nbHINx+vd1/OFEyaOjn4H9REsjOCyOM0FcDjCc9rJVvRZKYAdiAJ6g== =2KkP -----END PGP SIGNATURE----- --=-=-=-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 17:03:04 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 RAA09364 for ; Tue, 26 Aug 2003 17:03:04 -0400 (EDT) Received: (qmail 6966 invoked by uid 605); 26 Aug 2003 21:03:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6954 invoked from network); 26 Aug 2003 21:03:03 -0000 Received: from stratton-two-sixty-two.mit.edu (HELO konishi-polis.mit.edu) (18.187.6.7) by mail.netbsd.org with SMTP; 26 Aug 2003 21:03:03 -0000 Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 93717152023; Tue, 26 Aug 2003 17:02:58 -0400 (EDT) To: Love Cc: ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> From: Sam Hartman Date: Tue, 26 Aug 2003 17:02:58 -0400 In-Reply-To: (lha@stacken.kth.se's message of "Tue, 26 Aug 2003 22:39:29 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Love" == Love writes: Love> Sam Hartman writes: >> The mechanism does as good of a job as it can for such cases. >> In such cases, GSSAPI tokens are like one-time passwords. We >> know that if an attacker manages to tunnel them or otherwise >> get ahold of the token before the token reaches the server (and >> the server's replay cache), then the token can be used by the >> attacker. Love> It could do better if it did channel bindings with session Love> identifier in application data using GSS_C_AF_NULLADDRs. Love> Then gss mechs without integrity support but with (in gss Love> spec optional) channel binding support would not be Love> vulnerable to tunneling. It could do that. I wonder if it would work. I am sufficiently uncomfortable with GSS channel bindings to refrain from recommending their use until CCM becomes much more mature. Right now, I think that depending on channel bindings would delay our solution. If we believe we want to break backward compatability, I'd rather choose one of the other approaches. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 17:03:24 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 RAA09411 for ; Tue, 26 Aug 2003 17:03:23 -0400 (EDT) Received: (qmail 7392 invoked by uid 605); 26 Aug 2003 21:03:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7317 invoked from network); 26 Aug 2003 21:03:20 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 26 Aug 2003 21:03:20 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7QKxqZg016796; Tue, 26 Aug 2003 14:59:52 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7QKxqbO008497; Tue, 26 Aug 2003 14:59:52 -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 h7QKuKQx006265; Tue, 26 Aug 2003 13:56:20 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7QKuIrO006264; Tue, 26 Aug 2003 13:56:18 -0700 (PDT) Date: Tue, 26 Aug 2003 13:56:18 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org, "'Love'" Subject: Re: gss userauth Message-ID: <20030826205615.GA6247@binky.central.sun.com> References: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> <1304330000.1061594538@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1304330000.1061594538@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Aug 22, 2003 at 07:22:18PM -0400, Jeffrey Hutzelman wrote: > On Friday, August 22, 2003 14:41:38 -0700 Joseph Salowey > wrote: > > >I'm in favor of using channel bindings for this purpose. > > > >CCM could be one approach to do this. > >http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt > > > >At first glance it seems a little complex, but I need to actaully read > >the spec. > > CCM actually isn't what we want. It's a way of taking an app that uses > GSSAPI's integrity and/or encryption features, and a mechanism that > provides them, and essentially ripping out the mechanism's authentication > and encryption and replacing them with that provided by some lower-layer > protocol such as IPsec, on the theory that hardware acceleration is more > likely to be available there. We don't need that functionality -- we don't > ever use GSSAPI encryption features, and we currently send exactly one > integrity-protected message (during key exchange). Yes and no. Raw channel bindings would suffice for this purpose, so CCM is not applicable, but you could have used CCM (if it'd been available then and you'd really wanted to and you assumed channel bindings support everywhere). (CCM has other benefits besides leveraging IPsec HW acceleration, such as reducing the number of active crypto contexts needed on NFS file servers. But that's another story.) > I can think of two ways of doing this: > (1) Use GSSAPI channel bindings. Unfortunately, some mechanisms require > bindings to take a particular format, as described in RFC2744 section 3.11. > In our case, we would want to use address types of GSS_C_AF_NULLADDR, since > we very much do _not_ want to bind this authentication to network protocol > addresses (that would gain nothing, and make it not work through NAT's). > We could then include the session ID as "application data". Yes. But you can't do this now w/o breaking compatibility and not all GSS-API implementations, nor all mechanisms, for that matter, support channel bindings. > (2) Add an additional step in which the client is required to send a MIC of > the session ID before authentication can succeed. This is essentially the > same as what we do in key exchange, but in the reverse direction. This MIC can be sent as soon as the context is GSS_C_PROT_READY, on whichever side it's PROT_READY first. Though, it may be easiest to fit it into the last message from the client. > I find myself preferring option (2) for several reasons: > - By my reading, RFC2743 does not appear to actually require that GSSAPI > mechanisms _do_ anything with channel bindings. A mechanism could just > choose to ignore them. Right. > - RFC2743 _does_ allow mechanisms to require bindings to take a particular, > mechanism-dependent form. It does not specify what the behaviour might be > if the provided bindings are not in a format acceptable to the mechanism. We've seen this as a flaw in RFC2743 and the RFC2744/RFC1964 description has to be the standard. SPKM, for example, says nothing about how channel bindings are built, so CCM proposes that the rfc1964 construction be used with CCM. > - Some mechanism might be unable or unwilling to provide integrity > protection for channel bindings, and there is no way for them to signal > this to the application. While it may be the case that a mechanism cannot > support gss_get_mic, at least there is a flag to indicate that, and we can > write appropriate requirements. > - Using a separate message means we can maintain some amount of backward > compatibility for sites that have already deployed earlier versions of this > draft. Particularly, it allows for situations in which the client > implements the new message, but the server does not. Yep, and yep. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 17:14: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 RAA10516 for ; Tue, 26 Aug 2003 17:14:51 -0400 (EDT) Received: (qmail 14660 invoked by uid 605); 26 Aug 2003 21:14:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14653 invoked from network); 26 Aug 2003 21:14:52 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 26 Aug 2003 21:14:52 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa14371; 26 Aug 2003 17:14 EDT Date: Tue, 26 Aug 2003 17:14:28 -0400 From: Jeffrey Hutzelman To: Nicolas Williams cc: ietf-ssh@NetBSD.org, "'Love'" Subject: Re: gss userauth Message-ID: <2281740000.1061932468@minbar.fac.cs.cmu.edu> In-Reply-To: <20030826205615.GA6247@binky.central.sun.com> References: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> <1304330000.1061594538@minbar.fac.cs.cmu.edu> <20030826205615.GA6247@binky.central.sun.com> 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 Tuesday, August 26, 2003 13:56:18 -0700 Nicolas Williams wrote: >> (2) Add an additional step in which the client is required to send a MIC >> of the session ID before authentication can succeed. This is >> essentially the same as what we do in key exchange, but in the reverse >> direction. > > This MIC can be sent as soon as the context is GSS_C_PROT_READY, on > whichever side it's PROT_READY first. Though, it may be easiest to fit > it into the last message from the client. No; the direction actually matters. A MIC sent from the server to the client does not serve to bind the session to the client's identity, and thus does not solve the problem we are trying to address. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 17:16:16 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 RAA10656 for ; Tue, 26 Aug 2003 17:16:15 -0400 (EDT) Received: (qmail 15414 invoked by uid 605); 26 Aug 2003 21:16:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15407 invoked from network); 26 Aug 2003 21:16:17 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 26 Aug 2003 21:16:17 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1996588; Tue, 26 Aug 2003 15:16:16 -0600 Message-ID: <3F4BCE20.7010401@vandyke.com> Date: Tue, 26 Aug 2003 15:16:16 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Love , Joseph Salowey , ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <008901c36b19$aee40780$4d00a8c0@galb.vandyke.com> <1961590000.1061844207@minbar.fac.cs.cmu.edu> In-Reply-To: <1961590000.1061844207@minbar.fac.cs.cmu.edu> 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 Jeffrey Hutzelman wrote: > On Monday, August 25, 2003 09:00:54 -0600 Joseph Galbraith > wrote: > >> When we originally wrote the draft we talked about >> something like this but elected not to do it so that >> userauth wouldn't require integrity and mutual auth >> as the kex method does. > > What we're talking about now is similar, but different. The current > proposal is to require the _client_ to send the _server_ a MIC of the > session ID. This proves to the server that the client which has just > authenticated to it is the same client that started the ssh connection, > and not some intermediate attacker. I believe this is a real problem > and worth solving; I also believe there is a solution which is quite > trivial and does not break backward compatibility. Ah. I see the difference. >> In fact, to prevent downgrade attacks based on >> compatibility with old versions, we might want >> to define "gssapi-2", which is identical to >> "gssapi" in all ways, except that >> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE contains >> the MIC. > > I don't think it should actually be necessary to do this; it should be > sufficient to use a new final message in place of the existing one. A > new client would always send the new message, and fall back to sending > the old one if it gets a SSH_MSG_UNIMPLEMENTED. This isn't really a > "downgrade" as far as the client is concerned, since the only difference > is that the "old" version causes the client to send _less_ data. A new > server can choose to accept the old message or not, depending on a local > policy decision about a tradeoff between security and compatibility with > old clients. This approach gives us complete interoperability between > old and new implementations, except in the case where a new server > chooses not to support old clients for security reasons. Hmmm... I would still prefer to see a new auth method-- I think it is cleaner. SSH_MSG_UNIMPLEMENTED is clearly doable, but it is messy. Because SSH_MSG_UNIMPLEMENTED only includes the packet sequence number, telling exactly what was unimplemented is difficult at best. In retrospect, it would have been nice to include the packet type that was unimplemented in the UNIMPLEMENTED message. As long as all UNIMPLEMENTED messages are sent at mutually exclusive times, things aren't too bad, but... what if we do the kex init extension that has been kicked around. It isn't technically impossible for re-key to occur during user auth. Now, to support both of these, I have to start keeping a map of sequence-number to packet types sent so I can map back and figure out which packet I sent was unimplemented, so I know what to do about it. Now, the scenerio I've painted (re-key during userauth) is unlikely. But every time we depend on SSH_MSG_UNIMPLEMENTED, we increase the risk that we will run into a case where it will be unclear to the receiver of SSH_MSG_UNIMPLEMENTED which packet they sent was unimplemented. I think using SSH_MSG_UNIMPLEMENTED should be a last ditch solution. So I still prefer a new method name; we can define this method, and then include a note that "gssapi" is an obsolete method that differs only in it's last packet. I'm not sure about a name though. "gssapi-2" or "gssapi-mic" come to mind, but there might be better choices. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 17:25: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 RAA11134 for ; Tue, 26 Aug 2003 17:25:32 -0400 (EDT) Received: (qmail 20544 invoked by uid 605); 26 Aug 2003 21:25:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20534 invoked from network); 26 Aug 2003 21:25:34 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 26 Aug 2003 21:25:34 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7QLPSF6005296; Tue, 26 Aug 2003 14:25:33 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7QLPScm026280; Tue, 26 Aug 2003 15:25:28 -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 h7QLLtQx006286; Tue, 26 Aug 2003 14:21:55 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7QLLtlX006285; Tue, 26 Aug 2003 16:21:55 -0500 (CDT) Date: Tue, 26 Aug 2003 16:21:55 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org, "'Love'" Subject: Re: gss userauth Message-ID: <20030826212155.GL19235@binky.central.sun.com> References: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> <1304330000.1061594538@minbar.fac.cs.cmu.edu> <20030826205615.GA6247@binky.central.sun.com> <2281740000.1061932468@minbar.fac.cs.cmu.edu> <20030826212035.GL1319@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030826212035.GL1319@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 02:20:35PM -0700, Nicolas Williams wrote: > On Tue, Aug 26, 2003 at 05:14:28PM -0400, Jeffrey Hutzelman wrote: > > On Tuesday, August 26, 2003 13:56:18 -0700 Nicolas Williams > > wrote: > > > > >>(2) Add an additional step in which the client is required to send a MIC > > >>of the session ID before authentication can succeed. This is > > >>essentially the same as what we do in key exchange, but in the reverse > > >>direction. > > > > > >This MIC can be sent as soon as the context is GSS_C_PROT_READY, on > > >whichever side it's PROT_READY first. Though, it may be easiest to fit > > >it into the last message from the client. > > > > No; the direction actually matters. A MIC sent from the server to the > > client does not serve to bind the session to the client's identity, and > > thus does not solve the problem we are trying to address. > > Sure it does. If the client and server have established a GSS-API > security context then any MIC made with it will be bound to that > context and the initiator and/or acceptor names authenticated by the > context's establishment. Argh, sorry, you're right, the server needs to verify a MIC from the client to have the client prove that the context is bound to the session ID. My bad. Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 17:27:29 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 RAA11339 for ; Tue, 26 Aug 2003 17:27:29 -0400 (EDT) Received: (qmail 21709 invoked by uid 605); 26 Aug 2003 21:27:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21702 invoked from network); 26 Aug 2003 21:27:31 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 26 Aug 2003 21:27:31 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7QLO9Zg005289; Tue, 26 Aug 2003 15:24:09 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7QLO9bO017525; Tue, 26 Aug 2003 15:24:09 -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 h7QLKZQx006279; Tue, 26 Aug 2003 14:20:35 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7QLKZsZ006278; Tue, 26 Aug 2003 14:20:35 -0700 (PDT) Date: Tue, 26 Aug 2003 14:20:35 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org, "'Love'" Subject: Re: gss userauth Message-ID: <20030826212035.GL1319@binky.central.sun.com> References: <008801c368f6$2b5218f0$0200000a@amer.cisco.com> <1304330000.1061594538@minbar.fac.cs.cmu.edu> <20030826205615.GA6247@binky.central.sun.com> <2281740000.1061932468@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2281740000.1061932468@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 05:14:28PM -0400, Jeffrey Hutzelman wrote: > On Tuesday, August 26, 2003 13:56:18 -0700 Nicolas Williams > wrote: > > >>(2) Add an additional step in which the client is required to send a MIC > >>of the session ID before authentication can succeed. This is > >>essentially the same as what we do in key exchange, but in the reverse > >>direction. > > > >This MIC can be sent as soon as the context is GSS_C_PROT_READY, on > >whichever side it's PROT_READY first. Though, it may be easiest to fit > >it into the last message from the client. > > No; the direction actually matters. A MIC sent from the server to the > client does not serve to bind the session to the client's identity, and > thus does not solve the problem we are trying to address. Sure it does. If the client and server have established a GSS-API security context then any MIC made with it will be bound to that context and the initiator and/or acceptor names authenticated by the context's establishment. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 18:27:47 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 SAA16632 for ; Tue, 26 Aug 2003 18:27:46 -0400 (EDT) Received: (qmail 25868 invoked by uid 605); 26 Aug 2003 22:27:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25861 invoked from network); 26 Aug 2003 22:27:48 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 26 Aug 2003 22:27:48 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa14443; 26 Aug 2003 18:27 EDT Date: Tue, 26 Aug 2003 18:27:03 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <2310730000.1061936823@minbar.fac.cs.cmu.edu> In-Reply-To: References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Tuesday, August 26, 2003 20:59:11 +0200 Love H=F6rnquist =C5strand=20 wrote: > > Love writes: > >> I've pointed out this to the authors privatly, so I'll repeat this >> publicly. I consider gss userauth to be broken since it doesn't verify >> the session id (using either mic or a channel bindings (like in CCM)). > > So I would like to propose adding the following text (marked with !) in > 3.5 in draft-ietf-secsh-gsskeyex. I knowlingly break backward compability > because I think the problem is important enough to (possibly) break > backward compability. > > I've had a long chat with Jeff Hutzelman, and the solution that he and = Sam > Hartmans are talking about might be better then mine. I'm proposing this > for a simple alternative solution to the problem. I actually have two potential proposals. The first is a modification of=20 what Love just described, which could allow it to be deployed in a=20 backwards-compatible manner. However, it depends on existing server=20 implementations behaving properly when sent messages they don't understand=20 (i.e. they send SSH_MSG_UNIMPLEMENTED and otherwise do nothing).=20 Unfortunately, I think we've already demonstrated that we may not be able=20 to depend on existing implementations to handle this correctly in all=20 cases. I do find it saddening that even when we go out of our way to=20 provide a proper extensibility mechanism, it turns out to be pretty = useless. That said, I'm going to describe the solution that Love makes reference to=20 above. This idea was originally proposed by Sam Hartman; I've filled in a=20 few details and made some minor changes. Love thinks I should post some=20 actual text as it might appear in the draft; I'll try to do that later, but = I wanted to get the discussion rolling on this. I'd like to come to some=20 concensus on how to address this issue in the near future, so that it can=20 be incorporated in the next version of the draft. The basic idea is to define a new userauth method, which for the sake of=20 this discussion we'll call "gssapi-mic" (I know Joseph Galbraith just used=20 this name to describe something else, but I chose it first, so too bad).=20 The new method would consist of a single request message, containing the=20 usual method-independent fields and a MIC resulting from gss_getmic: byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-mic" string context-id string MIC MIC is obtained by calling gss_getmic over the following: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-mic" string context-id In these messages, context-id is a string identifying the particular GSSAPI = context to be used with gss_getmic and gss_verifymic to generate and verify = the MIC. For now, the string "userauth" means that the context used is=20 that established during the most recent exchange using the "gssapi"=20 userauth method which terminated with SSH_MSG_USERAUTH_FAILURE with the=20 partial success flag set. I'll describe another possible value later. A "new" server desiring to support GSS userauth with session id binding=20 should first advertise "gssapi" as a valid userauth method, as before.=20 Upon receiving the SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE message at the = end of a successful exchange, the server should return=20 SSH_MSG_USERAUTH_FAILURE with the partial success flag set, and include=20 "gssapi-mic" in the set of acceptable methods. A client supporting the new = protocol can then complete the authentication process using the gssapi-mic=20 method. This method provides complete compatibility between new clients and old=20 servers; with an old server, the gssapi method will simply return=20 SSH_MSG_USERAUTH_SUCCESS. It also allows new server implementations to=20 support old clients, by behaving as an old server would (return complete=20 success instead of partial success). A new server can also decide which=20 behaviour to use based on whether integrity is supported by the context;=20 this means it is possible to require the MIC with those GSSAPI mechanisms=20 which can support it, but still allow the use of mechanisms which do not. There is also an additional advantage to this approach, which is that the=20 same "gssapi-mic" userauth method can be used as an enhanced version of the = "external-keyx" method which provides better binding of the user's identity = to the session. In this usage, the context-id would be the string=20 "keyexchange", indicating that the GSSAPI context to be used is that=20 resulting from the successful gss-* key exchange used to establish the=20 session. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 19:11: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 TAA20021 for ; Tue, 26 Aug 2003 19:11:07 -0400 (EDT) Received: (qmail 22099 invoked by uid 605); 26 Aug 2003 23:11:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22092 invoked from network); 26 Aug 2003 23:11:09 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 26 Aug 2003 23:11:09 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1997414; Tue, 26 Aug 2003 17:11:07 -0600 Message-ID: <3F4BE90B.9070104@vandyke.com> Date: Tue, 26 Aug 2003 17:11:07 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> In-Reply-To: <2310730000.1061936823@minbar.fac.cs.cmu.edu> 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 > The basic idea is to define a new userauth method, which for the sake of > this discussion we'll call "gssapi-mic" (I know Joseph Galbraith just > used this name to describe something else, but I chose it first, so too I surrender the name to you :-) > bad). The new method would consist of a single request message, > containing the usual method-independent fields and a MIC resulting from > gss_getmic: > > byte SSH_MSG_USERAUTH_REQUEST > string user name > string service > string "gssapi-mic" > string context-id > string MIC I think this is a better proposal than mine. I like this-- I think it maintains the backward combatibility I need and fills the hole that Love pointed out quite nicely. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 22:34: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 WAA07851 for ; Tue, 26 Aug 2003 22:34:31 -0400 (EDT) Received: (qmail 20473 invoked by uid 605); 27 Aug 2003 02:34:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20445 invoked from network); 27 Aug 2003 02:34:28 -0000 Received: from adsl-68-78-101-70.dsl.emhril.ameritech.net (HELO flanders.mynet.net) (68.78.101.70) by mail.netbsd.org with SMTP; 27 Aug 2003 02:34:28 -0000 Received: from flanders.mynet.net (localhost [127.0.0.1]) by flanders.mynet.net (8.12.9/8.12.9) with ESMTP id h7R2YRYn001184 for ; Tue, 26 Aug 2003 21:34:27 -0500 (CDT) Received: from localhost (smichaud@localhost) by flanders.mynet.net (8.12.9/8.12.9/Submit) with ESMTP id h7R2YNpo001181 for ; Tue, 26 Aug 2003 21:34:27 -0500 (CDT) Date: Tue, 26 Aug 2003 21:34:23 -0500 (CDT) From: Steven Michaud X-X-Sender: smichaud@flanders.mynet.net To: ietf-ssh@NetBSD.org Subject: RE: gss userauth In-Reply-To: Message-ID: References: <024701c36b57$388912e0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 26 Aug 2003, Steven Michaud wrote: > I'm still not sure I've understood the MITM attacks you've > described. It turns out I _did_ misunderstand them, and that they _are_ a matter for concern. Sam Hartman's message to this list of 3:22 EDT today (8-26) was particularly useful in clearing up my misunderstanding. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Aug 26 23: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 XAA14120 for ; Tue, 26 Aug 2003 23:42:53 -0400 (EDT) Received: (qmail 3674 invoked by uid 605); 27 Aug 2003 03:42:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3666 invoked from network); 27 Aug 2003 03:42:54 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 27 Aug 2003 03:42:54 -0000 Received: by xanthine.gratuitous.org with local; Tue, 26 Aug 2003 23:42:52 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org In-reply-to: <2310730000.1061936823@minbar.fac.cs.cmu.edu> (message from Jeffrey Hutzelman on Tue, 26 Aug 2003 18:27:03 -0400) Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> Message-Id: Date: Tue, 26 Aug 2003 23:42:52 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I dislike the partial authentication approach. I believe it adds significant complexity to an implementation. If we don't want to rely on SSH_MSG_UNIMPLEMENTED, I'd be inclined to suggest that we consider the following: The spec starts with a set of a definition of messages SSH_MSG_USERAUTH_REQUEST, SSH_MSG_USERAUTH_GSSAPI_RESPONSE, SSH_MSG_USERAUTH_GSSAPI_TOKEN, SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, and SSH_MSG_USERAUTH_GSSAPI_MIC, plus the error messages that are currently defined. Then it would describe three userauth methods in terms of those messages: The gssapi userauth method uses the same set of messages it does now, for backwards compatibility and for methods that don't support integrity that someone someday might want to use for authentication. We add a new gssapi-mic userauth method, which is like gssapi but uses SSH_MSG_USERAUTH_GSSAPI_MIC instead of SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE. We define another new userauth method gssapi-keyex, which uses the context from key exchange, and involves the client sending SSH_MSG_USERAUTH_REQUEST followed by SSH_MSG_USERAUTH_GSSAPI_MIC. This probably makes it easier for code to continue to use the sorts of abstractions that code is likely to already be using (note that last I checked, openssh didn't support partial userauth at all), and it should be straightforward to share code between the userauth methods as needed. I'm willing to write up precise proposed text for this at some point tomorrow (probably fairly late in the day, realistically) if that would help. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 00:37: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 AAA19398 for ; Wed, 27 Aug 2003 00:37:41 -0400 (EDT) Received: (qmail 7709 invoked by uid 605); 27 Aug 2003 04:37:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7702 invoked from network); 27 Aug 2003 04:37:43 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 27 Aug 2003 04:37:43 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7R4bfFi029610; Tue, 26 Aug 2003 21:37:41 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7R4bfcm000455; Tue, 26 Aug 2003 22:37:41 -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 h7R4Y8Qx006638; Tue, 26 Aug 2003 21:34:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7R4Y8UY006637; Tue, 26 Aug 2003 21:34:08 -0700 (PDT) Date: Tue, 26 Aug 2003 21:34:07 -0700 From: Nicolas Williams To: Sam Hartman Cc: Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827043403.GA6628@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 03:22:00PM -0400, Sam Hartman wrote: > My reason is simple. I don't really see this as a new vulnerability > so much as an apparent decision on the part of the WG to change the > threat model. Not only that, there is an alternative that does the right thing: gsskeyex. I think a warning about gss userauth not being bound to the session ID and the resulting weakness, along with text explaining gss userauth's utility with gss mechs that don't provide integrity protection ought to suffice. We have other userauths that also don't bind authentication to the session ID (password, keyboard-interactive), so gss userauth's failure to bind authentication to the session ID is acceptable, particularly given that gsskeyex does (plus it has other benefits). Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 00:43:09 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 AAA19818 for ; Wed, 27 Aug 2003 00:43:08 -0400 (EDT) Received: (qmail 10365 invoked by uid 605); 27 Aug 2003 04:43:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10358 invoked from network); 27 Aug 2003 04:43:10 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 27 Aug 2003 04:43:10 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7R4h8F6020296; Tue, 26 Aug 2003 21:43:08 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7R4h7bO015655; Tue, 26 Aug 2003 22:43:08 -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 h7R4dZQx006647; Tue, 26 Aug 2003 21:39:35 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7R4dZj6006646; Tue, 26 Aug 2003 21:39:35 -0700 (PDT) Date: Tue, 26 Aug 2003 21:39:35 -0700 From: Nicolas Williams To: Sam Hartman Cc: Love , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827043935.GB6628@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 05:02:58PM -0400, Sam Hartman wrote: > >>>>> "Love" == Love writes: > > Love> Sam Hartman writes: > > >> The mechanism does as good of a job as it can for such cases. > >> In such cases, GSSAPI tokens are like one-time passwords. We > >> know that if an attacker manages to tunnel them or otherwise > >> get ahold of the token before the token reaches the server (and > >> the server's replay cache), then the token can be used by the > >> attacker. > > Love> It could do better if it did channel bindings with session > Love> identifier in application data using GSS_C_AF_NULLADDRs. > > Love> Then gss mechs without integrity support but with (in gss > Love> spec optional) channel binding support would not be > Love> vulnerable to tunneling. > > It could do that. I wonder if it would work. I am sufficiently > uncomfortable with GSS channel bindings to refrain from recommending > their use until CCM becomes much more mature. Why are you uncomfortable with GSS channel bindings? We know that they work, from experience, where they are supported. The lack of support for channel bindings across the board is definitely one good reason to be uncomfortable with using that facility to tackle this problem. > Right now, I think that depending on channel bindings would delay our > solution. If we believe we want to break backward compatability, I'd > rather choose one of the other approaches. On the argument that support for channel bindings is not pervasive I agree. But I'm not sure that we have to solve this problem since, after all, gss keyex does not have this problem and it is more useful that gss userauth anyways (for mechs that provide integrity protection services). We could just say that gss keyex is for mechs that provide mutual authentication and integrity services and gss userauth is for mechs that do not provide either or both of those. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 05:28: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 FAA10022 for ; Wed, 27 Aug 2003 05:28:20 -0400 (EDT) Received: (qmail 20928 invoked by uid 605); 27 Aug 2003 09:28:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20920 invoked from network); 27 Aug 2003 09:28:20 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 27 Aug 2003 09:28:20 -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 h7R9SG4Z028850; Wed, 27 Aug 2003 11:28:16 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id B202C2D003; Wed, 27 Aug 2003 11:27:55 +0200 (CEST) Date: Wed, 27 Aug 2003 11:27:55 +0200 From: Markus Friedl To: Nicolas Williams Cc: Sam Hartman , Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827092755.GA28045@folly> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043403.GA6628@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030827043403.GA6628@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 09:34:07PM -0700, Nicolas Williams wrote: > suffice. We have other userauths that also don't bind authentication to > the session ID (password, keyboard-interactive), so gss userauth's so both are weak forms of authentication. > failure to bind authentication to the session ID is acceptable, so gss userauth should be weak as well? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 10:49: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 KAA04171 for ; Wed, 27 Aug 2003 10:49:42 -0400 (EDT) Received: (qmail 22604 invoked by uid 605); 27 Aug 2003 14:49:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22581 invoked from network); 27 Aug 2003 14:49:41 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 27 Aug 2003 14:49:41 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7REncEJ014960; Wed, 27 Aug 2003 07:49:38 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7REnbbO001674; Wed, 27 Aug 2003 08:49:38 -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 h7REk5Qx006920; Wed, 27 Aug 2003 07:46:05 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7REk3OY006919; Wed, 27 Aug 2003 07:46:03 -0700 (PDT) Date: Wed, 27 Aug 2003 07:46:03 -0700 From: Nicolas Williams To: Markus Friedl Cc: Sam Hartman , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827144603.GZ1319@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043403.GA6628@binky.central.sun.com> <20030827092755.GA28045@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030827092755.GA28045@folly> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Aug 27, 2003 at 11:27:55AM +0200, Markus Friedl wrote: > On Tue, Aug 26, 2003 at 09:34:07PM -0700, Nicolas Williams wrote: > > suffice. We have other userauths that also don't bind authentication to > > the session ID (password, keyboard-interactive), so gss userauth's > > so both are weak forms of authentication. > > > failure to bind authentication to the session ID is acceptable, > > so gss userauth should be weak as well? It has to be weak in that way for mechanisms that don't provide integrity protection. For mechanisms that support integrity protection there is gss keyex, which does not have this weakness. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:43: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 MAA15118 for ; Wed, 27 Aug 2003 12:43:02 -0400 (EDT) Received: (qmail 6720 invoked by uid 605); 27 Aug 2003 16:43:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6712 invoked from network); 27 Aug 2003 16:43:01 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 27 Aug 2003 16:43:01 -0000 Received: by xanthine.gratuitous.org with local; Wed, 27 Aug 2003 12:42:51 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Sam Hartman , Love , ietf-ssh@NetBSD.org In-reply-to: <20030827043935.GB6628@binky.central.sun.com> (message from Nicolas Williams on Tue, 26 Aug 2003 21:39:35 -0700) Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> Message-Id: Date: Wed, 27 Aug 2003 12:42:51 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Why are you uncomfortable with GSS channel bindings? We know that they > work, from experience, where they are supported. The lack of support > for channel bindings across the board is definitely one good reason to > be uncomfortable with using that facility to tackle this problem. So, is there any deployed software anywhere that uses GSS channel bindings with krb5 gssapi? Or with gsi gssapi? If so, is there more than one independent implementation with demonstrated interoperability? I strongly believe we should pick an approach that involves the use of a MIC. And I also don't see that channel bindings really buy us anything. There are ways to do a MIC that will allow an old client to interoperate with a new server, and vice versa. Do channel bindings ever allow the problems to be solved without upgrading both the client and server? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:45: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 MAA15554 for ; Wed, 27 Aug 2003 12:45:56 -0400 (EDT) Received: (qmail 9029 invoked by uid 605); 27 Aug 2003 16:45:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9020 invoked from network); 27 Aug 2003 16:45:57 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 27 Aug 2003 16:45:57 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7RGhCkH000939; Wed, 27 Aug 2003 10:43:12 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RGhBbO029148; Wed, 27 Aug 2003 10:43:11 -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 h7RGddQx007043; Wed, 27 Aug 2003 09:39:39 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RGdcSc007042; Wed, 27 Aug 2003 09:39:38 -0700 (PDT) Date: Wed, 27 Aug 2003 09:39:38 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827163933.GA7036@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2310730000.1061936823@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 06:27:03PM -0400, Jeffrey Hutzelman wrote: > I actually have two potential proposals. The first is a modification of > what Love just described, which could allow it to be deployed in a > backwards-compatible manner. However, it depends on existing server > implementations behaving properly when sent messages they don't understand > (i.e. they send SSH_MSG_UNIMPLEMENTED and otherwise do nothing). > Unfortunately, I think we've already demonstrated that we may not be able > to depend on existing implementations to handle this correctly in all > cases. I do find it saddening that even when we go out of our way to > provide a proper extensibility mechanism, it turns out to be pretty useless. > > That said, I'm going to describe the solution that Love makes reference to > above. This idea was originally proposed by Sam Hartman; I've filled in a > few details and made some minor changes. Love thinks I should post some > actual text as it might appear in the draft; I'll try to do that later, but > I wanted to get the discussion rolling on this. I'd like to come to some > concensus on how to address this issue in the near future, so that it can > be incorporated in the next version of the draft. [description of new userauth and use of partial userauth failure removed] I approve of and support this additional userauth w/ gss userauth partial failure approach. I just posted on the openssh-dev-unix list about a simple partial userauth implementation. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:47: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 MAA15793 for ; Wed, 27 Aug 2003 12:47:01 -0400 (EDT) Received: (qmail 9752 invoked by uid 605); 27 Aug 2003 16:47:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9745 invoked from network); 27 Aug 2003 16:47:03 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 27 Aug 2003 16:47:03 -0000 Received: by xanthine.gratuitous.org with local; Wed, 27 Aug 2003 12:47:00 -0400 From: "Joel N. Weber II" To: Nicolas Williams cc: Sam Hartman , Love , ietf-ssh@NetBSD.org In-reply-to: (ietf-secsh@joelweber.com) Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> Message-Id: Date: Wed, 27 Aug 2003 12:47:00 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list So, what goals do we have in mind with changes to the spec? I think the requirements we have are basically: 1) stronger bindings 2) backwards compatibility 3) a preference toward ease of implementation I think we can get 1 and 2 quite easily using either a mic or channel bindings. I think 3 favors a mic, because it's not at all clear that channel bindings are particularily mature, and we don't want to have to create a lot of infrastructure to be able to solve this problem if there's a simpler fix. Nico, were there other goals you had in mind? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:53:14 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 MAA16685 for ; Wed, 27 Aug 2003 12:53:13 -0400 (EDT) Received: (qmail 13007 invoked by uid 605); 27 Aug 2003 16:53:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13000 invoked from network); 27 Aug 2003 16:53:15 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 27 Aug 2003 16:53:15 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7RGrBEJ019836; Wed, 27 Aug 2003 09:53:11 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RGrAcm019407; Wed, 27 Aug 2003 10:53:10 -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 h7RGncQx007055; Wed, 27 Aug 2003 09:49:38 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RGnb9S007054; Wed, 27 Aug 2003 09:49:37 -0700 (PDT) Date: Wed, 27 Aug 2003 09:49:37 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Sam Hartman , Love , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827164937.GI1319@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Aug 27, 2003 at 12:42:51PM -0400, Joel N. Weber II wrote: > > Why are you uncomfortable with GSS channel bindings? We know that they > > work, from experience, where they are supported. The lack of support > > for channel bindings across the board is definitely one good reason to > > be uncomfortable with using that facility to tackle this problem. > > So, is there any deployed software anywhere that uses GSS channel > bindings with krb5 gssapi? Or with gsi gssapi? If so, is there more > than one independent implementation with demonstrated > interoperability? MIT krb5's ftp/ftpd used to require the use of channel bindings using network addresses as the bindings. Of course, that created problems with NAT, but that's another story and wouldn't apply to this case. Did Heimdal ever support channel bindings? I don't know. There are also MIT-based implementations that interop with MIT. SSPI doesn't. > I strongly believe we should pick an approach that involves the use of > a MIC. Actually, I agree, not because of issues with channel bindings but because Jeff Hutzelman's proposal of using partial userauth with an additional userauth that has the client send the MIC is better, from a backwards compatibility point of view. > And I also don't see that channel bindings really buy us anything. > There are ways to do a MIC that will allow an old client to > interoperate with a new server, and vice versa. Do channel bindings > ever allow the problems to be solved without upgrading both the client > and server? I had already agreed that channel bindings wouldn't be the solution now - I was asking Sam why he was uncomfortable with channel bindings as I had the strong impression that he meant that generally, not specifically in this context (the quote was "I am sufficiently uncomfortable with GSS channel bindings to refrain from recommending their use until CCM becomes much more mature"). Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:56:09 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 MAA17150 for ; Wed, 27 Aug 2003 12:56:08 -0400 (EDT) Received: (qmail 15384 invoked by uid 605); 27 Aug 2003 16:55:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15363 invoked from network); 27 Aug 2003 16:55:41 -0000 Received: from dhcp-221-133.pdc.kth.se (HELO nutcracker.stacken.kth.se) (130.237.221.133) by mail.netbsd.org with SMTP; 27 Aug 2003 16:55:41 -0000 Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id ABAF3F3F7C; Wed, 27 Aug 2003 18:55:32 +0200 (CEST) To: Nicolas Williams Cc: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> From: Love Date: Wed, 27 Aug 2003 18:54:53 +0200 In-Reply-To: <20030827043935.GB6628@binky.central.sun.com> (Nicolas Williams's message of "Tue, 26 Aug 2003 21:39:35 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= Content-Transfer-Encoding: quoted-printable Nicolas Williams writes: >> It could do that. I wonder if it would work. I am sufficiently >> uncomfortable with GSS channel bindings to refrain from recommending >> their use until CCM becomes much more mature. > > Why are you uncomfortable with GSS channel bindings? We know that they > work, from experience, where they are supported. The lack of support > for channel bindings across the board is definitely one good reason to > be uncomfortable with using that facility to tackle this problem. How about adding a boolean flag to the gss exchange that the client sets to tell the server it used bindings. This way we don't need require channel bindings today. And servers can be configured to accept gss exchange that doesn't support integrity but channel binding. There is the issue how the server tells the client it needs to use channel bindings for that mech it just tried, but that I'm sure can be solved. Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (NetBSD) iQEVAwUAP0zihHW+NPVfDpmCAQIlTAgArCjh+yy2szuHAUsL/Prd2G5g9o1F4vQO YwXyaPolBdxF1ZfptD0lQnVaINHNZhRiaIXYJHdYsma07VHs0W1DaJEQLUeXeMs2 3jNn54Ii0VVjnKU/R7xdsY1V4cwZGPc3u2FcCyjQHZ93Ag2tprcxYBS/Lh6SKBAC djGKVDDWkFltym0emPSp6Qe4kmeNmOcaC+Gq0SinEZopnKpsO7LWEMiIk4tRgmty rEAR+hrTOUI0PiNM6oeP1l/uQXSVfC4/FiaDGvDFOmMBz3OtlEUgu0ImIDSuEW9x XdB/btiZEbvZ3P861HgESH0jHF4d5oig3GHjH8PBzQ7SVmJswF0Xqw== =Kz7a -----END PGP SIGNATURE----- --=-=-=-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:56: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 MAA17212 for ; Wed, 27 Aug 2003 12:56:32 -0400 (EDT) Received: (qmail 16223 invoked by uid 605); 27 Aug 2003 16:56:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16209 invoked from network); 27 Aug 2003 16:56:11 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 27 Aug 2003 16:56:11 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7RGu4vG000761; Wed, 27 Aug 2003 10:56:04 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RGu4bO006399; Wed, 27 Aug 2003 10:56:04 -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 h7RGqVQx007062; Wed, 27 Aug 2003 09:52:31 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RGqVei007061; Wed, 27 Aug 2003 09:52:31 -0700 (PDT) Date: Wed, 27 Aug 2003 09:52:31 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Sam Hartman , Love , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827165231.GJ1319@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Aug 27, 2003 at 12:47:00PM -0400, Joel N. Weber II wrote: > So, what goals do we have in mind with changes to the spec? I think > the requirements we have are basically: > > 1) stronger bindings > > 2) backwards compatibility > > 3) a preference toward ease of implementation > > I think we can get 1 and 2 quite easily using either a mic or channel > bindings. I think 3 favors a mic, because it's not at all clear that > channel bindings are particularily mature, and we don't want to have > to create a lot of infrastructure to be able to solve this problem if > there's a simpler fix. > > Nico, were there other goals you had in mind? Security. :) I don't think we can get all those goals with channel bindings _now_ - we could have, much earlier, but not now that implementations have been deployed. As it is I think Jeff's proposal (partial userauth + a new useruath that has the client send a GSS MIC) is the best approach that obtains all of these goals. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 12:58:51 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 MAA17439 for ; Wed, 27 Aug 2003 12:58:50 -0400 (EDT) Received: (qmail 18147 invoked by uid 605); 27 Aug 2003 16:58:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18137 invoked from network); 27 Aug 2003 16:58:52 -0000 Received: from dhcp-221-133.pdc.kth.se (HELO nutcracker.stacken.kth.se) (130.237.221.133) by mail.netbsd.org with SMTP; 27 Aug 2003 16:58:52 -0000 Received: by nutcracker.stacken.kth.se (Postfix, from userid 913) id 5EBB9F3F7C; Wed, 27 Aug 2003 18:58:45 +0200 (CEST) To: Nicolas Williams Cc: "Joel N. Weber II" , Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> <20030827164937.GI1319@binky.central.sun.com> From: Love Date: Wed, 27 Aug 2003 18:58:43 +0200 In-Reply-To: <20030827164937.GI1319@binky.central.sun.com> (Nicolas Williams's message of "Wed, 27 Aug 2003 09:49:37 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-=-= Content-Transfer-Encoding: quoted-printable Nicolas Williams writes: > Did Heimdal ever support channel bindings? I don't know. We do. Love --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (NetBSD) iQEVAwUAP0zjRXW+NPVfDpmCAQJzvwf+KMYc458Mf/ym96PHs2rxQbd3bz/M6qDf EYDM1iDaR/TO0QhcjQ8fZtN8hEoRAj+/X1CYn/2EXZY+ennqfzxOYogu91ShZvP6 aMEpYCHzPkKffsVlZgcvzmAQsUP0CWR0LnTB4XReGGtl+IG5TeR0ZaNQM6gttSvD H/CP3QNKSndv8++odXu6DM5aXBzmbjtC3GSEYJcRcG773P6EfV8XA5NgpVBx2QSu T53S/oQ7oBBFUg6PmIQWiIURzgJ7sxqEwaAljMiRWVcHXp7ZMAsJc/WwPkmk2BDX W7zua2Swv/GaygeDRE6ljgBlsY9iUoS5Dk5ShTSPzD22+7EILvBXvg== =Lzf0 -----END PGP SIGNATURE----- --=-=-=-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 13:05:16 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 NAA17872 for ; Wed, 27 Aug 2003 13:05:15 -0400 (EDT) Received: (qmail 21364 invoked by uid 605); 27 Aug 2003 17:05:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21348 invoked from network); 27 Aug 2003 17:05:17 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 27 Aug 2003 17:05:17 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h7RH5HEJ000776; Wed, 27 Aug 2003 10:05:17 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RH5Gcm023957; Wed, 27 Aug 2003 11:05:16 -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 h7RH1iQx007081; Wed, 27 Aug 2003 10:01:44 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RH1hrf007080; Wed, 27 Aug 2003 10:01:43 -0700 (PDT) Date: Wed, 27 Aug 2003 10:01:43 -0700 From: Nicolas Williams To: Love Cc: ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827170143.GK1319@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Aug 27, 2003 at 06:54:53PM +0200, Love wrote: > > Nicolas Williams writes: > > >> It could do that. I wonder if it would work. I am sufficiently > >> uncomfortable with GSS channel bindings to refrain from recommending > >> their use until CCM becomes much more mature. > > > > Why are you uncomfortable with GSS channel bindings? We know that they > > work, from experience, where they are supported. The lack of support > > for channel bindings across the board is definitely one good reason to > > be uncomfortable with using that facility to tackle this problem. > > How about adding a boolean flag to the gss exchange that the client sets to > tell the server it used bindings. If we were starting from scratch we could just require the use of channel bindings and be done. (One can always build a pseudo-mech that supports channel bindings from one that does not but which does support integrity protection). As it is we can't introduce a channel bindings requirement, though we could introduce CCM to negotiate the use channel bindings. But even so Jeff's latest proposal sounds much easier to implement (to me) and blah blah blah (see my other posts today). > This way we don't need require channel bindings today. And servers can be > configured to accept gss exchange that doesn't support integrity but > channel binding. > > There is the issue how the server tells the client it needs to use channel > bindings for that mech it just tried, but that I'm sure can be solved. See CCM. CCM is a proposed pseudo-mechanism that enables negotiation of the use of channel bindings (it itself does not do the negotiation, but it allows protocols that negotiate GSS-API mechanisms to negotiate the use of channel bindings). http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 13:16: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 NAA19059 for ; Wed, 27 Aug 2003 13:16:33 -0400 (EDT) Received: (qmail 26433 invoked by uid 605); 27 Aug 2003 17:16:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26426 invoked from network); 27 Aug 2003 17:16:36 -0000 Received: from konishi-polis.mit.edu (18.18.3.10) by mail.netbsd.org with SMTP; 27 Aug 2003 17:16:36 -0000 Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1212B151CEC; Wed, 27 Aug 2003 13:16:29 -0400 (EDT) To: Love Cc: Nicolas Williams , ietf-ssh@NetBSD.org Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <20030827043935.GB6628@binky.central.sun.com> From: Sam Hartman Date: Wed, 27 Aug 2003 13:16:29 -0400 In-Reply-To: (lha@stacken.kth.se's message of "Wed, 27 Aug 2003 18:54:53 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Love" == Love writes: Love> Nicolas Williams writes: >>> It could do that. I wonder if it would work. I am >>> sufficiently uncomfortable with GSS channel bindings to >>> refrain from recommending their use until CCM becomes much >>> more mature. >> Why are you uncomfortable with GSS channel bindings? We know >> that they work, from experience, where they are supported. The >> lack of support for channel bindings across the board is >> definitely one good reason to be uncomfortable with using that >> facility to tackle this problem. Love> How about adding a boolean flag to the gss exchange that the Love> client sets to tell the server it used bindings. Love> This way we don't need require channel bindings today. And Love> servers can be configured to accept gss exchange that Love> doesn't support integrity but channel binding. We can do anything we can get with channel bindings with a MIC. Why are we going down the channel bindings rathole? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Aug 27 13:24: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 NAA19602 for ; Wed, 27 Aug 2003 13:24:05 -0400 (EDT) Received: (qmail 1299 invoked by uid 605); 27 Aug 2003 17:24:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1289 invoked from network); 27 Aug 2003 17:24:07 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 27 Aug 2003 17:24:07 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7RHO4vG009705; Wed, 27 Aug 2003 11:24:04 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7RHO4cm000163; Wed, 27 Aug 2003 11:24:04 -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 h7RHKVQx007108; Wed, 27 Aug 2003 10:20:31 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h7RHKVRM007107; Wed, 27 Aug 2003 10:20:31 -0700 (PDT) Date: Wed, 27 Aug 2003 10:20:31 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org Subject: Re: gss userauth Message-ID: <20030827172030.GB7036@binky.central.sun.com> References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Aug 26, 2003 at 11:42:52PM -0400, Joel N. Weber II wrote: > I dislike the partial authentication approach. I believe it adds > significant complexity to an implementation. I disagree. First off, partial userauth is generally supported on the client side. Second, if you look at OpenSSH you'll see that it makes the list of userauth methods to offer to the client by pulling into the list all enabled userauth methods. You can see that manipulating the list of methods that will be produced on partial failure is easy: just manipulate the per-userauth method enabled/disabled flag. Partial failuer indication can be done by setting a flag on the userauth structure or by having a third value that can be returned by a method (failure, success, partial failure/success). (You may want to have to enabled/disabled flags: one to represent the configuration setting, the other to represent whether a method can be included in the list of methods that can continue after partial failure.) I think that some uses of partial userauth failure are easy to implement on the server side, others are not. This particular use of partial failure (Jeff's proposal) is easy to implement. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Aug 28 23:26: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 XAA18331 for ; Thu, 28 Aug 2003 23:26:54 -0400 (EDT) Received: (qmail 8355 invoked by uid 605); 29 Aug 2003 03:26:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8348 invoked from network); 29 Aug 2003 03:26:52 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 29 Aug 2003 03:26:52 -0000 Received: by xanthine.gratuitous.org with local; Thu, 28 Aug 2003 23:26:42 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: "Joel N. Weber II" , Jeffrey Hutzelman , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org In-reply-to: <20030827172030.GB7036@binky.central.sun.com> (message from Nicolas Williams on Wed, 27 Aug 2003 10:20:31 -0700) Subject: Re: gss userauth References: <200308212003.h7LK3BD9007282@thunk.east.sun.com> <2310730000.1061936823@minbar.fac.cs.cmu.edu> <20030827172030.GB7036@binky.central.sun.com> Message-Id: Date: Thu, 28 Aug 2003 23:26:42 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list So, having actually implemented the partial userauth approach so I could decide how painful it was, I've concluded that I don't really object to it. I'm not sure exactly where that leaves us on trying to reach consensus. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 00:01:10 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 AAA21753 for ; Fri, 29 Aug 2003 00:01:09 -0400 (EDT) Received: (qmail 29716 invoked by uid 605); 29 Aug 2003 04:01:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29708 invoked from network); 29 Aug 2003 04:01:11 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 29 Aug 2003 04:01:11 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa12285; 29 Aug 2003 0:00 EDT Date: Fri, 29 Aug 2003 00:00:44 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: Nicolas Williams , Love =?unknown-8bit?Q?H=F6rnquist_=C5strand?= , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: gss userauth In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 28 Aug 2003, Joel N. Weber II wrote: > So, having actually implemented the partial userauth approach so I > could decide how painful it was, I've concluded that I don't really > object to it. > > I'm not sure exactly where that leaves us on trying to reach > consensus. Since I am not the chair, my judgement doesn't really count. However, I think it makes us pretty close. I believe you were the only person advocating a different approach to addressing this without breaking backward compatibility. Given that, I will work up some specific text describing this approach, send it to the list, and prepare the next version of the draft for submission over the weekend. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 01:00:04 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 BAA26542 for ; Fri, 29 Aug 2003 01:00:03 -0400 (EDT) Received: (qmail 8718 invoked by uid 605); 29 Aug 2003 05:00:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8704 invoked from network); 29 Aug 2003 05:00:04 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 29 Aug 2003 05:00:04 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id 62AC37FD07; Fri, 29 Aug 2003 07:59:59 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id 602B17FD06; Fri, 29 Aug 2003 07:59:59 +0300 (EEST) Date: Fri, 29 Aug 2003 07:59:59 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@NetBSD.org Cc: Joseph Salowey , "'Steve Suehring'" Subject: RE: secsh-sftp-scp-uri draft In-Reply-To: <004701c367a5$00ba9b00$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 20 Aug 2003, Joseph Salowey wrote: > > > 4. Multiple host key algorithms and fingerprints > > > > I'd like to see fingerprints removed from the draft. I think > > it's calling > > for trouble in a way of man-in-the-middle or impersonation attacks. > > > > [Joe] Don't think that fingerprints in the URI make these problems any > worse. I think they can actually help. If I receive a URL in a signed > email from someone that I know I can rely on the fact that the > fingerprint is accurate. If I have a web page with a list of SSH URLs > that is delivered over a secure connection from a trusted source then > the fingerprints in the URIs are very useful. If the finger print > doesn't match then I know there is a problem (see below). Both e-mail and web page could have the fingerprint next to the URL. Maybe it could be easier to just click the link, but again, is it worth it? The trust is very hard to get right, especially when jumping from the domain of email client or web browser. What about SSH clients, would the client have to keep list of applications it trusts to pass trusted URLs? Do you trust all the SSL certificates to hand out SSH fingerprints? I wouldn't. Same goes for e-mail, I'd probably end up verifying the sender by hand and then deciding whether I trust a fingerprint or not. I'm a strong advocate of KISS, and here I just don't see the justification for this feature. Remeber the hulabaloo over dsniff and SSH MITM attacks? I think inclusion of fingerprints in URL's has greater potential to lead into similiar issues. I see your point about negative matches in URL vs. actual host key, but it could have problems as well: What if I happen to give a fingerprint that is for dsa key and client/server agree on rsa key? Links can become stale either by hostkey updates or different kex algorithms. I fear users might get a false sense of security from the information. The idea itself is not bad, but I'm worried it's very difficult to get right. Complexity is potential for trouble, and I'm not convinced it's worth it in this case. For what it's worth, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 11:20: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 LAA02123 for ; Fri, 29 Aug 2003 11:20:32 -0400 (EDT) Received: (qmail 22775 invoked by uid 605); 29 Aug 2003 15:20:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22768 invoked from network); 29 Aug 2003 15:20:34 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 29 Aug 2003 15:20:34 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7TFKRba017268; Fri, 29 Aug 2003 08:20:28 -0700 (PDT) Received: from jsaloweyw2k01 ([10.21.82.204]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Aug 2003 08:24:42 -0700 From: "Joseph Salowey" To: "'Heikki Nousiainen'" , Cc: "'Steve Suehring'" Subject: RE: secsh-sftp-scp-uri draft Date: Fri, 29 Aug 2003 08:20:26 -0700 Message-ID: <009a01c36e41$1357da00$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 29 Aug 2003 15:24:42.0525 (UTC) FILETIME=[AB78B4D0:01C36E41] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Heikki Nousiainen > Sent: Thursday, August 28, 2003 10:00 PM > To: ietf-ssh@NetBSD.org > Cc: Joseph Salowey; 'Steve Suehring' > Subject: RE: secsh-sftp-scp-uri draft > > > On Wed, 20 Aug 2003, Joseph Salowey wrote: > > > > 4. Multiple host key algorithms and fingerprints > > > > > > I'd like to see fingerprints removed from the draft. I think > > > it's calling > > > for trouble in a way of man-in-the-middle or > impersonation attacks. > > > > > > > [Joe] Don't think that fingerprints in the URI make these > problems any > > worse. I think they can actually help. If I receive a URL in a > > signed email from someone that I know I can rely on the > fact that the > > fingerprint is accurate. If I have a web page with a list > of SSH URLs > > that is delivered over a secure connection from a trusted > source then > > the fingerprints in the URIs are very useful. If the finger print > > doesn't match then I know there is a problem (see below). > > Both e-mail and web page could have the fingerprint next to > the URL. Maybe > it could be easier to just click the link, but again, is it > worth it? The > trust is very hard to get right, especially when jumping from > the domain > of email client or web browser. What about SSH clients, would > the client > have to keep list of applications it trusts to pass trusted URLs? > [Joe] I agree that the concept of trusted URLs cannot be easily determined or defined. > Do you trust all the SSL certificates to hand out SSH fingerprints? I > wouldn't. Same goes for e-mail, I'd probably end up verifying > the sender > by hand and then deciding whether I trust a fingerprint or not. I'm a > strong advocate of KISS, and here I just don't see the > justification for > this feature. Remeber the hulabaloo over dsniff and SSH MITM > attacks? I > think inclusion of fingerprints in URL's has greater > potential to lead > into similiar issues. > > I see your point about negative matches in URL vs. actual > host key, but > it could have problems as well: What if I happen to give a > fingerprint > that is for dsa key and client/server agree on rsa key? [Joe] If the fingerprint does not match for any reason then the reccomentation is to disallow the connection by default. > Links > can become > stale either by hostkey updates or different kex algorithms. > I fear users > might get a false sense of security from the information. > [Joe] A stale link will have the wrong fingerprint and they will not be able to make a connection. > The idea itself is not bad, but I'm worried it's very > difficult to get > right. Complexity is potential for trouble, and I'm not > convinced it's > worth it in this case. > [Joe] I think I understand your point and we debated this decided to include it in the draft because we believe it has value. I need to rework the security considerations section to remove the 'trusted URL' reference because that was a bad idea and focus more on the recommended behavior of the client. My hope is that will simplify things. > > For what it's worth, > Heikki Nousiainen > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 11:32:25 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 LAA03336 for ; Fri, 29 Aug 2003 11:32:24 -0400 (EDT) Received: (qmail 1448 invoked by uid 605); 29 Aug 2003 15:32:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1441 invoked from network); 29 Aug 2003 15:32:27 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 29 Aug 2003 15:32: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 LAA03308; Fri, 29 Aug 2003 11:32:18 -0400 (EDT) Message-Id: <200308291532.LAA03308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: netconf@ops.ietf.org, ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wasserman-netconf-over-ssh-00.txt Date: Fri, 29 Aug 2003 11:32:18 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the NETCONF Configuration Protocol over Secure Shell (SSH) Author(s) : M. Wasserman Filename : draft-wasserman-netconf-over-ssh-00.txt Pages : 16 Date : 2003-8-29 This document describes a simple method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session. Some features of the NETCONF protocol are not suited for use in a single shell session, and those limitations are described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wasserman-netconf-over-ssh-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-wasserman-netconf-over-ssh-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-wasserman-netconf-over-ssh-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-8-29113626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wasserman-netconf-over-ssh-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wasserman-netconf-over-ssh-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113626.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 12:09: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 MAA08217 for ; Fri, 29 Aug 2003 12:09:48 -0400 (EDT) Received: (qmail 23115 invoked by uid 605); 29 Aug 2003 16:09:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23106 invoked from network); 29 Aug 2003 16:09:50 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 29 Aug 2003 16:09:50 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h7TG9nqe012639; Fri, 29 Aug 2003 10:09:49 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7TG9ntK012077; Fri, 29 Aug 2003 12:09:49 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7TG9mD9024526; Fri, 29 Aug 2003 12:09:48 -0400 (EDT) Message-Id: <200308291609.h7TG9mD9024526@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org cc: Margaret Wasserman Subject: Re: I-D ACTION:draft-wasserman-netconf-over-ssh-00.txt In-Reply-To: Your message of "Fri, 29 Aug 2003 11:32:18 EDT." <200308291532.LAA03308@ietf.org> Reply-to: sommerfeld@east.sun.com Date: Fri, 29 Aug 2003 12:09:48 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list FYI. Margaret asked me to review an earlier version of this document. It's out of scope for the secure shell wg, but could use some review from secure shell implementors.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 13:03: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 NAA14545 for ; Fri, 29 Aug 2003 13:03:45 -0400 (EDT) Received: (qmail 27543 invoked by uid 605); 29 Aug 2003 17:03:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27535 invoked from network); 29 Aug 2003 17:03:47 -0000 Received: from above.proper.com (208.184.76.39) by mail.netbsd.org with SMTP; 29 Aug 2003 17:03:47 -0000 Received: from [165.227.249.150] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TH3ggf090956; Fri, 29 Aug 2003 10:03:43 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200308291609.h7TG9mD9024526@thunk.east.sun.com> References: <200308291609.h7TG9mD9024526@thunk.east.sun.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 29 Aug 2003 10:04:57 -0700 To: sommerfeld@east.sun.com, ietf-ssh@NetBSD.org From: Paul Hoffman / VPNC Subject: Re: I-D ACTION:draft-wasserman-netconf-over-ssh-00.txt Cc: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ietf-ssh-owner@NetBSD.org Precedence: list At 12:09 PM -0400 8/29/03, Bill Sommerfeld wrote: >FYI. > >Margaret asked me to review an earlier version of this document. > >It's out of scope for the secure shell wg, but could use some review >from secure shell implementors.. > > - Bill Oddly, a second proposal was introduced at the same time: . It could probably use the same review. --Paul Hoffman, Director --VPN Consortium From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Aug 29 13:16: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 NAA15586 for ; Fri, 29 Aug 2003 13:16:30 -0400 (EDT) Received: (qmail 3357 invoked by uid 605); 29 Aug 2003 17:16:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3342 invoked from network); 29 Aug 2003 17:16:34 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 29 Aug 2003 17:16:34 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h7THGQ9D021425; Fri, 29 Aug 2003 10:16:26 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h7THGPtK026853; Fri, 29 Aug 2003 13:16:25 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h7THGPD9024739; Fri, 29 Aug 2003 13:16:25 -0400 (EDT) Message-Id: <200308291716.h7THGPD9024739@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC cc: ietf-ssh@NetBSD.org, Margaret Wasserman , lear@cisco.com, ted.goddard@windriver.com Subject: Re: I-D ACTION:draft-wasserman-netconf-over-ssh-00.txt In-Reply-To: Your message of "Fri, 29 Aug 2003 10:04:57 PDT." Reply-to: sommerfeld@east.sun.com Date: Fri, 29 Aug 2003 13:16:25 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Oddly, a second proposal was introduced at the same time: > . > It could probably use the same review. Indeed. Under the assumption that we'll end up with a combined proposal with elements of each document, I'd appreciate it if folks could review both documents and provide feedback to both sets of authors... - Bill