From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 2 12:35:18 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15018 for ; Sun, 2 Mar 2003 12:35:18 -0500 (EST) Received: (qmail 29777 invoked by uid 605); 2 Mar 2003 17:37:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29770 invoked from network); 2 Mar 2003 17:37:05 -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; 2 Mar 2003 17:37:05 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa13245; 2 Mar 2003 12:36 EST Date: Sun, 2 Mar 2003 12:36:51 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: core draft nits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list A few nits we may want/need to fix, as long as we're going to have to do another rev of the core drafts. * architecture, section 3.1 (Host Keys) > Each server host SHOULD have a host key. > [...} > If a host has keys at all, it MUST have at least one key using each > REQUIRED public key algorithm (currently DSS [FIPS-186]) How did these statements make it through? "MUST is for implementors"; we can't tell a server operator he must have a particular type of host key. We should instead be saying that implementations MUST support the required algorithm * transport, section 4.2 (Compression) Fails to specify that the initial compression algorithm MUST be "none". While this should be obvious, implementors need to know it in order to get the initial algorithm negotiation right, so IMNSHO it should be spelled out. * transport, section 4.3 (Encryption) Fails to specify that the initial encryption algorithm MUST be "none". Again, this should be obvious, but implementors need to know, so we should spell it out. The remaining issues all have to do with IANA considerations, and I feel that they must be addressed before the documents can be resubmitted to the IESG, if we want to avoid yet another round of editing and/or mass confusion on the part of the IANA. * transport, section 9.1 (Disconnection Message) Fails to specify the mechanism for assigning new disconnect reason codes. * connect, section 4.10 (Returning Exit Status) Defines a different extension mechanism for signal names than that used by every other name type used in the ssh protocol. It should use the same mechanism, with names containing an '@' to be delegated to the owner of the specified domain, and names not containing an '@' assigned by IETF concensus (possibly we can delegate some or all of that space to POSIX). IMHO we should resolve at least the first part of this issue now; the discussion of whether and how to delegate part or all of the IETF namespace can be deferred for the next round. * connect, section 6 (Encoding of Terminal Modes) Fails to specify the mechanism for assigning new terminal mode opcodes. * architecture, section 7 (IANA considerations) This section is good as far as it goes, but it fails to provide an exhaustive list of the registries which the IANA is expected to maintain. In addition, for each registry we need to provide a pointer to a complete list of the values to be registered initially. The following is what I believe to be a complete list of registries to be created. For those registries for which there is not already a complete list of values in one of the core drafts, I have included one here. - message numbers (architecture, section 6; listed there) - compression methods (transport, section 4.2; listed there) - encryption algorithms (transport, section 4.3; listed there) - MAC algorithms (transport, section 4.4; listed there) - key exchange methods (transport, section 4.5; listed there) - public key algorithms (transport, section 4.6; listed there) - service names (transport, section 8; listed there) - disconnect reason codes (transport, section 9.1; listed there) - user authentication methods (userauth, section 2): + "none" (2.3) + "publickey" (4) + "password" (5) + "hostbased" (6) - global requests (connect, section 2): + "tcpip-forward" (5.1) + "cancel-tcpip-forward" (5.1) - channel types (connect, section 3.1) + "session" (4) + "x11" (4.3.2) + "forwarded-tcpip" (5.2) + "direct-tcpip" (5.2) - channel requests for the "session" channel (connect, section 4): + "pty-req" (4.2) + "x11-req" (4.3.1) + "env" (4.4) + "shell" (4.5) + "exec" (4.5) + "subsystem" (4.5) + "window-change" (4.7) + "xon-xoff" (4.8) + "signal" (4.9) + "exit-status" (4.10) + "exit-signal" (4.10) - subsystem names (connect, section 4.5; none currently defined) - terminal mode opcodes (connect, section 6; listed there) -- 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 Sun Mar 2 20:17:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22753 for ; Sun, 2 Mar 2003 20:17:51 -0500 (EST) Received: (qmail 10267 invoked by uid 605); 3 Mar 2003 01:19:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10259 invoked from network); 3 Mar 2003 01:19:46 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 3 Mar 2003 01:19:46 -0000 Received: from extremenetworks.com (unknown [10.0.8.90]) by gnat.inet.org (Postfix) with ESMTP id AF4D367108; Sun, 2 Mar 2003 20:34:00 -0500 (EST) Date: Sun, 2 Mar 2003 20:19:28 -0500 Subject: Re: core draft nits Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-ssh@netbsd.org To: Jeffrey Hutzelman From: RJ Atkinson In-Reply-To: Message-Id: <2DEB42CE-4D16-11D7-B842-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Sunday, Mar 2, 2003, at 12:36 America/Montreal, Jeffrey Hutzelman wrote: > * architecture, section 3.1 (Host Keys) >> Each server host SHOULD have a host key. >> [...} >> If a host has keys at all, it MUST have at least one key using each >> REQUIRED public key algorithm (currently DSS [FIPS-186]) > > How did these statements make it through? "MUST is for > implementors"; > we can't tell a server operator he must have a particular type of > host > key. We should instead be saying that implementations MUST support > the > required algorithm Wrong fix. If we ended up with more than one algorithm, your proposed fix might not support all algorithms concurrently due to lack of key storage space in an implementation. Implementations MUST be capable of having at least one key for each REQUIRED public key algorithm at any given time and MUST have some method for the user/operator to configure that key. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 3 09:19:43 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26479 for ; Mon, 3 Mar 2003 09:19:42 -0500 (EST) Received: (qmail 800 invoked by uid 605); 3 Mar 2003 14:21:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 625 invoked from network); 3 Mar 2003 14:21:14 -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; 3 Mar 2003 14:21:14 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa15514; 3 Mar 2003 9:20 EST Date: Mon, 3 Mar 2003 09:20:57 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: RJ Atkinson cc: ietf-ssh@netbsd.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: core draft nits In-Reply-To: <2DEB42CE-4D16-11D7-B842-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, 2 Mar 2003, RJ Atkinson wrote: > Wrong fix. If we ended up with more than one algorithm, your proposed > fix might not support all algorithms concurrently due to lack of key > storage space in an implementation. > > Implementations MUST be capable of having at least one key for each > REQUIRED public key algorithm at any given time and MUST have some > method for the user/operator to configure that key. Yes, your text definitely works better. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 7 06:54:27 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21551 for ; Fri, 7 Mar 2003 06:54:27 -0500 (EST) Received: (qmail 2328 invoked by uid 605); 7 Mar 2003 11:56:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2321 invoked from network); 7 Mar 2003 11:56:28 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Mar 2003 11:56:28 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21532; Fri, 7 Mar 2003 06:54:22 -0500 (EST) Message-Id: <200303071154.GAA21532@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-gsskeyex-06.txt Date: Fri, 07 Mar 2003 06:54:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : 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 The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [2] provides security services to callers in a mechanism-independent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.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-gsskeyex-06.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-gsskeyex-06.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-3-6125422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125422.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 13 14:43:32 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14805 for ; Thu, 13 Mar 2003 14:43:31 -0500 (EST) Received: (qmail 26983 invoked by uid 605); 13 Mar 2003 19:45:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26972 invoked from network); 13 Mar 2003 19:45:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 13 Mar 2003 19:45:34 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1371667; Thu, 13 Mar 2003 12:45:32 -0700 Message-ID: <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: , Cc: , References: <200302210212.h1L2Cbaj006356@thunk.east.sun.com> Subject: Re: IESG feedback on core drafts. Date: Thu, 13 Mar 2003 12:45:55 -0700 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Well, I'm not sure if this is what we need or not, but here is my first stab-- Here is the current Security Considerations section from the transport draft. > This protocol provides a secure encrypted channel over an insecure > network. It performs server host authentication, key exchange, > encryption, and integrity protection. It also derives a unique > session id that may be used by higher-level protocols. > > It is expected that this protocol will sometimes be used without > insisting on reliable association between the server host key and the > server host name. Such use is inherently insecure, but may be > necessary in non-security critical environments, and still provides > protection against passive attacks. However, implementors of > protocols running on top of this protocol should keep this > possibility in mind. > > This protocol is designed to be used over a reliable transport. If > transmission errors or message manipulation occur, the connection is > closed. The connection SHOULD be re-established if this occurs. > Denial of service attacks of this type ("wire cutter") are almost > impossible to avoid. > > The protocol was not designed to eliminate covert channels. For > example, the padding, SSH_MSG_IGNORE messages, and several other > places in the protocol can be used to pass covert information, and > the recipient has no reliable way to verify whether such information > is being sent. Here is my proposed revision: 11. Security Considerations This protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. 11.1 Confidentiality This protocol does allow the encryption mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" method is enabled. So long as the "none" cipher is not used, this protocol provides confidentiality. Older, smaller ciphers, such as 3des and arcfour MAY be less secure from attack than ciphers such as AES. Implementors SHOULD prefer ciphers such as twofish, serpent, or AES over blowfish, 3des and arcfour. 11.2 Data Integrity This protocol does allow the Data Integrity mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" mac is enabled. So long as the "none" mac is not used, this protocol provides data integrity. 11.3 Replay This protocol binds each session key to the session by including random data that is specific to the session in the hash used to produce session keys. This session id is used by higher level protocols to prevent replay of packets form previous sessions. In addition, the use of cipher chaining prevents replay of packets within the session. Cipher chaining also prevents the insertion or deletion of packets. 11.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure for distributing public keys. It is expected that this protocol will sometimes be used without insisting on reliable association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This vulnerability to man-in-the-middle attacks can be mitigated in several fashions: 1. Narrow the window. If the client ensures that the host key for a given server remains consistant, an attacker must execute the man-in-the-middle attack on the _first_ connection to a given server. 2. Use an authentication method that is not vulnerable to man-in-the-middle. For example, public-key authentication is not vulnerable to man-in-the-middle attack, because the signature is made across data that is session specific. The attack can not use the signature he receives because the session specific data between the attacker and server is different, and can not create a valid signature because he does not have the private key. 3. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, storing the hostkey fingerprint in a secure dns database, or using kerberos over gssapi during keyexchange to authenticate the server. Use of this protocol without reliable association is inherently insecure, but may be necessary in non-security critical environments, and still provides protection against passive attacks. However, implementors of protocols running on top of this protocol should keep this possibility in mind. 11.5 Denial-of-service This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid. In addition, this protocol is vulnerable to Denial of Service attack because an attacker can force the server to go through the CPU and memory intensive tasks of connection setup and key exchange without authenticating. Implementors SHOULD provide features that make this more difficult. For example, only allowing connections from a subset of IPs known to have valid users. 11.6 Covert Channels The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way to verify whether such information is being sent. ---- Is this what is needed, or am I way off track? Thanks, Joseph ----- Original Message ----- From: "Bill Sommerfeld" To: Cc: ; Sent: Thursday, February 20, 2003 19:12 Subject: IESG feedback on core drafts. > Some time ago I mentioned that the core drafts were being held up due > to concerns about the security considerations section. > > I've just gotten feedback from Steve Bellovin (security co-AD). > > He states that in his opinion, the security consideration section is > inadequate and should be rewritten along the lines described in > draft-iab-sec-cons-03.txt including: > > ".. a discussion of the limitations of the protocol, the > countermeasures, and the residual vulnerabilities. Looking just > at the architecture document, it says (in that section) nothing > about the risks from users accepting unknown host keys. The > information is present in diffuse form in 3.1, but it isn't > spelled out clearly in one spot. A possible countermeasure would > be some way for a logged-in user to then verify the fingerprint, > in a way that a clever mitm proxy would find hard to > mimic. Similarly, the draft says little about the security of the > endpoint being important. It's not any one thing; it's that I'd > really like SEC-area documents to be better than average, and this > isn't up to the standards that I, at least, have been demanding of > documents from other areas." > > WG members interested in forward progress of the core drafts should > take the time to read draft-iab-sec-cons-03 and send suggested text to > the list.. > > - Bill > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 14 04:05:55 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19636 for ; Fri, 14 Mar 2003 04:05:55 -0500 (EST) Received: (qmail 14045 invoked by uid 605); 14 Mar 2003 09:08:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14037 invoked from network); 14 Mar 2003 09:08:01 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 14 Mar 2003 09:08:01 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18tlAH-0007V7-00; Fri, 14 Mar 2003 09:07:45 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.com> Subject: Re: IESG feedback on core drafts. Message-Id: Date: Fri, 14 Mar 2003 09:07:45 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joseph Galbraith wrote: > Here is my proposed revision: [...] > 11.4 Man-in-the-middle [...] > This vulnerability to man-in-the-middle attacks can > be mitigated in several fashions: [...] > 2. Use an authentication method that is not vulnerable > to man-in-the-middle. For example, public-key > authentication is not vulnerable to man-in-the-middle > attack, because the signature is made across data > that is session specific. It might be worth mentioning explicitly that this is assuming the solution of a similar key-distribution problem to the one which lays SSH open to MITM in the first place! Sure, if you've _already_ copied your public key to the server in a secure manner, then PK auth is a good way to defeat MITMs. But if you have _already_ had access to the server in a secure manner in order to do this, why didn't you just note down the host key fingerprint while you were there? Conversely, PK auth doesn't solve your problem if you've never made a secure connection to the server before, because your very first connection is vulnerable to MITM and so you can't guarantee that it's a safe channel through which to copy your public key to the server - a hypothetical MITM could rewrite the key on the way past and end up giving the server a public key of his own instead of yours. (Of course, this is not an issue if your problem is that you're connecting to a server you've used before from a new client machine which doesn't contain your existing host key database. But it isn't a cure-all, so in a section whose job is to state this sort of thing explicitly, perhaps it would be a good thing to mention.) Cheers, Simon -- Simon Tatham "That all men should be brothers is a dream of people who have no brothers." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 14 09:52:43 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26775 for ; Fri, 14 Mar 2003 09:52:43 -0500 (EST) Received: (qmail 11745 invoked by uid 605); 14 Mar 2003 14:54:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11738 invoked from network); 14 Mar 2003 14:54:47 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 14 Mar 2003 14:54:47 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id E30FC67107; Fri, 14 Mar 2003 10:11:07 -0500 (EST) Date: Fri, 14 Mar 2003 09:54:30 -0500 Subject: Re: IESG feedback on core drafts. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-ssh@netbsd.org To: Simon Tatham From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, Mar 14, 2003, at 04:07 America/Montreal, Simon Tatham wrote: > It might be worth mentioning explicitly that this is assuming the > solution of a similar key-distribution problem to the one which lays > SSH open to MITM in the first place! Generally speaking, the goal of the Security Considerations section ought to be to: - describe residual risks from use of this protocol, including potential implementation flaws. - describe methods that those residual risks might be mitigated, if such methods exist. - leave the reader of the document with a clear and accurate understanding of what the deployment risks are, so that an operator/user can make an informed decision about whether to deploy/use the technology in the RFC IMHO, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 14 09:56:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26901 for ; Fri, 14 Mar 2003 09:56:51 -0500 (EST) Received: (qmail 13705 invoked by uid 605); 14 Mar 2003 14:58:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13698 invoked from network); 14 Mar 2003 14:58:58 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 14 Mar 2003 14:58:58 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 18tqeA-0002h4-00; Fri, 14 Mar 2003 14:58:58 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: To: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-Id: Date: Fri, 14 Mar 2003 14:58:58 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list RJ Atkinson wrote: > Generally speaking, the goal of the Security Considerations section > ought to be to: [...] > - leave the reader of the document with a clear and accurate > understanding of what the deployment risks are, so that > an operator/user can make an informed decision about > whether to deploy/use the technology in the RFC Quite so. And hence, if PK authentication is a useful means of mitigating host key risks in some but not all situations, it seems important to the reader's clear and accurate understanding that they should be aware of which situations are which. Cheers, Simon -- Simon Tatham "I'm cross. I'm going to have a tantrum. How do I start?" - my uncle From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 16 01:47:58 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07185 for ; Sun, 16 Mar 2003 01:47:58 -0500 (EST) Received: (qmail 10970 invoked by uid 605); 16 Mar 2003 06:50:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10963 invoked from network); 16 Mar 2003 06:50:06 -0000 Received: from mail-red.research.att.com (192.20.225.110) by mail.netbsd.org with SMTP; 16 Mar 2003 06:50:06 -0000 Received: from bigmail.research.att.com (H-135-207-30-101.research.att.com [135.207.30.101]) by mail-red.research.att.com (Postfix) with ESMTP id D21791AB463; Sun, 16 Mar 2003 01:52:15 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h2G6o3L09011; Sun, 16 Mar 2003 01:50:03 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7EFEC7B6E; Sat, 15 Mar 2003 20:16:36 -0500 (EST) From: "Steven M. Bellovin" To: "Joseph Galbraith" Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org, jis@mit.edu, smb@research.att.com Subject: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Thu, 13 Mar 2003 12:45:55 MST." <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.com> Date: Sat, 15 Mar 2003 20:16:36 -0500 Message-Id: <20030316011636.7EFEC7B6E@berkshire.research.att.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list In message <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.com>, "Joseph Galbraith " writes: >Well, I'm not sure if this is what we need or not, but >here is my first stab-- > .... > >Is this what is needed, or am I way off track? > Very nice. There's one more point I want mentioned, aside from Bill's suggestions: a caveat about the dangers of using forwarding (of ports, X11, or the authentication agent) to machines that aren't trustworthy. (Some of that should, perhaps, be in -connect instead, since there's already related text.) One more thing, and this is probably my own experiences talking: suggest that implementations provide a simple way for a logged-in client to retrieve the fingerprint of the host's key, as well as the stored fingerprint. Furthermore, this should be done in a way that's hard for a MITM attacker to spoof. The idea is that sometimes, you log in to a new machine -- but then you'd like to verify that the key you just accepted indeed matches what's stored on the new machine. (Ideally, there's be something involving, say, the Interlock Protocol, but that's a job for a new document, not for Security Considerations in this one.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 16 19:02:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13580 for ; Sun, 16 Mar 2003 19:02:10 -0500 (EST) Received: (qmail 14316 invoked by uid 605); 17 Mar 2003 00:04:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14304 invoked from network); 17 Mar 2003 00:04:18 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 17 Mar 2003 00:04:18 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 6DBC417940; Sun, 16 Mar 2003 19:04:17 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2GJgsFJ001095; Sun, 16 Mar 2003 14:42:54 -0500 (EST) Message-Id: <200303161942.h2GJgsFJ001095@syn.hamachi.org> From: Bill Sommerfeld To: "Steven M. Bellovin" Cc: "Joseph Galbraith" , ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Sat, 15 Mar 2003 20:16:36 EST." <20030316011636.7EFEC7B6E@berkshire.research.att.com> Reply-To: sommerfeld@east.sun.com Date: Sun, 16 Mar 2003 14:42:54 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Very nice. There's one more point I want mentioned, aside from > Bill's suggestions: a caveat about the dangers of using forwarding > (of ports, X11, or the authentication agent) to machines that > aren't trustworthy. (Some of that should, perhaps, be in -connect > instead, since there's already related text.) So, I'm wondering if it might make more sense to have a single set of security considerations in the -arch draft, with pointers from the other three documents. Like most things security related, they cut across functional areas, and I really don't want to waste time trying to get all the hairs perfectly split. > One more thing, and this is probably my own experiences talking: > suggest that implementations provide a simple way for a logged-in > client to retrieve the fingerprint of the host's key, as well as > the stored fingerprint. Furthermore, this should be done in a > way that's hard for a MITM attacker to spoof. The idea is that > sometimes, you log in to a new machine -- but then you'd like to > verify that the key you just accepted indeed matches what's stored > on the new machine. (Ideally, there's be something involving, > say, the Interlock Protocol, but that's a job for a new document, > not for Security Considerations in this one.) Uhh.. my "mission creep" detector just went off... I've been reminded that there are several vendors who are waiting for these documents to come out as RFC's before casting an implementation into firmware. Steve: if you feel strongly that this belongs in the documents, can you provide sample text for this provision *this week*? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 16 19:08:16 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13649 for ; Sun, 16 Mar 2003 19:08:15 -0500 (EST) Received: (qmail 17681 invoked by uid 605); 17 Mar 2003 00:10:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17673 invoked from network); 17 Mar 2003 00:10:25 -0000 Received: from mail-red.research.att.com (192.20.225.110) by mail.netbsd.org with SMTP; 17 Mar 2003 00:10:25 -0000 Received: from bigmail.research.att.com (H-135-207-30-101.research.att.com [135.207.30.101]) by mail-red.research.att.com (Postfix) with ESMTP id 5AB3D1AB585; Sun, 16 Mar 2003 19:12:35 -0500 (EST) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h2H0ANL04643; Sun, 16 Mar 2003 19:10:23 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7BC4D7B4D; Sun, 16 Mar 2003 19:10:22 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: sommerfeld@east.sun.com Cc: "Joseph Galbraith" , ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Sun, 16 Mar 2003 14:42:54 EST." <200303161942.h2GJgsFJ001095@syn.hamachi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Mar 2003 19:10:22 -0500 Message-Id: <20030317001022.7BC4D7B4D@berkshire.research.att.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list In message <200303161942.h2GJgsFJ001095@syn.hamachi.org>, Bill Sommerfeld write s: >> Very nice. There's one more point I want mentioned, aside from >> Bill's suggestions: a caveat about the dangers of using forwarding >> (of ports, X11, or the authentication agent) to machines that >> aren't trustworthy. (Some of that should, perhaps, be in -connect >> instead, since there's already related text.) > >So, I'm wondering if it might make more sense to have a single set of >security considerations in the -arch draft, with pointers from the >other three documents. Like most things security related, they cut >across functional areas, and I really don't want to waste time >trying to get all the hairs perfectly split. Always a reasonable option. Will such a document appear in finite time? The IESG is not fond of approving documents that say "see the following non-existent RFC for security considerations" -- but has often approved documents that point to existing documents for that information. > >> One more thing, and this is probably my own experiences talking: >> suggest that implementations provide a simple way for a logged-in >> client to retrieve the fingerprint of the host's key, as well as >> the stored fingerprint. Furthermore, this should be done in a >> way that's hard for a MITM attacker to spoof. The idea is that >> sometimes, you log in to a new machine -- but then you'd like to >> verify that the key you just accepted indeed matches what's stored >> on the new machine. (Ideally, there's be something involving, >> say, the Interlock Protocol, but that's a job for a new document, >> not for Security Considerations in this one.) > >Uhh.. my "mission creep" detector just went off... > >I've been reminded that there are several vendors who are waiting for >these documents to come out as RFC's before casting an implementation >into firmware. > >Steve: if you feel strongly that this belongs in the documents, can >you provide sample text for this provision *this week*? > I'll try -- and if I don't, I won't object to you shipping it the week after. I'm certainly *not* suggesting that you design something based on the Interlock protocol now. In fact, I'd object you tried to... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 16 19:17:04 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13738 for ; Sun, 16 Mar 2003 19:17:03 -0500 (EST) Received: (qmail 23361 invoked by uid 605); 17 Mar 2003 00:19:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23348 invoked from network); 17 Mar 2003 00:19:11 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Mar 2003 00:19:11 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01809; Sun, 16 Mar 2003 16:19:01 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H0J0uK022926; Sun, 16 Mar 2003 19:19:00 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H0J0aj014266; Sun, 16 Mar 2003 19:19:00 -0500 (EST) Message-Id: <200303170019.h2H0J0aj014266@thunk.east.sun.com> From: Bill Sommerfeld To: "Steven M. Bellovin" cc: "Joseph Galbraith" , ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Sun, 16 Mar 2003 19:10:22 EST." <20030317001022.7BC4D7B4D@berkshire.research.att.com> Reply-to: sommerfeld@east.sun.com Date: Sun, 16 Mar 2003 19:19:00 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > >So, I'm wondering if it might make more sense to have a single set of > >security considerations in the -arch draft, with pointers from the > >other three documents. Like most things security related, they cut > >across functional areas, and I really don't want to waste time > >trying to get all the hairs perfectly split. > > Always a reasonable option. Will such a document appear in finite > time? The IESG is not fond of approving documents that say "see the > following non-existent RFC for security considerations" -- but has > often approved documents that point to existing documents for that > information. The -arch draft, draft-ietf-secsh-architecture-13.txt, is currently part of the core drafts hairball before the IESG at this moment. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 16 20:35:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15148 for ; Sun, 16 Mar 2003 20:35:02 -0500 (EST) Received: (qmail 4625 invoked by uid 605); 17 Mar 2003 01:37:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4428 invoked from network); 17 Mar 2003 01:36:58 -0000 Received: from mail-red.research.att.com (192.20.225.110) by mail.netbsd.org with SMTP; 17 Mar 2003 01:36:58 -0000 Received: from bigmail.research.att.com (H-135-207-30-101.research.att.com [135.207.30.101]) by mail-red.research.att.com (Postfix) with ESMTP id 9E7EF1AB585; Sun, 16 Mar 2003 20:39:09 -0500 (EST) Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h2H1avL09667; Sun, 16 Mar 2003 20:36:57 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 19DFC7B4D; Sun, 16 Mar 2003 20:36:56 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: sommerfeld@east.sun.com Cc: "Joseph Galbraith" , ietf-ssh@netbsd.org, jis@mit.edu Subject: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Sun, 16 Mar 2003 19:19:00 EST." <200303170019.h2H0J0aj014266@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Mar 2003 20:36:56 -0500 Message-Id: <20030317013656.19DFC7B4D@berkshire.research.att.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list In message <200303170019.h2H0J0aj014266@thunk.east.sun.com>, Bill Sommerfeld wr ites: >> >So, I'm wondering if it might make more sense to have a single set of >> >security considerations in the -arch draft, with pointers from the >> >other three documents. Like most things security related, they cut >> >across functional areas, and I really don't want to waste time >> >trying to get all the hairs perfectly split. >> >> Always a reasonable option. Will such a document appear in finite >> time? The IESG is not fond of approving documents that say "see the >> following non-existent RFC for security considerations" -- but has >> often approved documents that point to existing documents for that >> information. > >The -arch draft, draft-ietf-secsh-architecture-13.txt, >is currently part of the core drafts hairball before the IESG at this >moment. > Right, but currently the security considerations information is split across many different documents. You'd have to collect it in that one place -- which would be a good idea. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 17 04:05:38 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07514 for ; Mon, 17 Mar 2003 04:05:38 -0500 (EST) Received: (qmail 16247 invoked by uid 605); 17 Mar 2003 09:07:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16240 invoked from network); 17 Mar 2003 09:07:42 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 17 Mar 2003 09:07:42 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.8/8.12.8) with ESMTP id h2H97con008628; Mon, 17 Mar 2003 09:07:39 GMT Received: by localhost.arcor.net (Postfix, from userid 31451) id A9B6034107; Mon, 17 Mar 2003 09:34:09 +0100 (CET) Date: Mon, 17 Mar 2003 09:34:09 +0100 From: Markus Friedl To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030317083409.GC4201@folly> References: <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.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 Fri, Mar 14, 2003 at 09:07:45AM +0000, Simon Tatham wrote: > Conversely, PK auth doesn't solve your problem if you've never made > a secure connection to the server before, because your very first > connection is vulnerable to MITM and so you can't guarantee that > it's a safe channel through which to copy your public key to the > server - a hypothetical MITM could rewrite the key on the way past > and end up giving the server a public key of his own instead of > yours. as far as i understand pk auth with ssh v2, i think that pk auth allows you to detect MITM because in this case the authentication will always fail (as opposed to ssh v1). (but i could be too tired to get this right).... -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 17 09:32:14 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14222 for ; Mon, 17 Mar 2003 09:32:13 -0500 (EST) Received: (qmail 10903 invoked by uid 605); 17 Mar 2003 14:34:13 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 17 Mar 2003 14:34:13 -0000 Message-ID: <20030317143413.10902.qmail@mail.netbsd.org> Received: (qmail 10660 invoked from network); 17 Mar 2003 14:34:01 -0000 Received: from unknown (HELO macau.mbfax.com) (202.175.91.122) by mail.netbsd.org with SMTP; 17 Mar 2003 14:34:01 -0000 From: sales@mbfax.com To: ietf-ssh@netbsd.org From: "Man Bond Communications Limited" Subject: Own your Hong Kong Fax Line We found your company on cvs.openbsd.org's website and believe that our Hong Kong Fax Line service will assist your company to promote your products and services in Hong Kong. You will have your own fax number in Hong Kong to receive faxes and all faxes received will be converted into image files and forwarded to your email address. It is just like you have a virtual fax machine in Hong Kong. The monthly service charge is US$20.00 for unlimited fax receiving plus 200 free pages of fax sending to Hong Kong every month. Details can be found on http://www.mbfax.com/hk-faxline.html or email to info@mbfax.com We also provide Hong Kong telephone line service for your potential customers to contact you directly. Man Bond Communications Limited Phone : 852-2780-3257 Fax : 852-2385-2631 Webpage: http://www.mbfax.com Block F1, 13/F., Tuen Mun Industrial Centre No. 76, Pui To Road, Tuen Mun Hong Kong ********************************************************************* If you wish to be removed from our list, please return our email with Removal at the Subject: line. ********************************************************************* Sender: ietf-ssh-owner@netbsd.org Precedence: list From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 11:19:14 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15692 for ; Tue, 18 Mar 2003 11:19:13 -0500 (EST) Received: (qmail 16909 invoked by uid 605); 18 Mar 2003 16:21:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16902 invoked from network); 18 Mar 2003 16:21:23 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 18 Mar 2003 16:21:23 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29407 for ; Tue, 18 Mar 2003 09:21:22 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IGLLuK014827 for ; Tue, 18 Mar 2003 11:21:22 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IGLLaj022451 for ; Tue, 18 Mar 2003 11:21:21 -0500 (EST) Message-Id: <200303181621.h2IGLLaj022451@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Meeting WEDNESDAY 3:30pm Reply-to: sommerfeld@east.sun.com Date: Tue, 18 Mar 2003 11:21:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list For those of you at the IETF meeting in San Francisco, We will be meeting on Wednesday at 3:30 in Imperial B. Proposed agenda: - wg/document status. - core draft security considerations discussion. - current work - file transfer document. finally ready for last call? - gssapi. - newish work - closing the CBC hole - agent draft Anything I forgot? sorry for the general disorganization this time.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 11:21:49 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15992 for ; Tue, 18 Mar 2003 11:21:48 -0500 (EST) Received: (qmail 18003 invoked by uid 605); 18 Mar 2003 16:23:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17996 invoked from network); 18 Mar 2003 16:23:57 -0000 Received: from unknown (HELO hardcandy.Virtualsite.co.uk) (212.78.67.84) by mail.netbsd.org with SMTP; 18 Mar 2003 16:23:57 -0000 Received: (from flashsf@localhost) by hardcandy.Virtualsite.co.uk (8.11.1/8.11.1) id h2IGNXH17616; Tue, 18 Mar 2003 16:23:33 GMT Date: Tue, 18 Mar 2003 16:23:33 GMT Message-Id: <200303181623.h2IGNXH17616@hardcandy.Virtualsite.co.uk> To: kwo@dbr.com From: ImproveNaturally673dk@20na.com () Subject: Every man and woman should see this (NOT spam) Sender: ietf-ssh-owner@netbsd.org Precedence: list Click the blue hyperlink --> http://www.matemagnet.com/index.asp?affid=21027 <-- ml1 name: (ImproveNaturally673dk@20na.com) on Tuesday, March 18, 2003 at 16:23:33 realname: ImproveNaturally673dk@20na.com --------------------------------------------------------------------------- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 14:35:16 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26025 for ; Tue, 18 Mar 2003 14:35:15 -0500 (EST) Received: (qmail 4567 invoked by uid 605); 18 Mar 2003 19:37:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4557 invoked from network); 18 Mar 2003 19:37:16 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 18 Mar 2003 19:37:16 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id BD74F1793A for ; Tue, 18 Mar 2003 14:37:15 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2IIVYqV002708 for ; Tue, 18 Mar 2003 10:31:34 -0800 (PST) Message-Id: <200303181831.h2IIVYqV002708@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG Chair Nits on draft-ietf-secsh-publickeyfile-03.txt Reply-To: sommerfeld@netbsd.org Date: Tue, 18 Mar 2003 10:31:34 -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Okay, here we go again. This is intended as an informational draft; i'm not sure how picky the I* is about these but assuming they're treated like standards-track documents.. 1) references: need normative/non-normative split (all normative, looks like) bibliographic references to RFC's don't include the RFC numbers this appears to include [2], [3], [4], [5] 2) security considerations section missing. 3) it may be necessary to add a "iana considerations: none" section. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 14:35:22 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26039 for ; Tue, 18 Mar 2003 14:35:22 -0500 (EST) Received: (qmail 4570 invoked by uid 605); 18 Mar 2003 19:37:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4551 invoked from network); 18 Mar 2003 19:37:16 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 18 Mar 2003 19:37:16 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 063F717939 for ; Tue, 18 Mar 2003 14:37:15 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2IIZkEU002726 for ; Tue, 18 Mar 2003 10:35:46 -0800 (PST) Message-Id: <200303181835.h2IIZkEU002726@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG chair nits on draft-ietf-secsh-dns-02.txt Reply-To: sommerfeld@netbsd.org Date: Tue, 18 Mar 2003 10:35:46 -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list One *nit* spotted in the security considerations section: The security considerations section should reference the search path issue mentioned in section 2.2. It may also be good to recommend that clients using this get their DNS client configuration, including search path, from a trusted source, and that DHCP likely does not provide sufficient protection.. I think this can be respun without another WG last call. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 14:35:33 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26060 for ; Tue, 18 Mar 2003 14:35:33 -0500 (EST) Received: (qmail 4870 invoked by uid 605); 18 Mar 2003 19:37:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4566 invoked from network); 18 Mar 2003 19:37:17 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 18 Mar 2003 19:37:17 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id A546617939 for ; Tue, 18 Mar 2003 14:37:16 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2IHOn7J000392 for ; Tue, 18 Mar 2003 09:24:49 -0800 (PST) Message-Id: <200303181724.h2IHOn7J000392@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG chair nits on draft-ietf-secsh-auth-kbdinteract-04.txt Reply-To: sommerfeld@east.sun.com Date: Tue, 18 Mar 2003 09:24:48 -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Okay, it's been impressed on me by the powers that be that wg chairs should do more thorough drafts review. This is the first of a series. - Bill 1) normative/informative reference split. look like [PAM] is informative; everything else is normative. [rfc-2279] is not explicitly referenced anywhere by reference id, but is normative (for encoding of various forms here and there). 2) security considerations. i can't find one. this is a bad thing. let's add this to the "needs security considerations rewrite" pile. once again, see draft-iab-sec-cons-03.txt for guidelines on writing one. 3) iana considerations. "protocol constants" should turn into "iana considerations". also an explicit allocation of the userauth type "keyboard-interactive" needs to be listed. there may be other constants in the document which should be listed here but I can't find them. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 18:13:21 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05255 for ; Tue, 18 Mar 2003 18:13:21 -0500 (EST) Received: (qmail 25000 invoked by uid 605); 18 Mar 2003 23:15:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24908 invoked from network); 18 Mar 2003 23:15:27 -0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by mail.netbsd.org with SMTP; 18 Mar 2003 23:15:27 -0000 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2INDgTL008128 for ; Wed, 19 Mar 2003 00:13:42 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA07910 for ietf-ssh@netbsd.org; Tue, 18 Mar 2003 23:15:25 GMT Date: Tue, 18 Mar 2003 23:15:25 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Certificates in draft-ietf-secsh-transport-15.txt Message-ID: <20030318231525.F29750@edinburgh.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list I seem to recall some discussion on the list a while ago to the effect that the certificate part of the the transport draft was going to be ripped out and put into a seperate draft. This specifically 'cause of a lack of detail about just how the certs should be used. Is this still the consensus, or has the will to do this lapsed? DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 20:14:35 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10631 for ; Tue, 18 Mar 2003 20:14:35 -0500 (EST) Received: (qmail 28251 invoked by uid 605); 19 Mar 2003 01:16:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28244 invoked from network); 19 Mar 2003 01:16:44 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 19 Mar 2003 01:16:44 -0000 Received: from sydney.East.Sun.COM ([129.148.9.16]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00139; Tue, 18 Mar 2003 18:16:44 -0700 (MST) Received: from sydney.east.sun.com (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2J1Gc014381; Tue, 18 Mar 2003 20:16:40 -0500 (EST) From: Steve Hanna Message-Id: <200303190116.h2J1Gc014381@sydney.East.Sun.COM> Date: Tue, 18 Mar 2003 20:19:19 -0500 To: "Derek Fawcus" , Reply-To: Subject: Re: Certificates in draft-ietf-secsh-transport-15.txt X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I volunteered to work on an Internet Draft with a much more detailed description of how to use X.509 certificates with SSH. I'm planning to write the first draft this week and will post it as soon as the repository reopens. -Steve >I seem to recall some discussion on the list a while ago to the effect >that the certificate part of the the transport draft was going to be >ripped out and put into a seperate draft. This specifically 'cause >of a lack of detail about just how the certs should be used. > >Is this still the consensus, or has the will to do this lapsed? > >DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 21:09:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12036 for ; Tue, 18 Mar 2003 21:09:56 -0500 (EST) Received: (qmail 26401 invoked by uid 605); 19 Mar 2003 02:12:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26394 invoked from network); 19 Mar 2003 02:12:07 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 19 Mar 2003 02:12:07 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04666; Tue, 18 Mar 2003 19:12:05 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J2C5uK002907; Tue, 18 Mar 2003 21:12:05 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J2C5aj024877; Tue, 18 Mar 2003 21:12:05 -0500 (EST) Message-Id: <200303190212.h2J2C5aj024877@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Fawcus cc: ietf-ssh@netbsd.org Subject: Re: Certificates in draft-ietf-secsh-transport-15.txt In-Reply-To: Your message of "Tue, 18 Mar 2003 23:15:25 GMT." <20030318231525.F29750@edinburgh.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 18 Mar 2003 21:12:05 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Steve Hanna has already stuck his neck out saying he's working on it. Process-wise, the time to prune unimplemented features is at Draft stage, not Proposed stage; prior consensus was to leave a "stub" in place rather than rip it entirely.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 18 21:49:08 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12989 for ; Tue, 18 Mar 2003 21:49:08 -0500 (EST) Received: (qmail 13155 invoked by uid 605); 19 Mar 2003 02:51:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13145 invoked from network); 19 Mar 2003 02:51:11 -0000 Received: from unknown (HELO mta0) (61.144.161.2) by mail.netbsd.org with SMTP; 19 Mar 2003 02:51:11 -0000 Received: from m19684 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HBZ005NL6IHQU@mta0.huawei.com> for ietf-ssh@netbsd.org; Wed, 19 Mar 2003 10:49:30 +0800 (CST) Date: Wed, 19 Mar 2003 10:51:33 +0800 From: Miao Fuyou Subject: Relationship between user name and public key pair in Authentication Protocol In-reply-to: <001b01c2ea02$62fbd2a0$41426e0a@HUAWEI.COM> To: ylo@ssh.com, kivinen@ssh.com Cc: ietf-ssh@netbsd.org Message-id: <000001c2edc2$7441c1a0$41426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7BIT Hi, Tatu & Tero: I have a doubt on draft-ietf-secsh-userauth-16.txt. In section 2.1, there is: "In any case, if the user does not exist, the authentication request MUST NOT be accepted." In section 4, there is a sentence like: "When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct." Now the question is: Is there any RELATIONSHIP between the user name and the public key? For example, public key K1 is only used by user U1. If there is relationship, what is it? 1:1, 1:n, n:1 or m:n? I prefer to 1:1 and 1:n because n:1 and m:n have serious security problem. Looking forward to your response! Yours Miao From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 19 16:52:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11161 for ; Wed, 19 Mar 2003 16:52:12 -0500 (EST) Received: (qmail 8314 invoked by uid 605); 19 Mar 2003 21:54:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8306 invoked from network); 19 Mar 2003 21:54:15 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 19 Mar 2003 21:54:15 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01427; Wed, 19 Mar 2003 13:53:57 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JLrvuK006243; Wed, 19 Mar 2003 16:53:57 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JLruaj029037; Wed, 19 Mar 2003 16:53:56 -0500 (EST) Message-Id: <200303192153.h2JLruaj029037@thunk.east.sun.com> From: Bill Sommerfeld To: Miao Fuyou cc: ylo@ssh.com, kivinen@ssh.com, ietf-ssh@netbsd.org Subject: Re: Relationship between user name and public key pair in Authentication Protocol In-Reply-To: Your message of "Wed, 19 Mar 2003 10:51:33 +0800." <000001c2edc2$7441c1a0$41426e0a@HUAWEI.COM> Reply-to: sommerfeld@east.sun.com Date: Wed, 19 Mar 2003 16:53:56 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Existing implementations allow a m:n relationship between user keys and user names; the client specifies the target user id and a key, and the server consults a per-target-user acl (typically a file named something like .ssh/authorized_keys in the target user's home directory) which lists keys allowed to log in as the given target user. Nothing prevents the same key from appearing on multiple acls, but it's an unusual configuration. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 19 17:40:27 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12839 for ; Wed, 19 Mar 2003 17:40:25 -0500 (EST) Received: (qmail 7635 invoked by uid 605); 19 Mar 2003 22:42:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7623 invoked from network); 19 Mar 2003 22:42:32 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 19 Mar 2003 22:42:32 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29991 for ; Wed, 19 Mar 2003 14:42:31 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JMgVuK017894 for ; Wed, 19 Mar 2003 17:42:31 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JMgVaj029372 for ; Wed, 19 Mar 2003 17:42:31 -0500 (EST) Message-Id: <200303192242.h2JMgVaj029372@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: preliminary version of counter mode draft Reply-to: sommerfeld@east.sun.com Date: Wed, 19 Mar 2003 17:42:31 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a preliminary version of a counter mode + transport fixes draft prepared by some of the folks who recently did a security analysis of the protocol.. The authors have the following questions for the WG: 1) The transport ID says messages should be padded to a length a multiple of the block cipher's block size. That is not necessary if we use CTR mode (ie, we can pad to a multiple of 8 bytes even if the block ciphers uses 16 byte blocks). Do people think we should "break" compliance with the transport spec and just pad to a multiple of 8 bytes (to help with performance on slow links). (Of course, the less padding we use, the more information we leak about the length of the payload. But implementations can always add more than the minimum amount of padding if they want to.) 2) How should we handle the recommendation: the receiver should rekey before receiving 2**32 packets since the last rekey operation? The solution we currently have is to require (ie, say SHOULD) implementations to rekey after receiving more than 2**31 packets since the last rekey operation? 3) Which ciphers do people want to use (AES, 3DES, Twofish, etc.)? We'll discuss these in the meeting and follow up on the list.. Network Working Group M. Bellare Internet-Draft T. Kohno Expires: [[Month Day, Year]] UC San Diego C. Namprempre Thammasat University [[Date]] SSH Transport Layer Encryption Modes draft-ietf-secsh-newmodes-00.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 [[Month Day, Year]]. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Researchers have recently discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how Bellare, Kohno, and Namprempre [Page 1] Internet Draft Month, Year frequently SSH implementations should rekey. Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy and integrity/authenticity attacks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . X 2. Conventions Used in This Document . . . . . . . . . . . . . . X 3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . X 3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . X 3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . X 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . X 5. Security Considerations . . . . . . . . . . . . . . . . . . . X 5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . X 5.2 Encryption Method Considerations . . . . . . . . . . . . . . . X References . . . . . . . . . . . . . . . . . . . . . . . . . . X Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . X Full Copyright Statement . . . . . . . . . . . . . . . . . . . X 1. Introduction The symmetric portion of the SSH Transport Protocol was designed to provide both privacy and integrity of encapsulated data. Researchers ([DAI,BKN]) have, however, recently identified several security problems with the symmetric portion of the SSH Transport Protocol as described in [SSH-TRANS]. For example, the encryption mode specified in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack. Additionally, if not rekeyed frequently enough, the SSH Transport Protocol may leak information about payload data. This latter property is true regardless of what encryption mode is used. In [BKN] Bellare, Kohno, and Namprempre show how to modify the symmetric portion of the SSH Transport Protocol so that it provably preserves privacy and integrity against chosen-plaintext, chosen- ciphertext, and reaction attacks. This document instantiates the recommendations described in [BKN]. 2. 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 [RFC2119]. The used data types and terminology are specified in the architecture Bellare, Kohno, and Namprempre [Page 2] Internet Draft Month, Year document [SSH-ARCH]. The SSH Transport Protocol is specified in the transport document [SSH-TRANS]. 3. Rekeying Section 7 of [SSH-TRANS] suggests that SSH implementations rekey after every gigabyte of transmitted data. [SSH-TRANS] does not, however, discuss all the problems that could arise if an SSH implementation does not rekey frequently enough. This section serves to strengthen the suggestion in [SSH-TRANS] by giving firm upper bounds on the tolerable number of encryptions between rekeying operations. In Section 5 we discuss the motivation for these rekeying recommendations in more detail. This section makes two recommendations. Informally, the first recommendation is intended to protects against possible information leakage through the MAC tag and the second recommendation is intended to protect against possible information leakage through the block cipher. Note that, depending on the block length of the underlying block cipher and the length of the encrypted packets, the first recommendation may supersede the second recommendation, or visa- versa. 3.1 First Rekeying Recommendation Because of possible information leakage through the MAC tag, SSH implementations SHOULD rekey at least once every 2**32 outgoing packets. More explicitly, after a key exchange an SSH implementation SHOULD NOT send more than 2**32 packets before rekeying again. SSH implementations SHOULD also attempt to rekey before receiving more than 2**32 packets since the last rekey operation. The preferred way to do this is to rekey after receiving more than 2**31 packets since the last rekey operation. 3.2 Second Rekeying Recommendation Because of a birthday property of block ciphers and some modes of operation, implementations must be careful not to encrypt too many blocks with the same encryption key. Let L be the block length (in bits) of an SSH encryption method's block cipher (eg, 128 for AES). If L is at least 128 then, after rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4) blocks before rekeying again. If L is at least 128, then SSH implementations should also attempt to force a rekey before receiving Bellare, Kohno, and Namprempre [Page 3] Internet Draft Month, Year more than 2**(L/4) blocks. If L is less than 128 (which is the case for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, although it may be too expensive to rekey every 2**(L/4) blocks, it is still advisable for SSH implementations to follow the original recommendation in [SSH-TRANS]: rekey at least once every gigabyte of transmitted data. Note that if L is less than or equal to 128, then the recommendation in this subsection supersedes the recommendation in Section 3.1. If an SSH implementation uses a block cipher with a larger block size (eg, Rijndael with 256-bit blocks), then the recommendations in the above paragraph may supersede the recommendations in this paragraph (depending on the lengths of the packets). 4. Encryption Modes This document describes new encryption methods for use with the SSH Transport Protocol. These encryption methods are in addition to the encryption methods described in Section 4.3 of [SSH-TRANS]. Recall from [SSH-TRANS] that the encryption methods in each direction of an SSH connection MUST run independently of each other and that, when encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the chosen method. Further recall that the total length of the concatenation of the packet length, padding length, payload, and padding MUST be a multiple of the cipher's block size when the cipher's block size is greater than or equal to 8 bytes (which is the case for all of the following methods). This document describes the following new methods: aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr RECOMMENDED Blowfish in SDCTR mode twofish128-ctr RECOMMENDED Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr RECOMMENDED Serpent in SDCTR mode, with with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode Bellare, Kohno, and Namprempre [Page 4] Internet Draft Month, Year The label -ctr means that the block cipher is to be used in "stateful-decryption counter" (SDCTR) mode. Let L be the block length of in bits. In stateful-decryption counter mode both the sender and the receiver maintain an internal L-bit counter X. The initial value of X should be the initial IV (as computed in Section 5.2 of [SSH-TRANS]) interpreted as an L-bit unsigned integer in network-byte-order. If X=(2**L)-1, then "increment X" has the traditional semantics of "set X to 0." We use the notation to mean "convert X to an L-bit string in network- byte-order." Naturally, implementations may differ in how the internal value X is stored. For example, implementations may store X as multiple unsigned 32-bit counters. To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each blocks of length L), the encryptor first encrypts with to obtain a block B1. The block B1 is then XORed with P1 to generate the ciphertext block C1. The counter X is then incremented and the process is repeated for each subsequent block in order to generate the entire ciphertext C=C1||C2||...||Cn corresponding to the packet P. Note that the counter X is not included in the ciphertext. Also note that the keystream can be pre-computed and that encryption is parallelizable. To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also maintains its own copy of X), first encrypts its copy of with to generate a block B1 and then XORs B1 to C1 to get P1. The decryptor then increments its copy of the counter X and repeats the above process for each block to obtain the plaintext packet P=P1||P2||...||Pn. As before, the keystream can be pre-computed and decryption is parallelizable. The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes. The "aes192-ctr" method uses AES with 192-bit keys. The "aes256-ctr" method uses AES with 256-bit keys. The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt- encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). The block size is 8 bytes. This algorithm is defined in [SCHNEIER]. The "blowfish-ctr" method uses Blowfish with 256 bit keys [SCHNEIER]. The block size is 8 bytes. Bellare, Kohno, and Namprempre [Page 5] Internet Draft Month, Year The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. The block size is 16 bytes. The "twofish192-ctr" method uses Twofish with 192-bit keys. The "twofish256-ctr" method uses Twofish with 256-bit keys. The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] with 128-bit keys. The block size is 16 bytes. The "serpent192-ctr" method uses Serpent with 192-bit keys. The "serpent256-ctr" method uses Serpent with 256-bit keys. The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. IDEA is patented by Ascom AG. The block size is 8 bytes. The "cast128-ctr" method uses the CAST-128 cipher [RFC2144]. The block size is 8 bytes. 5. Security Considerations This document describes additional encryption methods and recommendations for the SSH Transport Protocol [SSH-TRANS]. [BKN] prove that if an SSH application incorporates the methods and recommendations described in this document, then the symmetric cryptographic portion of that application will resist a large class of privacy and integrity attacks. This section is designed to help implementors understand the security-related motivations for, as well as possible consequences of deviating from, the methods and recommendations described in this document. Additional motivation and discussion, as well as proofs of security, appear in the research paper [BKN]. Please note that the notion of "prove" in the context of [BKN] is that of practice-oriented reductionist security: if an attacker is able to break the symmetric portion of the SSH Transport Protocol using a certain type of attack (eg, a chosen-ciphertext attack), then the attacker will also be able to break one of the transport protocol's underlying components (eg, the underlying block cipher or MAC). If we make the reasonable assumption that the underlying components (such as AES and HMAC-SHA1) are secure, then the attacker against the symmetric portion of the SSH protocol cannot be very successful (since otherwise there would be a contradiction). Please see [BKN] for details. In particular, attacks are not impossible; just extremely improbable (unless the building blocks, like AES, are insecure). Bellare, Kohno, and Namprempre [Page 6] Internet Draft Month, Year Note also that cryptography often plays only a small (but critical) role in an application's overall security. In the case of the SSH Transport Protocol, even though an application might implement the symmetric portion of the SSH protocol exactly as described in this document, the application may still be vulnerable to non-protocol- based attacks (as an egregious example, an application might save cryptographic keys in cleartext to an unprotected file). Consequently, even though the methods described herein come with proofs of security, developers must still execute caution when developing applications that implement these methods. 5.1 Rekeying Considerations Section 3 of this document makes two rekeying recommendations: (1) rekey at least once every 2**32 packets and (2) rekey after a certain number of encrypted blocks (eg, 2**(L/4) blocks if the block cipher's block length L is at least 128 bits). The motivations for recommendations (1) and (2) are different, and we consider each recommendation in turn. Briefly, (1) is designed to protect against information leakage through the SSH protocol's underlying MAC and (2) is designed to protect against information leakage through the SSH protocol's underlying encryption scheme. Please note that, depending on the encryption method's block length L and the number of blocks encrypted per packet, recommendation (1) may supersede recommendation (2) or visa-versa. Recommendation (1) states that SSH implementations should rekey at least once every 2**32 packets. As [BKN] show, if more than 2**32 packets are encrypted and MACed by the SSH Transport Protocol between rekeyings, then the SSH Transport Protocol's underlying MAC may begin to leak information about the protocol's payload data. In more detail, an adversary looks for a collision between the MACs associated to two packets that were MACed with the same 32-bit sequence number (see Section 4.4 of [SSH-TRANS]); if a collision is found, then the payload data associated with those two ciphertexts is probably identical. Note that this problem occurs regardless of how secure the underlying encryption method is. Implementors who decide not to rekey at least once every 2**32 packets should understand this issue. Note that compressing payload data before encrypting and MACing will not significantly reduce the risk of information leakage through the underlying MAC. Similarly, the use of random (and unpredictable to an adversary) padding will not prevent information leakage through the underlying MAC [BKN]. One alternative to recommendation (1) would be to make the SSH Transport Protocol's sequence number more than 32 bits long. This Bellare, Kohno, and Namprempre [Page 7] Internet Draft Month, Year document does not suggest increasing the length of the sequence number because doing so could hinder interoperability with older version of the SSH protocol. Another alternative to recommendation (1) would be to switch from HMAC to a privacy-preserving randomized MAC. Recommendation (2) states that SSH implementations should rekey before encrypting more than 2**(L/4) blocks with the same key (assuming L is at least 128). This recommendation is designed to minimize the risk of birthday attacks against the encryption method's underlying block cipher. For example, there is a theoretical privacy attack against stateful-decryption counter mode if an adversary is allowed to encrypt approximately 2**(L/2) messages with the same key. It is because of these birthday attacks that implementors are highly encouraged to use secure block ciphers with large block lengths. 5.2 Encryption Method Considerations Researchers have recently shown that the original CBC-based encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext privacy attacks [DAI,BKN]. The new stateful-decryption counter mode encryption methods described in Section 4 of this document were designed to be secure replacements to the original encryption methods described in [SSH-TRANS]. Many people shy away from counter mode-based encryption schemes because, when used incorrectly (such as when the keystream is allowed to repeat), counter mode can be very insecure. Fortunately, the common concerns with counter mode do not apply to SSH because of the rekeying recommendations and because of the additional protection provided by the transport protocol's MAC. This discussion is formalized with proofs of security in [BKN]. As an additional note, when one of the stateful-decryption counter mode encryption methods (Section 4) is used, then the padding included in an SSH packet (Section 4 of [SSH-TRANS]) need not be (but can still be) random. This eliminates the need to generate cryptographically-secure pseudorandom bytes for each packet. One property of counter mode encryption is that it does not require messages to be padded to a multiple of the block cipher's block length. Although not padding messages can reduce the protocol's network consumption, this document requires padding to be a multiple of the block cipher's block length in order to (1) not alter the packet description in [SSH-TRANS] and (2) not leak precise information about the length of the packet's payload data. (Although there may be some networks savings for padding to only 8-bytes even if the block cipher uses 16-byte blocks, because of (1) we do not Bellare, Kohno, and Namprempre [Page 8] Internet Draft Month, Year make that recommendation here.) In addition to stateful-decryption counter mode, [BKN] describe other provably-secure encryption methods for use with the SSH Transport Protocol. The stateful-decryption counter mode methods in Section 4 are, however, the preferred alternatives to the insecure methods in [SSH-TRANS] because stateful-decryption counter mode is the most efficient (both in terms of network consumption and in terms of the number of required cryptographic operations per packet). References [AES] Daemon, J. and Rijmen, V., "AES Proposal: Rijndael", NIST AES Proposal, 1998. [BKN] Bellare, M., Kohno, T., and Namprempre, C., "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol", Ninth ACM Conference on Computer and Communications Security, 2002. [BN] Bellare, M. and Namprempre, C., "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm", Asiacrypt 2000. [DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to the ietf-ssh@netbsd.org email list, 2002. [KRAWCZYK] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How secure is SSL?)", Crypto 2001. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: Protocols algorithms and source in code in C", Wiley, 1996. [SERPENT] Anderson, R., Biham, E., and Knudsen, L. "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998. [SSH-ARCH] Ylonen, T., et. al., "SSH Protocol Architecture", I-D draft-ietf-architecture-12.txt, January 2002. Bellare, Kohno, and Namprempre [Page 9] Internet Draft Month, Year [SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol", I-D draft-ietf-transport-14.txt, March 2002. [TWOFISH] Schneier, B., et. al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999. Authors' Addresses: Mihir Bellare Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0114 La Jolla, CA 92093-0114 Phone: +1 858-822-2977 EMail: mihir@cs.ucsd.edu Tadayoshi Kohno Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0114 La Jolla, CA 92093-0114 Phone: +1 858-822-2977 EMail: tkohno@cs.ucsd.edu Chanathip Namprempre Thammasat University Faculty of Engineering Electrical Engineering Department Rangsit Campus, Klong Luang Pathumthani, Thailand 12121 EMail: meaw@alum.mit.edu 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 Bellare, Kohno, and Namprempre [Page 10] Internet Draft Month, Year 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. Acknowledgments The first and third author were supported by NSF Grant CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership Development Award. The second author was supported by a National Defense Science and Engineering Fellowship. Bellare, Kohno, and Namprempre [Page 11] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 19 19:40:24 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18035 for ; Wed, 19 Mar 2003 19:40:23 -0500 (EST) Received: (qmail 8162 invoked by uid 605); 20 Mar 2003 00:42:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8151 invoked from network); 20 Mar 2003 00:42:29 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 20 Mar 2003 00:42:29 -0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 48AFD5286; Thu, 20 Mar 2003 01:42:28 +0100 (MET) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id EC6341D9B; Thu, 20 Mar 2003 01:42:27 +0100 (MET) Date: Thu, 20 Mar 2003 01:42:27 +0100 (CET) From: Jakob Schlyter To: Bill Sommerfeld Cc: IETF Secure Shell WG Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: <200303181835.h2IIZkEU002726@syn.hamachi.org> Message-ID: References: <200303181835.h2IIZkEU002726@syn.hamachi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list we suggest the following changes. jakob @@ -304,7 +304,14 @@ As stated in , we recommend that SSH implementors provide a policy mechanism to control the order of - methods used for host key verification. + methods used for host key verification. One specific scenario for + having a configurable policy is where clients use unqualified host + names to connect to servers. In this case, we recommend that SSH + implementations check the host key against a local database before + verifying the key via the fingerprint returned from DNS. This + would help prevent an attacker from injecting a DNS search path + into the local resolver and forcing the client to connect to a + different host. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 00:46:24 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26825 for ; Thu, 20 Mar 2003 00:46:13 -0500 (EST) Received: (qmail 1771 invoked by uid 605); 20 Mar 2003 05:48:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1764 invoked from network); 20 Mar 2003 05:48:05 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 20 Mar 2003 05:48:05 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21676; Wed, 19 Mar 2003 22:48:02 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2K5m29P018788; Thu, 20 Mar 2003 00:48:02 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K5m1aj001062; Thu, 20 Mar 2003 00:48:02 -0500 (EST) Message-Id: <200303200548.h2K5m1aj001062@thunk.east.sun.com> From: Bill Sommerfeld To: Jakob Schlyter cc: IETF Secure Shell WG Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: Your message of "Thu, 20 Mar 2003 01:42:27 +0100." Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Mar 2003 00:48:01 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list An alternate approach which I think is superior is to ensure that the DNS search path used while resolving SSHFP records comes from a trusted source (i.e., not from DHCP or PPP/ipcp). Also, the security of SSHFP records depends on the client being properly configured as a secure DNS client; exactly what is required to do this are out of scope for the SSHFP document but some methods are described in references [4] and [9]. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 01:10:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27245 for ; Thu, 20 Mar 2003 01:10:51 -0500 (EST) Received: (qmail 13481 invoked by uid 605); 20 Mar 2003 06:13:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13474 invoked from network); 20 Mar 2003 06:13:04 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 20 Mar 2003 06:13:04 -0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 7F7545286; Thu, 20 Mar 2003 07:13:03 +0100 (MET) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id 22E891D99; Thu, 20 Mar 2003 07:13:03 +0100 (MET) Date: Thu, 20 Mar 2003 07:13:02 +0100 (CET) From: Jakob Schlyter To: Bill Sommerfeld Cc: IETF Secure Shell WG Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: <200303200548.h2K5m1aj001062@thunk.east.sun.com> Message-ID: References: <200303200548.h2K5m1aj001062@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 20 Mar 2003, Bill Sommerfeld wrote: > An alternate approach which I think is superior is to ensure that the > DNS search path used while resolving SSHFP records comes from a > trusted source (i.e., not from DHCP or PPP/ipcp). or one could just acknowledge that DNS search paths are evil. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 14:30:07 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01037 for ; Thu, 20 Mar 2003 14:30:07 -0500 (EST) Received: (qmail 11260 invoked by uid 605); 20 Mar 2003 19:32:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11250 invoked from network); 20 Mar 2003 19:32:17 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 20 Mar 2003 19:32:17 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id EC6CF1793A for ; Thu, 20 Mar 2003 14:32:16 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2KHqr9c000660 for ; Thu, 20 Mar 2003 09:52:53 -0800 (PST) Message-Id: <200303201752.h2KHqr9c000660@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: another bounced message with chinese subject. Reply-To: sommerfeld@netbsd.org Date: Thu, 20 Mar 2003 09:52:53 -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list again, this was caught as a false-positive. ------- Forwarded Message Date: Thu, 20 Mar 2003 14:24:39 +0800 From: Miao Fuyou Subject: RE: Relationship between user name and public key pair in Authentication Protocol In-reply-to: <200303200520.h2K5Kvaj000896@thunk.east.sun.com> To: sommerfeld@east.sun.com Cc: ylo@ssh.com, kivinen@ssh.com, ietf-ssh@netbsd.org You are right, it is unpractical to generate the same key pair, and the effort to devise a mechanism for prevention is meaningless. But I still think the relationship permitted in SSH shall be described explicitly, so the developers can implement it realizingly. How do you think about it? - -----Original Message----- From: sommerfeld@thunk.east.sun.com [mailto:sommerfeld@thunk.east.sun.com] On Behalf Of Bill Sommerfeld Sent: Thursday, March 20, 2003 1:21 PM To: Miao Fuyou Cc: ylo@ssh.com; kivinen@ssh.com; ietf-ssh@netbsd.org > For the sake of the "public" nature of public key it will not be > secure if several users share the same public key pair. But that's not the case you asked about. > Even if the server try > its best to keep it secret, the user may disclose the public key > casually. But the whole point of public key systems is that they allow you to disclose the public part of the keypair without creating a security risk. > So, it's necessary to ensure the public key pair are unique. Does not follow. Keypairs are statistically unique and it is highly improbable that two users might generate the same key, assuming reasonable random number generators. > If the server find a user is registering a existing public key, it > shall refuse the register and invalidate the existing one. register *what*, precisely? what are you really trying to accomplish here? what additional security do you think you might provide? It may be possible for a "role"-style shared account may have an acl which allows access to it from multiple keys. It may also be useful in some cases for a single key to provide access to multiple accounts or multiple services. ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 14:30:20 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01064 for ; Thu, 20 Mar 2003 14:30:19 -0500 (EST) Received: (qmail 11259 invoked by uid 605); 20 Mar 2003 19:32:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11244 invoked from network); 20 Mar 2003 19:32:17 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 20 Mar 2003 19:32:17 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 5D85A17939 for ; Thu, 20 Mar 2003 14:32:16 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2KHotFR000644 for ; Thu, 20 Mar 2003 09:50:55 -0800 (PST) Message-Id: <200303201750.h2KHotFR000644@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Bounced message with subject in chinese. Reply-To: sommerfeld@netbsd.org Date: Thu, 20 Mar 2003 09:50:55 -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list I'm now in my "list administrator" role.. The mail host we use assumes that the lists it hosts are predominantly in english and presumes that messages containing text in an asian charset are spam. (Most of the subscribers don't read chinese or japanese or korean so this is a reasonable assumption). It seems that a message sent by Miao Fuyou's had a chinese charset subject line, which triggered the filter. My reply to it and miao's response to my reply also got caught up in the filter. - Bill ------- Forwarded Message Message-Id: <200303200520.h2K5Kvaj000896@thunk.east.sun.com> From: Bill Sommerfeld To: Miao Fuyou cc: ylo@ssh.com, kivinen@ssh.com, ietf-ssh@netbsd.org In-Reply-To: Your message of "Thu, 20 Mar 2003 10:05:47 +0800." <000001c2ee85$39d4bea0$41426e0a@HUAWEI.COM> Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Mar 2003 00:20:57 -0500 Sender: sommerfeld@thunk.east.sun.com > For the sake of the "public" nature of public key it will not be secure > if several users share the same public key pair. But that's not the case you asked about. > Even if the server try > its best to keep it secret, the user may disclose the public key > casually. But the whole point of public key systems is that they allow you to disclose the public part of the keypair without creating a security risk. > So, it's necessary to ensure the public key pair are unique. Does not follow. Keypairs are statistically unique and it is highly improbable that two users might generate the same key, assuming reasonable random number generators. > If the server find a user is registering a existing public key, it shall > refuse the register and invalidate the existing one. register *what*, precisely? what are you really trying to accomplish here? what additional security do you think you might provide? It may be possible for a "role"-style shared account may have an acl which allows access to it from multiple keys. It may also be useful in some cases for a single key to provide access to multiple accounts or multiple services. ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 14:30:31 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01091 for ; Thu, 20 Mar 2003 14:30:30 -0500 (EST) Received: (qmail 11453 invoked by uid 605); 20 Mar 2003 19:32:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11262 invoked from network); 20 Mar 2003 19:32:19 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 20 Mar 2003 19:32:19 -0000 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 9308617939; Thu, 20 Mar 2003 14:32:18 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.12.7+Sun/8.8.8) with ESMTP id h2KHsQDW000682; Thu, 20 Mar 2003 09:54:26 -0800 (PST) Message-Id: <200303201754.h2KHsQDW000682@syn.hamachi.org> From: Bill Sommerfeld To: Jakob Schlyter Cc: IETF Secure Shell WG Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: Your message of "Thu, 20 Mar 2003 07:13:02 +0100." Reply-To: sommerfeld@netbsd.org Date: Thu, 20 Mar 2003 09:54:26 -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list > > An alternate approach which I think is superior is to ensure that the > > DNS search path used while resolving SSHFP records comes from a > > trusted source (i.e., not from DHCP or PPP/ipcp). > > or one could just acknowledge that DNS search paths are evil. I think it's unreasonable from a usability standpoint to require that users always type FQDN's rather than shorter name forms.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 18:25:53 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13960 for ; Thu, 20 Mar 2003 18:25:53 -0500 (EST) Received: (qmail 2092 invoked by uid 605); 20 Mar 2003 23:28:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2083 invoked from network); 20 Mar 2003 23:28:05 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 20 Mar 2003 23:28:05 -0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 1F4F3529E; Fri, 21 Mar 2003 00:28:04 +0100 (MET) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id C0A111D99; Fri, 21 Mar 2003 00:28:03 +0100 (MET) Date: Fri, 21 Mar 2003 00:28:03 +0100 (CET) From: Jakob Schlyter To: Bill Sommerfeld Cc: IETF Secure Shell WG Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: <200303200548.h2K5m1aj001062@thunk.east.sun.com> Message-ID: References: <200303200548.h2K5m1aj001062@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 20 Mar 2003, Bill Sommerfeld wrote: > An alternate approach which I think is superior is to ensure that the > DNS search path used while resolving SSHFP records comes from a trusted > source (i.e., not from DHCP or PPP/ipcp). how can the ssh client implementation ensure that? jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 18:37:08 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14265 for ; Thu, 20 Mar 2003 18:37:07 -0500 (EST) Received: (qmail 8625 invoked by uid 605); 20 Mar 2003 23:39:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8617 invoked from network); 20 Mar 2003 23:39:17 -0000 Received: from ganymede.jtan.com (207.106.84.133) by mail.netbsd.org with SMTP; 20 Mar 2003 23:39:17 -0000 Received: from jtan.com (wgriffin@callisto.jtan.com [207.106.84.134]) by ganymede.jtan.com (8.11.0/8.11.0) with ESMTP id h2KNdDD29428; Thu, 20 Mar 2003 18:39:14 -0500 (EST) Date: Thu, 20 Mar 2003 15:39:34 -0800 Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Bill Sommerfeld , IETF Secure Shell WG To: Jakob Schlyter From: wes In-Reply-To: Message-Id: <348EDA8C-5B2D-11D7-B212-000393D121BA@jtan.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, March 20, 2003, at 03:28 PM, Jakob Schlyter wrote: > On Thu, 20 Mar 2003, Bill Sommerfeld wrote: > >> An alternate approach which I think is superior is to ensure that the >> DNS search path used while resolving SSHFP records comes from a >> trusted >> source (i.e., not from DHCP or PPP/ipcp). > > how can the ssh client implementation ensure that? I don't think the implementation can ensure that. However, the users of the client system can ensure that by manually coding a DNS search path that doesn't get over-written by DHCP. -- wes / wgriffin@jtan.com / 000f1a2f From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 20 18:46:40 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14490 for ; Thu, 20 Mar 2003 18:46:39 -0500 (EST) Received: (qmail 13579 invoked by uid 605); 20 Mar 2003 23:48:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13572 invoked from network); 20 Mar 2003 23:48:51 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 20 Mar 2003 23:48:51 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27535 for ; Thu, 20 Mar 2003 16:48:50 -0700 (MST) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNmon6365772 for ; Thu, 20 Mar 2003 15:48:50 -0800 (PST) Date: Thu, 20 Mar 2003 15:48:38 -0800 (PST) From: Darren J Moffat To: ietf-ssh@netbsd.org Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: <348EDA8C-5B2D-11D7-B212-000393D121BA@jtan.com> Message-ID: References: <348EDA8C-5B2D-11D7-B212-000393D121BA@jtan.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 20 Mar 2003, wes wrote: > On Thursday, March 20, 2003, at 03:28 PM, Jakob Schlyter wrote: > > > On Thu, 20 Mar 2003, Bill Sommerfeld wrote: > > > >> An alternate approach which I think is superior is to ensure that the > >> DNS search path used while resolving SSHFP records comes from a > >> trusted > >> source (i.e., not from DHCP or PPP/ipcp). > > > > how can the ssh client implementation ensure that? > > I don't think the implementation can ensure that. However, the users of > the client system can ensure that by manually coding a DNS search path > that doesn't get over-written by DHCP. I doubt very much that normal users can do any such thing. On most systems DNS configuration is system wide, not per user. Most users don't even know what DNS is (and they shouldn't really need to). The administrator of the system may be able to do what is suggested - but it depends on the OS and how it deals with DHCP. It also depends on what APIs will be available for DNSSEC and/or normal DNS. Clever users with use of LD_PRELOAD (and its equivalent if it exists) on UNIX like systems might be able to do what was suggested. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 21 00:16:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22063 for ; Fri, 21 Mar 2003 00:16:46 -0500 (EST) Received: (qmail 18766 invoked by uid 605); 21 Mar 2003 05:18:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18759 invoked from network); 21 Mar 2003 05:18:58 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 21 Mar 2003 05:18:58 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12059; Thu, 20 Mar 2003 22:18:55 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L5ItuK013288; Fri, 21 Mar 2003 00:18:55 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L5Isaj005875; Fri, 21 Mar 2003 00:18:54 -0500 (EST) Message-Id: <200303210518.h2L5Isaj005875@thunk.east.sun.com> From: Bill Sommerfeld To: Jakob Schlyter cc: IETF Secure Shell WG Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: Your message of "Fri, 21 Mar 2003 00:28:03 +0100." Reply-to: sommerfeld@east.sun.com Date: Fri, 21 Mar 2003 00:18:54 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > > An alternate approach which I think is superior is to ensure that the > > DNS search path used while resolving SSHFP records comes from a trusted > > source (i.e., not from DHCP or PPP/ipcp). > > how can the ssh client implementation ensure that? The ssh client can't, but a system containing an ssh client could. Security considerations are not just for subsystem implementors; they're also for the users.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 21 01:32:51 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23775 for ; Fri, 21 Mar 2003 01:32:51 -0500 (EST) Received: (qmail 25313 invoked by uid 605); 21 Mar 2003 06:35:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25306 invoked from network); 21 Mar 2003 06:35:03 -0000 Received: from unknown (HELO mta0) (61.144.161.2) by mail.netbsd.org with SMTP; 21 Mar 2003 06:35:03 -0000 Received: from m19684 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HC300BXM67KN6@mta0.huawei.com> for ietf-ssh@netbsd.org; Fri, 21 Mar 2003 14:33:21 +0800 (CST) Date: Fri, 21 Mar 2003 14:35:24 +0800 From: Miao Fuyou Subject: RE: another bounced message with chinese subject. In-reply-to: <200303201752.h2KHqr9c000660@syn.hamachi.org> To: ietf-ssh@netbsd.org Message-id: <000001c2ef74$0e3fc420$41426e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7BIT Your comments are welcome on following "relationship description". -----Original Message----- From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org] On Behalf Of Bill Sommerfeld Sent: Friday, March 21, 2003 1:53 AM To: ietf-ssh@netbsd.org Subject: another bounced message with chinese subject. again, this was caught as a false-positive. ------- Forwarded Message Date: Thu, 20 Mar 2003 14:24:39 +0800 From: Miao Fuyou Subject: RE: Relationship between user name and public key pair in Authentication Protocol In-reply-to: <200303200520.h2K5Kvaj000896@thunk.east.sun.com> To: sommerfeld@east.sun.com Cc: ylo@ssh.com, kivinen@ssh.com, ietf-ssh@netbsd.org You are right, it is unpractical to generate the same key pair, and the effort to devise a mechanism for prevention is meaningless. But I still think the relationship permitted in SSH shall be described explicitly, so the developers can implement it realizingly. How do you think about it? - -----Original Message----- From: sommerfeld@thunk.east.sun.com [mailto:sommerfeld@thunk.east.sun.com] On Behalf Of Bill Sommerfeld Sent: Thursday, March 20, 2003 1:21 PM To: Miao Fuyou Cc: ylo@ssh.com; kivinen@ssh.com; ietf-ssh@netbsd.org > For the sake of the "public" nature of public key it will not be > secure if several users share the same public key pair. But that's not the case you asked about. > Even if the server try > its best to keep it secret, the user may disclose the public key > casually. But the whole point of public key systems is that they allow you to disclose the public part of the keypair without creating a security risk. > So, it's necessary to ensure the public key pair are unique. Does not follow. Keypairs are statistically unique and it is highly improbable that two users might generate the same key, assuming reasonable random number generators. > If the server find a user is registering a existing public key, it > shall refuse the register and invalidate the existing one. register *what*, precisely? what are you really trying to accomplish here? what additional security do you think you might provide? It may be possible for a "role"-style shared account may have an acl which allows access to it from multiple keys. It may also be useful in some cases for a single key to provide access to multiple accounts or multiple services. ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 21 13:50:06 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22338 for ; Fri, 21 Mar 2003 13:50:04 -0500 (EST) Received: (qmail 10404 invoked by uid 605); 21 Mar 2003 18:52:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10397 invoked from network); 21 Mar 2003 18:52:14 -0000 Received: from centaur.acm.jhu.edu (128.220.223.65) by mail.netbsd.org with SMTP; 21 Mar 2003 18:52:14 -0000 Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id C9FA513EB0; Fri, 21 Mar 2003 13:52:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id C941237DFE for ; Fri, 21 Mar 2003 13:52:13 -0500 (EST) Date: Fri, 21 Mar 2003 13:52:13 -0500 (EST) From: Jack Lloyd To: Subject: Re: preliminary version of counter mode draft In-Reply-To: <200303192242.h2JMgVaj029372@thunk.east.sun.com> Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 X-Red-Robot-Approved: CRUSH ALL HU-MANS! Organization: JHU ACM/CS/SRL MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 19 Mar 2003, Bill Sommerfeld wrote: Just a comment from a non-implementor lurker. > 3) Which ciphers do people want to use (AES, 3DES, Twofish, etc.)? I'm curious why all of these were here: > twofish128-ctr RECOMMENDED Twofish in SDCTR mode, > with 128-bit key > twofish192-ctr OPTIONAL Twofish with 192-bit key > twofish256-ctr OPTIONAL Twofish with 256-bit key > serpent128-ctr RECOMMENDED Serpent in SDCTR mode, with > with 128-bit key > serpent192-ctr OPTIONAL Serpent with 192-bit key > serpent256-ctr OPTIONAL Serpent with 256-bit key Serpent and Twofish treat 128, 192 and 256 bit keys basically the same anyway (unlike AES, where all three different versions might be useful). Obviously there is no reason _not to have them all (besides a fairly small amount of extra work for implementors), but it seems pointless, given that serpent256-ctr and twofish256-ctr would do the job of all six of these just fine. -Jack From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 24 11:27:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24676 for ; Mon, 24 Mar 2003 11:27:02 -0500 (EST) Received: (qmail 5474 invoked by uid 605); 24 Mar 2003 16:29:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5462 invoked from network); 24 Mar 2003 16:29:17 -0000 Received: from ganymede.jtan.com (207.106.84.133) by mail.netbsd.org with SMTP; 24 Mar 2003 16:29:17 -0000 Received: from jtan.com (wgriffin@callisto.jtan.com [207.106.84.134]) by ganymede.jtan.com (8.11.0/8.11.0) with ESMTP id h2OGT1q06577; Mon, 24 Mar 2003 11:29:01 -0500 (EST) Date: Mon, 24 Mar 2003 11:29:24 -0500 Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-ssh@netbsd.org, Jakob Schlyter To: sommerfeld@east.sun.com From: wes In-Reply-To: <200303210518.h2L5Isaj005875@thunk.east.sun.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, March 21, 2003, at 12:18 AM, Bill Sommerfeld wrote: >>> An alternate approach which I think is superior is to ensure that the >>> DNS search path used while resolving SSHFP records comes from a >>> trusted >>> source (i.e., not from DHCP or PPP/ipcp). >> >> how can the ssh client implementation ensure that? > > The ssh client can't, but a system containing an ssh client could. > > Security considerations are not just for subsystem implementors; > they're also for the users.. Agreed. I put this paragraph together last week, it addresses the search path concerns through configuration of the "system" instead of the implementation. Index: draft-ietf-secsh-dns-xx.xml =================================================================== RCS file: /cvs/sshdev/draft/draft-ietf-secsh-dns-xx.xml,v retrieving revision 1.44 diff -u -r1.44 draft-ietf-secsh-dns-xx.xml --- draft-ietf-secsh-dns-xx.xml 20 Mar 2003 00:42:42 -0000 1.44 +++ draft-ietf-secsh-dns-xx.xml 20 Mar 2003 23:31:06 -0000 @@ -315,6 +315,15 @@ + A different approach to solve the DNS search path issue would be for + clients to use a trusted DNS search path, i.e., one not acquired + through DHCP or other autoconfiguration mechanisms. Since there is + no way for the DNS lookup APIs to tell whether a search path is from + a trusted source, the entire client system would need to be + configured with this trusted DNS search path. + + + Another dependency is on the implementation of DNSSEC itself. As stated in , we mandate the use of secure methods for lookup and that SSHFP RRs are authenticated by From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 24 14:26:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29738 for ; Mon, 24 Mar 2003 14:26:13 -0500 (EST) Received: (qmail 26517 invoked by uid 605); 24 Mar 2003 19:28:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26509 invoked from network); 24 Mar 2003 19:28:24 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 24 Mar 2003 19:28:24 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03676; Mon, 24 Mar 2003 12:28:22 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OJSLuK000070; Mon, 24 Mar 2003 14:28:21 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJSLaj022921; Mon, 24 Mar 2003 14:28:21 -0500 (EST) Message-Id: <200303241928.h2OJSLaj022921@thunk.east.sun.com> From: Bill Sommerfeld To: wes cc: ietf-ssh@netbsd.org, Jakob Schlyter Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt In-Reply-To: Your message of "Mon, 24 Mar 2003 11:29:24 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 24 Mar 2003 14:28:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [wg chair hat off] > A different approach to solve the DNS search path issue would be for > clients to use a trusted DNS search path, i.e., one not acquired > through DHCP or other autoconfiguration mechanisms. Good. > Since there is > no way for the DNS lookup APIs to tell whether a search path is from > a trusted source, the entire client system would need to be > configured with this trusted DNS search path. I'd say "No way with current DNS lookup API's to tell.." instead of assuming that this will be true for all time.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 24 14:35:08 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00078 for ; Mon, 24 Mar 2003 14:35:08 -0500 (EST) Received: (qmail 932 invoked by uid 605); 24 Mar 2003 19:37:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 925 invoked from network); 24 Mar 2003 19:37:22 -0000 Received: from ganymede.jtan.com (207.106.84.133) by mail.netbsd.org with SMTP; 24 Mar 2003 19:37:22 -0000 Received: from jtan.com (wgriffin@callisto.jtan.com [207.106.84.134]) by ganymede.jtan.com (8.11.0/8.11.0) with ESMTP id h2OJbIq10249; Mon, 24 Mar 2003 14:37:19 -0500 (EST) Date: Mon, 24 Mar 2003 14:37:41 -0500 Subject: Re: WG chair nits on draft-ietf-secsh-dns-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ietf-ssh@netbsd.org, Jakob Schlyter To: sommerfeld@east.sun.com From: wes In-Reply-To: <200303241928.h2OJSLaj022921@thunk.east.sun.com> Message-Id: <14155950-5E30-11D7-BBE2-000393D121BA@jtan.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, March 24, 2003, at 02:28 PM, Bill Sommerfeld wrote: > [wg chair hat off] > >> A different approach to solve the DNS search path issue would be for >> clients to use a trusted DNS search path, i.e., one not acquired >> through DHCP or other autoconfiguration mechanisms. > > Good. > >> Since there is >> no way for the DNS lookup APIs to tell whether a search path is >> from >> a trusted source, the entire client system would need to be >> configured with this trusted DNS search path. > > I'd say "No way with current DNS lookup API's to tell.." instead of > assuming that this will be true for all time.. Yep, sounds good. I'll make the change. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 25 08:13:42 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08753 for ; Tue, 25 Mar 2003 08:13:41 -0500 (EST) Received: (qmail 12832 invoked by uid 605); 25 Mar 2003 13:15:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12825 invoked from network); 25 Mar 2003 13:15:49 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 25 Mar 2003 13:15:49 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08704; Tue, 25 Mar 2003 08:13:11 -0500 (EST) Message-Id: <200303251313.IAA08704@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-newmodes-00.txt Date: Tue, 25 Mar 2003 08:13:10 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Encryption Modes Author(s) : M. Bellare et al. Filename : draft-ietf-secsh-newmodes-00.txt Pages : 11 Date : 2003-3-24 Researchers have recently discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy and integrity/authenticity attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-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-newmodes-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-newmodes-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-3-24141459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-newmodes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-newmodes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-24141459.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 25 08:44:39 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10985 for ; Tue, 25 Mar 2003 08:44:37 -0500 (EST) Received: (qmail 28249 invoked by uid 605); 25 Mar 2003 13:46:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28242 invoked from network); 25 Mar 2003 13:46:52 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 25 Mar 2003 13:46:52 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.8/8.12.8) with ESMTP id h2PDkoon026628 for ; Tue, 25 Mar 2003 13:46:51 GMT Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id DE30C34081; Tue, 25 Mar 2003 14:45:25 +0100 (CET) Date: Tue, 25 Mar 2003 14:45:25 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-newmodes-00.txt Message-ID: <20030325134525.GA19134@folly> References: <200303251313.IAA08704@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303251313.IAA08704@ietf.org> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 25, 2003 at 08:13:10AM -0500, Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-00.txt has anyone implemented this? i'd like to do some interop testing if possible. thanks, -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 26 02:43:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17076 for ; Wed, 26 Mar 2003 02:43:57 -0500 (EST) Received: (qmail 2550 invoked by uid 605); 26 Mar 2003 07:46:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2543 invoked from network); 26 Mar 2003 07:46:08 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 26 Mar 2003 07:46:08 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id A09D33BD0E; Wed, 26 Mar 2003 08:46:06 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id D56F66C8C1; Wed, 26 Mar 2003 08:46:08 +0100 (MET) Received: from localhost (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 547FB317E1; Wed, 26 Mar 2003 08:46:05 +0100 (MET) Date: Wed, 26 Mar 2003 08:46:01 +0100 (CET) From: maf@appgate.com Reply-To: maf@appgate.com Subject: Re: I-D ACTION:draft-ietf-secsh-newmodes-00.txt To: markus@openbsd.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20030326074605.547FB317E1@pelee.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list On 25 Mar, Markus Friedl wrote: > has anyone implemented this? I am looking into implementing it in MindTerm. > i'd like to do some interop testing if possible. Would be great. I'll get back to you in a couple of days when I have some code. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 26 04:13:37 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18849 for ; Wed, 26 Mar 2003 04:13:37 -0500 (EST) Received: (qmail 15283 invoked by uid 605); 26 Mar 2003 09:15:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15274 invoked from network); 26 Mar 2003 09:15:48 -0000 Received: from p50852978.dip0.t-ipconnect.de (HELO tickit.tick-it.de) (80.133.41.120) by mail.netbsd.org with SMTP; 26 Mar 2003 09:15:48 -0000 Received: from siliconcircus.com (sircus@[192.168.1.102]) by tickit.tick-it.de (8.11.6/8.11.6) with ESMTP id h2QA1O228112; Wed, 26 Mar 2003 11:01:25 +0100 Message-ID: <3E816FE3.9030902@siliconcircus.com> Date: Wed, 26 Mar 2003 10:16:19 +0100 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Friedl CC: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-newmodes-00.txt References: <200303251313.IAA08704@ietf.org> <20030325134525.GA19134@folly> In-Reply-To: <20030325134525.GA19134@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 Tue, Mar 25, 2003 at 08:13:10AM -0500, Internet-Drafts@ietf.org wrote: > >>http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-00.txt > > > has anyone implemented this? I'll be implementing it shortly in PenguiNet (Win32). If you'd like a beta, just let me know. Is this now in OpenSSH CVS, or is there another way to get hold of an OpenSSH with this implemented in order that I can also do my own interop testing? -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 26 13:58:54 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07375 for ; Wed, 26 Mar 2003 13:58:53 -0500 (EST) Received: (qmail 16290 invoked by uid 605); 26 Mar 2003 19:01:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16283 invoked from network); 26 Mar 2003 19:01:07 -0000 Received: from adsl-64-123-27-105.dsl.austtx.swbell.net (HELO pyramid.twistedmatrix.com) (64.123.27.105) by mail.netbsd.org with SMTP; 26 Mar 2003 19:01:07 -0000 Received: from z3p by pyramid.twistedmatrix.com with local (Exim 3.35 #1 (Debian)) id 18yGB1-0002os-00 for ; Wed, 26 Mar 2003 13:03:07 -0600 Date: Wed, 26 Mar 2003 13:03:07 -0600 From: Paul Swartz To: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-newmodes-00.txt Message-ID: <20030326190307.GB4279@pyramid.twistedmatrix.com> Mail-Followup-To: ietf-ssh@netbsd.org References: <200303251313.IAA08704@ietf.org> <20030325134525.GA19134@folly> <3E816FE3.9030902@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E816FE3.9030902@siliconcircus.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus Friedl wrote: >On Tue, Mar 25, 2003 at 08:13:10AM -0500, Internet-Drafts@ietf.org wrote: > >>http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-00.txt > > >has anyone implemented this? Yes, I have now. A test server is available at twistedmatrix.com:5022, user:'user', password:'password'. It should just print out 'It worked!' and disconnect. The code in CVS, instructions are at twistedmatrix.com. -p -- Paul Swartz (o_ http://www.twistedmatrix.com/users/z3p.twistd/ _o) //\ z3p@twistedmatrix.com /\\ V_/_ AIM: z3penguin _\_V-> From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 26 14:10:48 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07872 for ; Wed, 26 Mar 2003 14:10:47 -0500 (EST) Received: (qmail 21193 invoked by uid 605); 26 Mar 2003 19:06:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21155 invoked from network); 26 Mar 2003 19:06:25 -0000 Received: from adsl-64-123-27-105.dsl.austtx.swbell.net (HELO pyramid.twistedmatrix.com) (64.123.27.105) by mail.netbsd.org with SMTP; 26 Mar 2003 19:06:25 -0000 Received: from z3p by pyramid.twistedmatrix.com with local (Exim 3.35 #1 (Debian)) id 18yGGH-0002uO-00 for ; Wed, 26 Mar 2003 13:08:33 -0600 Date: Wed, 26 Mar 2003 13:08:33 -0600 From: Paul Swartz To: ietf-ssh@netbsd.org Subject: Re: I-D ACTION:draft-ietf-secsh-newmodes-00.txt Message-ID: <20030326190833.GC4279@pyramid.twistedmatrix.com> Mail-Followup-To: ietf-ssh@netbsd.org References: <200303251313.IAA08704@ietf.org> <20030325134525.GA19134@folly> <3E816FE3.9030902@siliconcircus.com> <20030326190307.GB4279@pyramid.twistedmatrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030326190307.GB4279@pyramid.twistedmatrix.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list Oh, and the public host-key is: ---- BEGIN SSH2 PUBLIC KEY ---- AAAAB3NzaC1yc2EAAAABIwAAAGEArzJx8OYOnJmzf4tfBEvLi8DVPrJ3/c9k2I/Az64fxjH f9imyRJbixtQhlH9lfNjUIx+4LmrJH5QNRsFporcHDKOTwTTYLh5KmRpslkYHRivcJSkbh/ C+BR3utDS555mV ---- END SSH2 PUBLIC KEY ---- -p -- Paul Swartz (o_ http://www.twistedmatrix.com/users/z3p.twistd/ _o) //\ z3p@twistedmatrix.com /\\ V_/_ AIM: z3penguin _\_V-> From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 27 07:46:51 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25595 for ; Thu, 27 Mar 2003 07:46:51 -0500 (EST) Received: (qmail 22461 invoked by uid 605); 27 Mar 2003 12:49:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22454 invoked from network); 27 Mar 2003 12:49:03 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Mar 2003 12:49:03 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25547; Thu, 27 Mar 2003 07:46:39 -0500 (EST) Message-Id: <200303271246.HAA25547@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-dns-03.txt Date: Thu, 27 Mar 2003 07:46:39 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Using DNS to securely publish SSH key fingerprints Author(s) : J. Schlyter, W. Griffin Filename : draft-ietf-secsh-dns-03.txt Pages : 11 Date : 2003-3-26 This document describes a method to verify SSH host keys using DNSSEC. The document defines a new DNS resource record that contains a standard SSH key fingerprint. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-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-dns-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-dns-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-3-26123057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dns-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dns-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26123057.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 27 14:27:15 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14119 for ; Thu, 27 Mar 2003 14:27:14 -0500 (EST) Received: (qmail 864 invoked by uid 605); 27 Mar 2003 19:29:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 857 invoked from network); 27 Mar 2003 19:29:32 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 27 Mar 2003 19:29:32 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22532 for ; Thu, 27 Mar 2003 12:29:28 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJTSuK010186 for ; Thu, 27 Mar 2003 14:29:28 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJTSaj019868 for ; Thu, 27 Mar 2003 14:29:28 -0500 (EST) Message-Id: <200303271929.h2RJTSaj019868@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: draft-ietf-secsh-dns-03.txt sent to our AD. Reply-to: sommerfeld@sun.com Date: Thu, 27 Mar 2003 14:29:28 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list FYI, I've sent draft-ietf-secsh-dns-03.txt to Russ Housley. One down, N more to go.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 27 17:00:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21480 for ; Thu, 27 Mar 2003 17:00:51 -0500 (EST) Received: (qmail 28812 invoked by uid 605); 27 Mar 2003 22:02:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28710 invoked from network); 27 Mar 2003 22:02:32 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 27 Mar 2003 22:02:32 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27501; Thu, 27 Mar 2003 14:02:21 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RM2L9P013858; Thu, 27 Mar 2003 17:02:21 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RM2Laj014273; Thu, 27 Mar 2003 17:02:21 -0500 (EST) Message-Id: <200303272202.h2RM2Laj014273@thunk.east.sun.com> From: Bill Sommerfeld To: Joseph Galbraith cc: ietf-ssh@netbsd.org Subject: for security considerations: smb key fingerprint text. Reply-to: sommerfeld@sun.com Date: Thu, 27 Mar 2003 17:02:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Steve Bellovin and I came up with: > Server administrators are encouraged to make host key > fingerprints available for checking by some means whose > security does not rely on the integrity of the actual host > keys. Possible mechanisms include secured Web pages, the DNS > [draft-ietf-secsh-dns], physical pieces of paper, etc. > Implementors should provide recommendations on how best to do > this with their implementation. If anyone else has thoughts on this, please let the WG know.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 27 18:53:23 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26766 for ; Thu, 27 Mar 2003 18:53:23 -0500 (EST) Received: (qmail 26318 invoked by uid 605); 27 Mar 2003 23:55:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26307 invoked from network); 27 Mar 2003 23:55:37 -0000 Received: from unknown (HELO neo.ramsys.net) (216.226.20.213) by mail.netbsd.org with SMTP; 27 Mar 2003 23:55:37 -0000 Received: (from http@localhost) by neo.ramsys.net (8.10.0/8.10.1) id h2RNtHk27922; Thu, 27 Mar 2003 17:55:17 -0600 Date: Thu, 27 Mar 2003 17:55:17 -0600 Message-Id: <200303272355.h2RNtHk27922@neo.ramsys.net> To: 48@36.com From: 5o3f@d5ug.com (5o3f@d5ug.com) Subject: Insane GIRLS In Crazy Videos... Sender: ietf-ssh-owner@netbsd.org Precedence: list I want u to come and check me out. I wont charge you anything. Lets just keep it between me and u. LOL CLICK THE BLUE LINK BELOW!!! INNOCENT CLICK THE LINK FOR ACCESS... CLICK HERE If you would like to no longer receive any of our promotions simply visit the advertised website and remove yourself by clicking the link at the bottom. du From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 29 11:33:24 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24985 for ; Sat, 29 Mar 2003 11:33:22 -0500 (EST) Received: (qmail 26965 invoked by uid 605); 29 Mar 2003 16:35:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26954 invoked from network); 29 Mar 2003 16:35:41 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Mar 2003 16:35:41 -0000 Received: from [127.0.0.1] (HELO ENTROPY) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1416689; Sat, 29 Mar 2003 09:35:39 -0700 Message-ID: <001001c2f610$ebd6fcc0$d800a8c0@vandyke.connectathon.org> From: "Joseph Galbraith" To: "Joseph Galbraith" , , Cc: , References: <200302210212.h1L2Cbaj006356@thunk.east.sun.com> <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.com> Subject: Re: IESG feedback on core drafts. Date: Sat, 29 Mar 2003 08:33:25 -0800 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit All right; here is version two, to be added to the architecture draft. I'd appreciate feedback. - Joseph ----- Here is my proposed revision: 11. Security Considerations In order to make the entire body of Security Considerations more accessible, Security Considerations for the transport, authentication, and connection documents have been gathered here. The transport protocol [1] provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [2] provides a suite of mechanism which can be used to authenticating the client user. Individual mechanisms specified in the in authentication protocol use teh session id provided by the transport protocol and/or depend on the security and integrity gaurentees of the transport protocol. The connection protocol [3] specifies a mechanism to multiplex multiple streams [channels] of data over the secure transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 11.1 Transport 11.1.1 Confidentiality This protocol does allow the encryption mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" method is enabled. So long as the "none" cipher is not used, this protocol provides confidentiality. Older, smaller ciphers, such as 3des and arcfour MAY be less secure from attack than ciphers such as AES. Implementors SHOULD prefer ciphers such as twofish, serpent, or AES over blowfish, 3des and arcfour. With ciphers operating in CBC mode is theoretically vulnerable to choosen cipher-text attacks because of the high predicability of the start of packet sequence. However, this attack is still relatively hard enough, and requires a sufficiently high number of packets, to be safe in the short term. Ciphers with larger block sizes are less vulnerable the ciphers with smaller block sizes. [Is this true?] Effort is underway to standardize the use of CTR mode ciphers in the SSH protocol. When this work is completed, implementors SHOULD support it. In addition, the CBC mode attack can be mitigated by ensuring the an SSH_MSG_IGNORE packet preceeds any real data at the start of a TCP packet. [Is this true? 26 of the 32 length bits can probably be reliably guessed to be 0. One or two of the pad length bits are likewise reliably guessed as 0. The packet type is known. 26 of the length field of the string in an ignore packet are known. So 26 + 2 + 8 + 16 = 52 of the first 64 bits are reliablely known (or 62 of the first 128 bits) -- my understanding is hazy-- is this applicable to the vulnerability?] 11.1.2 Data Integrity This protocol does allow the Data Integrity mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" mac is enabled. So long as the "none" mac is not used, this protocol provides data integrity. Because MACs use a 32 bit sequence number, they may start to leak information after 2**32 packets have been sent. However, following the rekeying recomendations should prevent this attack. The transport protocol [1] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying should happen after 2**28 packets at the very most. 11.1.3 Replay This protocol binds each session key to the session by including random data that is specific to the session in the hash used to produce session keys. This session id is used by higher level protocols to prevent replay of packets form previous sessions. In addition, the use of cipher chaining prevents replay of packets within the session. Cipher chaining also prevents the insertion or deletion of packets. 11.1.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure for distributing public keys. It is expected that this protocol will sometimes be used without insisting on reliable association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This vulnerability to man-in-the-middle attacks can be mitigated in several fashions: 1. Narrow the window. If the client ensures that the host key for a given server remains consistant, an attacker must execute the man-in-the-middle attack on the _first_ connection to a given server. 2. Use an authentication method that is not vulnerable to man-in-the-middle. For example, public-key authentication is not vulnerable to man-in-the-middle attack, because the signature is made across data that is session specific. The attack can not use the signature he receives because the session specific data between the attacker and server is different, and can not create a valid signature because he does not have the private key. However, this does assume that the public-key has been distributed to the server host in some secure fashion before the first SSH connection can be made. 3. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, storing the hostkey fingerprint in a secure dns database, or using kerberos over gssapi during keyexchange to authenticate the server. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms include secured Web pages, the DNS [draft-ietf-secsh-dns], physical pieces of paper, etc. Implementors should provide recommendations on how best to do this with their implementation. Use of this protocol without reliable association is inherently insecure, but may be necessary in non-security critical environments, and still provides protection against passive attacks. However, implementors of protocols running on top of this protocol should keep this possibility in mind. 11.1.5 Denial-of-service This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid. In addition, this protocol is vulnerable to Denial of Service attacks because an attacker can force the server to go through the CPU and memory intensive tasks of connection setup and key exchange without authenticating. Implementors SHOULD provide features that make this more difficult. For example, only allowing connections from a subset of IPs known to have valid users. 11.1.6 Covert Channels The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way to verify whether such information is being sent. 11.2 Authentication Protocol The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. The transport layer provides forward secrecy for password authentication and other methods that rely on secret data. The server may go into a "sleep" period after repeated unsuccessful authentications to make key search harder. Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed. 11.2.1 Weak Transport If the transport layer does not provide encryption, authentication methods that rely on secret data SHOULD be disabled. If it does not provide MAC protection, requests to change authentication data (e.g. password change) SHOULD be disabled to avoid an attacker from modifying the ciphertext without being noticed, rendering the new authentication data unusable (denial of service). 11.2.2 Debug messages Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during user authentication phase) if high security is required. 11.2.3 Local security policy Authentication is always a delicate security operation. Implementor MUST not only ensure that the credentials given validate the professed user, but also that the local policy of the server hosts allows the user the access requested. In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine this completely at the time of authentication, because the kind of service being requested is not yet clear. For example, local policy might allow a user to access files on the server, but not start an interactive shell. However, during the authentication protocol, it is not known whether the user will be accessing files or attempting to use an interactive shell, or even both. In any event, local security policy for the server host MUST be applied and enforced correctly. 11.2.4 Public key authentication The use of public-key authentication assumes that the client host has not been compromised. This risk can be mitigated by the use of passphrases on private keys; however, this is not an enforcable policy. The use of smartcards, or other technology to make passphrases an enforcable policy is suggested. The server could require both password and public-key authentication, however, this requires the client to expose its password to the server (see section on password authentication below.) 11.2.5 Password authentication The password mechanism of specified in the authentication protocol assumes that the server has not been compromised. If the server has been compromised, using password authentication will reveal a valid username / password combination to the attacker, which may lead to further comprimises. This vulnerability can be mitigated by using an alternative form of authentication. For example, public-key authentication makes no assumptions about security on the server. 11.2.6 Host based authentication Host based authentication assumes that the client has not been compromised. There are no mitaging strategies, other than to use host based authentication in combination with another authentication method. 11.3 Connection protocol 11.3.1 End point security End point security is assumed by the connection protocol. If the server has been compromised, any terminal sessions, port forwarding, or systems accessed on the host are comprimised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 11.3.2 Proxy forwarding The ssh connection protocol allows proxy forwarding of other protocols. The proxy forwarding functionality can be used to circumvent firewall protections. Implementors SHOULD provide a mechanism to disable to administratively control the proxy forwarding funcitonality. In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls. As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data pass over proxy forwarding. 11.3.3 X11 forwarding Another form of proxy forwarding provided by the ssh connection protocol is the forwarding of the X11 protocol. Implementors of the X11 protocol SHOULD implement the magic cookie spoofing, to prevent unauthorized use of the proxy. X11 forwarding relies on end-point security. If end-point security has been compromised, X11 forwarding will allow any attack against the X11 server possible locally. Users and administors should, as a matter of course, use X11 security mechanism to prevent unauthorized use of the X11 server. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 29 11:46:06 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25314 for ; Sat, 29 Mar 2003 11:46:05 -0500 (EST) Received: (qmail 4081 invoked by uid 605); 29 Mar 2003 16:48:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4074 invoked from network); 29 Mar 2003 16:48:24 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Mar 2003 16:48:24 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1416732; Sat, 29 Mar 2003 09:48:23 -0700 Message-ID: <02fb01c2f613$0220a2e0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Cc: Subject: Please publish attached draft-ietf-secsh-break-01 Date: Sat, 29 Mar 2003 09:48:21 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02F8_01C2F5D8.559BA540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_02F8_01C2F5D8.559BA540 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please publish the attached draft, draft-ietf-secsh-break-01.txt. Thank you, Joseph ------=_NextPart_000_02F8_01C2F5D8.559BA540 Content-Type: text/plain; name="draft-ietf-secsh-break-01.txt" Content-Disposition: attachment; filename="draft-ietf-secsh-break-01.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= Secure Shell Working Group J. Galbraith=0A= Internet-Draft VanDyke Software=0A= Expires: September 27, 2003 P. Remaker=0A= Cisco Systems, Inc=0A= March 29, 2003=0A= =0A= =0A= Session Channel Break Extension=0A= draft-ietf-secsh-break-01.txt=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that other=0A= groups may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at http://=0A= www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on September 27, 2003.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= The Break Extension provides a way to send a break signal during a=0A= SSH terminal session.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 1]=0A= =0C=0A= Internet-Draft Session Channel Break Extension March 2003=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Break Request . . . . . . . . . . . . . . . . . . . . . . . 4=0A= References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5=0A= Intellectual Property and Copyright Statements . . . . . . . . . 6=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 2]=0A= =0C=0A= Internet-Draft Session Channel Break Extension March 2003=0A= =0A= =0A= 1. Introduction=0A= =0A= The SSH session channel provides a mechanism for the client-user to=0A= interactively enter commands and receive output from a remote host=0A= while taking advantage of the SSH transport's privacy and integrity=0A= features.=0A= =0A= A common application of the telnet protocol is the "Console Server"=0A= whereby a telnet NVT can be connected to a physical RS-232/V.24=0A= asynchronous port, allowing the telnet NVT to appear as a locally=0A= attached terminal to that port, and allowing that port to appear as a=0A= network addressable device. A number of major computer equipment=0A= vendors provide high level administrative functions through an=0A= asynchronous serial port and generally expect the attached terminal=0A= to be capable of send a BREAK signal, which is defined as the TxD=0A= signal being held in a SPACE state for a time greater than a whole=0A= character time, typically interpreted as 250 to 500 ms.=0A= =0A= The telnet protocolprovides a means to send a "BREAK" signal, which=0A= is defined as a "a signal outside the USASCII set which is currently=0A= given local meaning within many systems." [1] Console Server vendors=0A= interpret the TELNET break signal as a physical break signal, which=0A= can then allow access to the full range of administartive functions=0A= available on an asynchronous serial console port.=0A= =0A= The lack of a similar facility in the SSH session channel has forced=0A= users to continue the use of telnet for the "Console Server"=0A= function.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 3]=0A= =0C=0A= Internet-Draft Session Channel Break Extension March 2003=0A= =0A= =0A= 2. The Break Request=0A= =0A= The following following channel specific request can be sent to=0A= request that the remote host perform a break operation.=0A= =0A= byte SSH_MSG_CHANNEL_REQUEST=0A= uint32 recipient channel=0A= string "break"=0A= boolean want_reply=0A= uint32 break-length in milliseconds=0A= =0A= If the break length cannot be controlled by the application receiving=0A= this request, the break length parameter SHOULD be ignored and the=0A= default break signal length of the chipset or underlying chipset=0A= driver SHOULD be sent.=0A= =0A= If the application can control the break-length, the following=0A= suggestions are made reagarding break duration. If a break duration=0A= request of greater than 3000ms is received, it SHOULD be processed as=0A= a 3000ms break, in order to an unreasonably long break request=0A= causing the port to become unavailable for as long as 47 days while=0A= executing the break. Applications that require a longer break may=0A= choose to ignore this requirement. If break duration request of=0A= less than 500ms, is requested a break of 500ms SHOULD be sent since=0A= most devices will recognize a break of that length. In the event=0A= that an application needs a shorter break, this can be ignored. If=0A= the break-length parameter is 0, the break SHOULD be sent as 500ms or=0A= the default break signal length of the chipset or underlying chipset=0A= driver .=0A= =0A= If the want_reply boolean is set, the server MUST reply using=0A= SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE [4] messages. If=0A= a break of any kind was preformed, SSH_MSG_CHANNEL_SUCCESS MUST be=0A= sent. If no break was preformed, SSH_MSG_CHANNEL_FAILURE MUST be=0A= sent.=0A= =0A= This operation SHOULD be support by most general purpose SSH clients.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 4]=0A= =0C=0A= Internet-Draft Session Channel Break Extension March 2003=0A= =0A= =0A= References=0A= =0A= [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD=0A= 8, RFC 854, May 1983.=0A= =0A= [2] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH=0A= Protocol Architecture", draft-ietf-secsh-architecture-13 (work=0A= in progress), September 2002.=0A= =0A= [3] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.=0A= Lehtinen, "SSH Transport Layer Protocol",=0A= draft-ietf-secsh-transport-15 (work in progress), September=0A= 2002.=0A= =0A= [4] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH=0A= Connection Protocol", draft-ietf-secsh-connect-16 (work in=0A= progress), September 2002.=0A= =0A= =0A= Authors' Addresses=0A= =0A= Joseph Galbraith=0A= VanDyke Software=0A= 4848 Tramway Ridge Blvd=0A= Suite 101=0A= Albuquerque, NM 87111=0A= US=0A= =0A= Phone: +1 505 332 5700=0A= EMail: galb-list@vandyke.com=0A= =0A= =0A= Phillip Remaker=0A= Cisco Systems, Inc=0A= 170 West Tasman Drive=0A= San Jose, CA 95120=0A= US=0A= =0A= EMail: remaker@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 5]=0A= =0C=0A= Internet-Draft Session Channel Break Extension March 2003=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= intellectual property or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; neither does it represent that it=0A= has made any effort to identify any such rights. Information on the=0A= IETF's procedures with respect to rights in standards-track and=0A= standards-related documentation can be found in BCP-11. Copies of=0A= claims of rights made available for publication and any assurances of=0A= licenses to be made available, or the result of an attempt made to=0A= obtain a general license or permission for the use of such=0A= proprietary rights by implementors or users of this specification can=0A= be obtained from the IETF Secretariat.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights which may cover technology that may be required to practice=0A= this standard. Please address the information to the IETF Executive=0A= Director.=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assignees.=0A= =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 6]=0A= =0C=0A= Internet-Draft Session Channel Break Extension March 2003=0A= =0A= =0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith & Remaker Expires September 27, 2003 [Page 7]=0A= =0C=0A= =0A= ------=_NextPart_000_02F8_01C2F5D8.559BA540-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 29 12:06:28 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25558 for ; Sat, 29 Mar 2003 12:06:28 -0500 (EST) Received: (qmail 16889 invoked by uid 605); 29 Mar 2003 17:08:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16880 invoked from network); 29 Mar 2003 17:08:48 -0000 Received: from romeo.rtfm.com (198.144.203.242) by mail.netbsd.org with SMTP; 29 Mar 2003 17:08:48 -0000 Received: by romeo.rtfm.com (Postfix, from userid 556) id 9AE00AB6D; Sat, 29 Mar 2003 09:14:16 -0800 (PST) To: "Joseph Galbraith" Cc: , , , Subject: Re: IESG feedback on core drafts. References: <200302210212.h1L2Cbaj006356@thunk.east.sun.com> <000501c2e999$29c4d9f0$4d00a8c0@galb.vandyke.com> <001001c2f610$ebd6fcc0$d800a8c0@vandyke.connectathon.org> Reply-To: EKR From: Eric Rescorla Date: 29 Mar 2003 09:14:16 -0800 In-Reply-To: <001001c2f610$ebd6fcc0$d800a8c0@vandyke.connectathon.org> Message-ID: Lines: 70 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list Some detailed comments, "Joseph Galbraith" writes: > So long as the "none" cipher is not used, this protocol > provides confidentiality. Older, smaller ciphers, such Why do you say "smaller". How is 3DES smaller than AES? > as 3des and arcfour MAY be less secure from attack than > ciphers such as AES. Implementors SHOULD prefer ciphers > such as twofish, serpent, or AES over blowfish, 3des and > arcfour. Why would you recommend twofish and serpent over 3DES? 3DES has received vastly more analysis than either. > With ciphers operating in CBC mode is theoretically > vulnerable to choosen cipher-text attacks because of > the high predicability of the start of packet sequence. > However, this attack is still relatively hard enough, and > requires a sufficiently high number of packets, to be safe > in the short term. Ciphers with larger block sizes are > less vulnerable the ciphers with smaller block sizes. > [Is this true?] What attack are you talking about here? The Rogaway attack? Perhaps you need a citation and some explanation? > Effort is underway to standardize the use of CTR mode > ciphers in the SSH protocol. When this work is completed, > implementors SHOULD support it. > > In addition, the CBC mode attack can be mitigated by > ensuring the an SSH_MSG_IGNORE packet preceeds any real > data at the start of a TCP packet. A TCP packet? How is the TCP mapping relevant? > Because MACs use a 32 bit sequence number, they may > start to leak information after 2**32 packets have > been sent. You should be specific here about how they leak data. > 11.1.3 Replay > > This protocol binds each session key to the session > by including random data that is specific to the > session in the hash used to produce session keys. > > This session id is used by higher level protocols > to prevent replay of packets form previous sessions. ^^^^ from. > In addition, the use of cipher chaining prevents > replay of packets within the session. Cipher chaining > also prevents the insertion or deletion of packets. I'm not sure this is true if the MAC is disabled. > 11.3.2 Proxy forwarding > > The ssh connection protocol allows proxy forwarding > of other protocols. The proxy forwarding functionality > can be used to circumvent firewall protections. Implementors > SHOULD provide a mechanism to disable to administratively > control the proxy forwarding funcitonality. This sentence is ungrammatical. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 29 12:24:39 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25920 for ; Sat, 29 Mar 2003 12:24:39 -0500 (EST) Received: (qmail 26861 invoked by uid 605); 29 Mar 2003 17:27:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26846 invoked from network); 29 Mar 2003 17:26:59 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 29 Mar 2003 17:26:59 -0000 Received: from CELLO (c-24-126-120-178.we.client2.attbi.com [24.126.120.178]) by carnelian.propagation.net (8.9.3/8.8.5) with SMTP id LAA04755; Sat, 29 Mar 2003 11:26:38 -0600 From: "Howard Chu" To: "'EKR'" , "'Joseph Galbraith'" Cc: , , , Subject: RE: IESG feedback on core drafts. Date: Sat, 29 Mar 2003 09:25:49 -0800 Message-ID: <001b01c2f618$47636720$0e01a8c0@CELLO> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 Eric Rescorla > Some detailed comments, > This sentence is ungrammatical. > > "Joseph Galbraith" writes: > > With ciphers operating in CBC mode is theoretically > > vulnerable to choosen cipher-text attacks because of > > the high predicability of the start of packet sequence. Likewise. Aside from "chosen" it's still unparsable. > > However, this attack is still relatively hard enough, and > > requires a sufficiently high number of packets, to be safe > > in the short term. Ciphers with larger block sizes are > > less vulnerable the ciphers with smaller block sizes. > > [Is this true?] > What attack are you talking about here? The Rogaway attack? > Perhaps you need a citation and some explanation? > > > > Effort is underway to standardize the use of CTR mode > > ciphers in the SSH protocol. When this work is completed, > > implementors SHOULD support it. > > > > In addition, the CBC mode attack can be mitigated by > > ensuring the an SSH_MSG_IGNORE packet preceeds any real ^^^ that -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 31 06:45:18 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02740 for ; Mon, 31 Mar 2003 06:45:16 -0500 (EST) Received: (qmail 19700 invoked by uid 605); 31 Mar 2003 11:47:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19693 invoked from network); 31 Mar 2003 11:47:31 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 31 Mar 2003 11:47:31 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02728; Mon, 31 Mar 2003 06:45:05 -0500 (EST) Message-Id: <200303311145.GAA02728@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-fingerprint-01.txt Date: Mon, 31 Mar 2003 06:45:04 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Fingerprint Format Author(s) : M. Friedl Filename : draft-ietf-secsh-fingerprint-01.txt Pages : 2 Date : 2003-3-28 This document formally documents the fingerprint format in use for verifying public keys from SSH clients and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-fingerprint-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-fingerprint-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-fingerprint-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-28142359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-fingerprint-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-fingerprint-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-28142359.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 31 11:06:42 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12465 for ; Mon, 31 Mar 2003 11:06:40 -0500 (EST) Received: (qmail 614 invoked by uid 605); 31 Mar 2003 16:09:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 507 invoked from network); 31 Mar 2003 16:09:00 -0000 Received: from edison.cisco.com (171.70.144.164) by mail.netbsd.org with SMTP; 31 Mar 2003 16:09:00 -0000 Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA22545 for ; Mon, 31 Mar 2003 08:08:59 -0800 (PST) Date: Mon, 31 Mar 2003 08:08:59 -0800 (PST) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, My attempts at resolution in-line. I will note that I make no claim to cryptographic abilities. I've merely tried to work Joseph's thoughts into a hopefully more palatable contribution. :-) On 29 Mar 2003, Eric Rescorla wrote: > Some detailed comments, > > "Joseph Galbraith" writes: > > So long as the "none" cipher is not used, this protocol > > provides confidentiality. Older, smaller ciphers, such > Why do you say "smaller". How is 3DES smaller than AES? > > > as 3des and arcfour MAY be less secure from attack than > > ciphers such as AES. Implementors SHOULD prefer ciphers > > such as twofish, serpent, or AES over blowfish, 3des and > > arcfour. > Why would you recommend twofish and serpent over 3DES? > 3DES has received vastly more analysis than either. Replace with: It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry. At the time of this writing, ciphers commonly in use include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has been accepted by cryptographic experts as being stronger than most of the other ciphers in use today and it is being implemented in other security protocols as it is within SSH. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. Implementors may wish to offer relatively weaker ciphers in their products for interoperability but should strive to depricate them as soon as possible. The "none" cipher is provided for debugging and should never be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410. [This last part should probably be worked into the preceding paragraph in Joseph's original proposal - paragrph 1 of section 11.1.] > > > With ciphers operating in CBC mode is theoretically > > vulnerable to choosen cipher-text attacks because of > > the high predicability of the start of packet sequence. > > However, this attack is still relatively hard enough, and > > requires a sufficiently high number of packets, to be safe > > in the short term. Ciphers with larger block sizes are > > less vulnerable the ciphers with smaller block sizes. > > [Is this true?] > What attack are you talking about here? The Rogaway attack? > Perhaps you need a citation and some explanation? Replace with: The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack is still deemed difficult and not considered fully practicable especially if relatively longer block sizes are used. [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley and Sons Publisher, 1996 [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, Prentice Hall Publisher, 1995 > > > > Effort is underway to standardize the use of CTR mode > > ciphers in the SSH protocol. When this work is completed, > > implementors SHOULD support it. > > > > In addition, the CBC mode attack can be mitigated by > > ensuring the an SSH_MSG_IGNORE packet preceeds any real > > data at the start of a TCP packet. > A TCP packet? How is the TCP mapping relevant? Additionally, the CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. This technique may be used to obfuscate the relative positions of the enciphered message and its use is encouraged. Beyond that, an effort is currently underway to standardize the use of the CTR mode of operation in ciphers used in the SSH protocol. When that work is completed, implementors SHOULD support it as that will obviate the CBC mode attack. > > > Because MACs use a 32 bit sequence number, they may > > start to leak information after 2**32 packets have > > been sent. > You should be specific here about how they leak data. > > > 11.1.3 Replay > > > > This protocol binds each session key to the session > > by including random data that is specific to the > > session in the hash used to produce session keys. > > > > This session id is used by higher level protocols > > to prevent replay of packets form previous sessions. > ^^^^ > from. > > > In addition, the use of cipher chaining prevents > > replay of packets within the session. Cipher chaining > > also prevents the insertion or deletion of packets. > I'm not sure this is true if the MAC is disabled. > > > 11.3.2 Proxy forwarding > > > > The ssh connection protocol allows proxy forwarding > > of other protocols. The proxy forwarding functionality > > can be used to circumvent firewall protections. Implementors > > SHOULD provide a mechanism to disable to administratively > > control the proxy forwarding funcitonality. > This sentence is ungrammatical. Replace with: The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. > > -Ekr > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ > Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 31 11:08:34 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12543 for ; Mon, 31 Mar 2003 11:08:29 -0500 (EST) Received: (qmail 1951 invoked by uid 605); 31 Mar 2003 16:10:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1942 invoked from network); 31 Mar 2003 16:10:48 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 31 Mar 2003 16:10:48 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 72B1F67104; Mon, 31 Mar 2003 11:30:11 -0500 (EST) Date: Mon, 31 Mar 2003 11:10:30 -0500 Subject: Re: IESG feedback on core drafts. Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , , , To: "Joseph Galbraith" From: RJ Atkinson In-Reply-To: <001001c2f610$ebd6fcc0$d800a8c0@vandyke.connectathon.org> Message-Id: <4B482B07-6393-11D7-A792-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Overall, a very good start. Specific nits noted inline. Ran rja@extremenetworks.com On Saturday, Mar 29, 2003, at 11:33 America/Montreal, Joseph Galbraith wrote: > 11. Security Considerations > > In order to make the entire body of Security > Considerations more accessible, Security > Considerations for the transport, authentication, > and connection documents have been gathered here. > > The transport protocol [1] provides a secure encrypted > channel over an insecure network. It performs server s/a secure encrypted channel/a confidential channel/ "encryption" is the mechanism. "confidentiality" is the property. > host authentication, key exchange, encryption, and > integrity protection. It also derives a unique > session id that may be used by higher-level protocols. > > The authentication protocol [2] provides a suite of > mechanism which can be used to authenticating the client > user. Individual mechanisms specified in the in s/user./user to the server./ > authentication protocol use teh session id provided s/teh/the/ > by the transport protocol and/or depend on the security > and integrity gaurentees of the transport protocol. s/guarentees/guarantees/ > The connection protocol [3] specifies a mechanism > to multiplex multiple streams [channels] of data over > the secure transport. It also specifies channels for s/secure transport/confidential and authenticated transport/ > accessing an interactive shell, for 'proxy-forwarding' > various external protocols over the secure transport > (including arbitrary TCP/IP protocols), and for > accessing secure 'subsystems' on the server host. > > 11.1 Transport > > > 11.1.1 Confidentiality > > This protocol does allow the encryption mechanism to be > disabled. Implementors SHOULD be wary of exposing this > feature for any purpose other than debugging. Users and > administrators SHOULD be explicitly warned anytime the > "none" method is enabled. > > So long as the "none" cipher is not used, this protocol > provides confidentiality. Older, smaller ciphers, such > as 3des and arcfour MAY be less secure from attack than > ciphers such as AES. Implementors SHOULD prefer ciphers > such as twofish, serpent, or AES over blowfish, 3des and > arcfour. s/MAY/might/ The capitalised "MAY" as used in IETF documents related only to permission, not to possibilities. In the sentence above, the apparent meaning is that some ciphers might be less desirable than others, so "might" is a more clear choice and capitalised "MAY" is a clearly bad choice. > With ciphers operating in CBC mode is theoretically > vulnerable to choosen cipher-text attacks because of > the high predicability of the start of packet sequence. Not a sentence; please rephrase. Also, please consider adding a bibliographic reference to some paper, article, or book in the published literature. > However, this attack is still relatively hard enough, and > requires a sufficiently high number of packets, to be safe > in the short term. Ciphers with larger block sizes are > less vulnerable the ciphers with smaller block sizes. > [Is this true?] See previous comment. > Effort is underway to standardize the use of CTR mode > ciphers in the SSH protocol. When this work is completed, > implementors SHOULD support it. Premature. Suggest deleting those 2 sentences for now. The issue can be revisited later if/when CTR mode is specified and there is some clear consensus on whether those specs are solid. > In addition, the CBC mode attack can be mitigated by > ensuring the an SSH_MSG_IGNORE packet preceeds any real > data at the start of a TCP packet. > [Is this true? 26 of the 32 length bits can probably > be reliably guessed to be 0. One or two of the pad > length bits are likewise reliably guessed as 0. The > packet type is known. 26 of the length field of the > string in an ignore packet are known. So 26 + 2 + 8 + 16 = > 52 of the first 64 bits are reliablely known (or 62 of > the first 128 bits) -- my understanding is hazy-- is > this applicable to the vulnerability?] We ought avoid making claims unless we are certain that they are valid. Again, it is pleasant to cite some document, paper, or book in the public literature for published claims such as in this document. > 11.1.2 Data Integrity > > This protocol does allow the Data Integrity mechanism to > be disabled. Implementors SHOULD be wary of exposing this > feature for any purpose other than debugging. Users and > administrators SHOULD be explicitly warned anytime the > "none" mac is enabled. > > So long as the "none" mac is not used, this protocol > provides data integrity. > > Because MACs use a 32 bit sequence number, they may s/may/might/ > start to leak information after 2**32 packets have > been sent. However, following the rekeying > recomendations should prevent this attack. > The transport protocol [1] recommends rekeying after > one gigabyte of data, and the smallest possible > packet is 16 bytes. Therefore, rekeying should happen > after 2**28 packets at the very most. s/should happen/SHOULD hapen/ In this case, one appears to be trying to levy implementation guidance, so capitalisation is appropriate. > 11.1.3 Replay > > This protocol binds each session key to the session > by including random data that is specific to the > session in the hash used to produce session keys. Is it random or pseudo-random ? Does the difference matter in this case ? > This session id is used by higher level protocols > to prevent replay of packets form previous sessions. > > In addition, the use of cipher chaining prevents > replay of packets within the session. Cipher chaining > also prevents the insertion or deletion of packets. Citations would be pleasant for these claims. > 11.1.4 Man-in-the-middle > > This protocol makes no assumptions nor provisions for s/no/neither/ > an infrastructure for distributing public keys. It is > expected that this protocol will sometimes be used without > insisting on reliable association between the server host > key and the server host name. Such usage is vulnerable > to man-in-the-middle attacks. > > This vulnerability to man-in-the-middle attacks can > be mitigated in several fashions: > > 1. Narrow the window. If the client ensures that the > host key for a given server remains consistant, an > attacker must execute the man-in-the-middle attack > on the _first_ connection to a given server. Narrow *which* window ? Intended meaning is not crystal clear above. > 2. Use an authentication method that is not vulnerable > to man-in-the-middle. For example, public-key > authentication is not vulnerable to man-in-the-middle > attack, because the signature is made across data > that is session specific. The attack can not use > the signature he receives because the session specific > data between the attacker and server is different, and > can not create a valid signature because he does not > have the private key. Is this really true and sufficient ? > However, this does assume that the public-key has > been distributed to the server host in some secure > fashion before the first SSH connection can be made. > > 3. Because the protocol is extensible, future extensions > to the protocol may provide better mechanisms for dealing s/may/might/ This is not dealing with permissions, but with possibilities. > with the need to know the server's host key before > connecting. For example, storing the hostkey fingerprint > in a secure dns database, or using kerberos over gssapi > during keyexchange to authenticate the server. > > Server administrators are encouraged to make host key > fingerprints available for checking by some means whose > security does not rely on the integrity of the actual host > keys. Possible mechanisms include secured Web pages, the DNS > [draft-ietf-secsh-dns], physical pieces of paper, etc. > Implementors should provide recommendations on how best to do > this with their implementation. s/should provide/SHOULD provide/ Again, this is providing implementation guidance, so ought to be capitalised. > > Use of this protocol without reliable association association of what/whom ? > is inherently insecure, but may be necessary in > non-security critical environments, and still > provides protection against passive attacks. However, > implementors of protocols running on top of this > protocol should keep this possibility in mind. ??? s/protocols running/applications running/ ??? > > 11.1.5 Denial-of-service > > This protocol is designed to be used over a reliable transport. If > transmission errors or message manipulation occur, the connection is > closed. The connection SHOULD be re-established if this occurs. > Denial of service attacks of this type ("wire cutter") are almost > impossible to avoid. > > In addition, this protocol is vulnerable to Denial of Service > attacks because an attacker can force the server to go through > the CPU and memory intensive tasks of connection setup and > key exchange without authenticating. Implementors SHOULD provide > features that make this more difficult. For example, only allowing > connections from a subset of IPs known to have valid users. > > 11.1.6 Covert Channels > > The protocol was not designed to eliminate covert channels. For > example, the padding, SSH_MSG_IGNORE messages, and several other > places in the protocol can be used to pass covert information, and > the recipient has no reliable way to verify whether such information > is being sent. > > 11.2 Authentication Protocol > > The purpose of this protocol is to perform client user > authentication. It assumed that this runs over a secure transport > layer protocol, which has already authenticated the server machine, > established an encrypted communications channel, and computed a > unique session identifier for this session. The transport layer > provides forward secrecy for password authentication and other > methods that rely on secret data. "perfect forward secrecy" or "forward secrecy" ? > The server may go into a "sleep" period after repeated unsuccessful > authentications to make key search harder. > > Several authentication methods with different security > characteristics are allowed. It is up to the server's local policy > to decide which methods (or combinations of methods) it is willing > to > accept for each user. Authentication is no stronger than the > weakest > combination allowed. > > 11.2.1 Weak Transport > > If the transport layer does not provide encryption, authentication s/encryption/confidentiality/ > methods that rely on secret data SHOULD be disabled. If it does not > provide MAC protection, requests to change authentication data (e.g. > password change) SHOULD be disabled to avoid an attacker from > modifying the ciphertext without being noticed, rendering the new > authentication data unusable (denial of service). > > 11.2.2 Debug messages > > Special care should be taken when designing debug messages. These > messages may reveal surprising amounts of information about the host > if not properly designed. Debug messages can be disabled (during > user authentication phase) if high security is required. > > 11.2.3 Local security policy > > Authentication is always a delicate security operation. > Implementor MUST not only ensure that the credentials > given validate the professed user, but also that the > local policy of the server hosts allows the user the > access requested. Propose edit of paragraph above to: Implementer MUST ensure that the credentials provided validate the professed user and also MUST ensure that the local policy of the server permits the user the access requested. > In particular, because of the flexible nature of the > SSH connection protocol, it may not be possible to determine > this completely at the time of authentication, because > the kind of service being requested is not yet clear. Unclear antecedent "this". > For example, local policy might allow a user to access > files on the server, but not start an interactive shell. > However, during the authentication protocol, it is not > known whether the user will be accessing files or > attempting to use an interactive shell, or even both. > > In any event, local security policy for the server > host MUST be applied and enforced correctly. > > 11.2.4 Public key authentication > > The use of public-key authentication assumes that the > client host has not been compromised. > > This risk can be mitigated by the use of passphrases > on private keys; however, this is not an enforcable > policy. The use of smartcards, or other technology > to make passphrases an enforcable policy is suggested. > > The server could require both password and public-key > authentication, however, this requires the client > to expose its password to the server (see section on > password authentication below.) > > 11.2.5 Password authentication > > The password mechanism of specified in the authentication > protocol assumes that the server has not been compromised. > If the server has been compromised, using password > authentication will reveal a valid username / password > combination to the attacker, which may lead to further > comprimises. > > This vulnerability can be mitigated by using an alternative > form of authentication. For example, public-key authentication > makes no assumptions about security on the server. > > 11.2.6 Host based authentication > > Host based authentication assumes that the client > has not been compromised. There are no mitaging s/mitaging/mitigating > strategies, other than to use host based authentication > in combination with another authentication method. > > 11.3 Connection protocol > > 11.3.1 End point security > > End point security is assumed by the connection protocol. > If the server has been compromised, any terminal sessions, > port forwarding, or systems accessed on the host are comprimised. > There are no mitigating factors for this. > > If the client end point has been compromised, and the server > fails to stop the attacker at the authentication protocol, > all services exposed (either as subsystems or through forwarding) > will be vulnerable to attack. Implementors SHOULD provide > mechanisms for administrators to control which services > are exposed to limit the vulnerability of other services. > > These controls might include controlling which machines and > ports can be target in 'port-forwarding' operations, which > users are allowed to use interactive shell facilities, or > which users are allowed to use exposed subsystems. > > 11.3.2 Proxy forwarding > > The ssh connection protocol allows proxy forwarding > of other protocols. The proxy forwarding functionality > can be used to circumvent firewall protections. Implementors > SHOULD provide a mechanism to disable to administratively > control the proxy forwarding funcitonality. > > In addition, a reverse proxy forwarding functionality > is available, which again can be used to bypass firewall > controls. > > As indicated above, end-point security is assumed during > proxy forwarding operations. Failure of end-point security > will compromise all data pass over proxy forwarding. > > 11.3.3 X11 forwarding > > Another form of proxy forwarding provided by the ssh > connection protocol is the forwarding of the X11 protocol. > > Implementors of the X11 protocol SHOULD implement the > magic cookie spoofing, to prevent unauthorized use of > the proxy. Add citation for "magic cookie spoofing". > X11 forwarding relies on end-point security. If end-point > security has been compromised, X11 forwarding will allow > any attack against the X11 server possible locally. > > Users and administors should, as a matter of course, use > X11 security mechanism to prevent unauthorized use of > the X11 server. Which "X11 security mechanism" is meant ? Also, please add a citation for that mechanism. ------------------------------------------------------------------------ --- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 31 17:19:08 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28107 for ; Mon, 31 Mar 2003 17:19:07 -0500 (EST) Received: (qmail 19671 invoked by uid 605); 31 Mar 2003 22:21:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19664 invoked from network); 31 Mar 2003 22:21:28 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 31 Mar 2003 22:21:28 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08262; Mon, 31 Mar 2003 14:21:19 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VMLIuK023050; Mon, 31 Mar 2003 17:21:18 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2VMLIaj027209; Mon, 31 Mar 2003 17:21:18 -0500 (EST) Message-Id: <200303312221.h2VMLIaj027209@thunk.east.sun.com> From: Bill Sommerfeld To: RJ Atkinson cc: "Joseph Galbraith" , ietf-ssh@netbsd.org, smb@research.att.com, jis@MIT.EDU Subject: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Mon, 31 Mar 2003 11:10:30 EST." <4B482B07-6393-11D7-A792-00039357A82A@extremenetworks.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 31 Mar 2003 17:21:18 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > > The transport protocol [1] provides a secure encrypted > > channel over an insecure network. It performs server > > s/a secure encrypted channel/a confidential channel/ > > "encryption" is the mechanism. > "confidentiality" is the property. a nit on a nit: It's probably also worth adding something about "integrity-protected" as well here. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 31 17:44:25 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29290 for ; Mon, 31 Mar 2003 17:44:24 -0500 (EST) Received: (qmail 29874 invoked by uid 605); 31 Mar 2003 22:43:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27176 invoked from network); 31 Mar 2003 22:38:08 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 31 Mar 2003 22:38:08 -0000 Received: from ixion.tartarus.org (ixion.tartarus.org [195.149.39.210]) by narn.netbsd.org (Postfix) with ESMTP id 3C56311153 for ; Mon, 31 Mar 2003 14:37:55 -0800 (PST) Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1907pg-00017i-00; Mon, 31 Mar 2003 23:32:48 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <02fb01c2f613$0220a2e0$4d00a8c0@galb.vandyke.com> Subject: Re: Please publish attached draft-ietf-secsh-break-01 Message-Id: Date: Mon, 31 Mar 2003 23:32:48 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joseph Galbraith wrote: > Please publish the attached draft, > draft-ietf-secsh-break-01.txt. This looks good - I've had a few requests for this functionality in PuTTY. Are any server maintainers planning to implement it soon? I'd certainly like to have it in the next PuTTY release, but I'd also quite like the documentation not to have to confess `actually no servers support this so it's a bit useless' :-) Cheers, Simon -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about."