From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 03:50: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 DAA10459 for ; Thu, 3 Apr 2003 03:50:39 -0500 (EST) Received: (qmail 6495 invoked by uid 605); 3 Apr 2003 08:52:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6488 invoked from network); 3 Apr 2003 08:52:43 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 3 Apr 2003 08:52:43 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.3) with ESMTP id h338qbZJ009463; Thu, 3 Apr 2003 00:52:37 -0800 Received: from moma.corp.google.com (localhost [127.0.0.1]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h338qbL9003397; Thu, 3 Apr 2003 00:52:37 -0800 Received: (from frank@localhost) by moma.corp.google.com (8.12.9/8.12.3) id h338qbFR003379; Thu, 3 Apr 2003 00:52:37 -0800 Date: Thu, 3 Apr 2003 00:52:37 -0800 From: Frank Cusack To: Chris Lonvick Cc: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030403005237.A3335@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from clonvick@cisco.com on Mon, Mar 31, 2003 at 08:08:59AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: > 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. I believe the "none" cipher has legitimate uses besides debugging. You may want the authentication mechanisms provided by SSH, but not the data confidentiality. EG: you are copying already encrypted data between machines that have such low CPU power that encryption is a significant overhead. Even if you disagree, *it goes without saying* that you wouldn't use the "none" cipher where integrity/privacy matters. If you /were/ to keep this text, shouldn't 'should' be in caps? RFC 2410 seems too humorous to be referenced in a security considerations section. Maybe I'm just in a bad mood though. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 04:26: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 EAA11197 for ; Thu, 3 Apr 2003 04:26:51 -0500 (EST) Received: (qmail 21765 invoked by uid 605); 3 Apr 2003 09:29:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21758 invoked from network); 3 Apr 2003 09:29:15 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.37.170) by mail.netbsd.org with SMTP; 3 Apr 2003 09:29:15 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id h33944A02120 for ietf-ssh@netbsd.org; Thu, 3 Apr 2003 01:04:04 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: IESG feedback on core drafts. Date: 3 Apr 2003 09:04:04 GMT Organization: University of California, Berkeley Lines: 20 Distribution: isaac Message-ID: References: <20030403005237.A3335@google.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1049360644 2106 128.32.153.211 (3 Apr 2003 09:04:04 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 3 Apr 2003 09:04:04 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Frank Cusack wrote: >On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: >> 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. > >I believe the "none" cipher has legitimate uses besides debugging. You >may want the authentication mechanisms provided by SSH, but not the data >confidentiality. EG: you are copying already encrypted data between >machines that have such low CPU power that encryption is a significant >overhead. Do you really think there is any real-world case where this will come up? Remember, to use SSH you have to be able to do a public-key operation. I'm hard-pressed to imagine any scenario where the public-key operation is feasible but there is no symmetric-key encryption that will be. Allowing people to use the none cipher is asking for trouble. Many people expect the (symmetric-key) crypto to be much more expensive than it really is. The ``SHOULD NOT use "none" cipher'' language seems reasonable. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 05:12: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 FAA12374 for ; Thu, 3 Apr 2003 05:12:00 -0500 (EST) Received: (qmail 13876 invoked by uid 605); 3 Apr 2003 10:14:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13869 invoked from network); 3 Apr 2003 10:14:26 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 3 Apr 2003 10:14:26 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.3) with ESMTP id h33AEKZJ015374; Thu, 3 Apr 2003 02:14:20 -0800 Received: from moma.corp.google.com (localhost [127.0.0.1]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h33AEKL9032503; Thu, 3 Apr 2003 02:14:20 -0800 Received: (from frank@localhost) by moma.corp.google.com (8.12.9/8.12.3) id h33AEK0O032502; Thu, 3 Apr 2003 02:14:20 -0800 Date: Thu, 3 Apr 2003 02:14:20 -0800 From: Frank Cusack To: Chris Lonvick Cc: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030403021420.B3335@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from clonvick@cisco.com on Mon, Mar 31, 2003 at 08:08:59AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Some more comments. BTW, thanks for taking the time to collect and compose this text. On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: > twofish, serpent and blowfish. AES has been accepted by cryptographic > experts as being stronger than most of the other ciphers in use today It has? I don't think DES had that property and I'm not sure (ie, I don't know either way) that AES has that property. eg, one of the considerations for selection was a design that allows for efficient implementation in software (unlike DES). http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.html#sec4 Certainly, AES is strong. Is it stronger than MOST of the other ciphers in use today? What ciphers are in use today? I might just be being too picky. > and it is being implemented in other security protocols as it is within ^^^^^^^^ "as well as", maybe? > 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 cool. > wish to offer relatively weaker ciphers in their products for > interoperability but should strive to depricate them as soon as "deprecate", and why would implementors deprecate, say 3DES which may be weaker than AES? 3DES is required by SSH, AES is not. (Although, I believe that AES *should* be required and the 3DES req. dropped, but that's not the point.) I would just lose this sentence. > 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. "practical" might be better. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 05:42: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 FAA12945 for ; Thu, 3 Apr 2003 05:42:10 -0500 (EST) Received: (qmail 26428 invoked by uid 605); 3 Apr 2003 10:44:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25517 invoked from network); 3 Apr 2003 10:43:15 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 3 Apr 2003 10:43:15 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.3) with ESMTP id h33AhCZJ017001 for ; Thu, 3 Apr 2003 02:43:12 -0800 Received: from moma.corp.google.com (localhost [127.0.0.1]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h33AhBL9010855 for ; Thu, 3 Apr 2003 02:43:11 -0800 Received: (from frank@localhost) by moma.corp.google.com (8.12.9/8.12.3) id h33AhBMF010854 for ietf-ssh@netbsd.org; Thu, 3 Apr 2003 02:43:11 -0800 Date: Thu, 3 Apr 2003 02:43:11 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030403024311.C3335@google.com> References: <20030403005237.A3335@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from daw@mozart.cs.berkeley.edu on Thu, Apr 03, 2003 at 09:04:04AM +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Apr 03, 2003 at 09:04:04AM +0000, David Wagner wrote: > Frank Cusack wrote: > >On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: > >> 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. > > > >I believe the "none" cipher has legitimate uses besides debugging. You > >may want the authentication mechanisms provided by SSH, but not the data > >confidentiality. EG: you are copying already encrypted data between > >machines that have such low CPU power that encryption is a significant > >overhead. > > Do you really think there is any real-world case where this will come up? Sure, I regularly copy terabytes of data around, data that is not encrypted but also not worth protecting. The time cost of encryption is visible to me, partly for billing reasons. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 05:48:45 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 FAA13083 for ; Thu, 3 Apr 2003 05:48:45 -0500 (EST) Received: (qmail 29787 invoked by uid 605); 3 Apr 2003 10:51:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29780 invoked from network); 3 Apr 2003 10:51:11 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 3 Apr 2003 10:51:11 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.3) with ESMTP id h33ApBZJ017456 for ; Thu, 3 Apr 2003 02:51:11 -0800 Received: from moma.corp.google.com (localhost [127.0.0.1]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h33ApBL9013744 for ; Thu, 3 Apr 2003 02:51:11 -0800 Received: (from frank@localhost) by moma.corp.google.com (8.12.9/8.12.3) id h33ApBmO013743 for ietf-ssh@netbsd.org; Thu, 3 Apr 2003 02:51:11 -0800 Date: Thu, 3 Apr 2003 02:51:11 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030403025111.A12407@google.com> References: <20030403005237.A3335@google.com> <20030403024311.C3335@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030403024311.C3335@google.com>; from fcusack@fcusack.com on Thu, Apr 03, 2003 at 02:43:11AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Apr 03, 2003 at 02:43:11AM -0800, Frank Cusack wrote: > On Thu, Apr 03, 2003 at 09:04:04AM +0000, David Wagner wrote: > > > > Do you really think there is any real-world case where this will come up? > > Sure, I regularly copy terabytes of data around, data that is not > encrypted but also not worth protecting. The time cost of encryption > is visible to me, partly for billing reasons. Then again, anyone who is going to use 'none' is going to have really good reasons for it. There's no harm in discouraging it. Part of my argument was that it seems damn obvious that you shouldn't use "none". /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 06:26: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 GAA14104 for ; Thu, 3 Apr 2003 06:26:14 -0500 (EST) Received: (qmail 20582 invoked by uid 605); 3 Apr 2003 11:28:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20517 invoked from network); 3 Apr 2003 11:28:37 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 3 Apr 2003 11:28:37 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h33BSJ3k011722; Thu, 3 Apr 2003 13:28:20 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id E306134081; Thu, 3 Apr 2003 13:28:09 +0200 (CEST) Date: Thu, 3 Apr 2003 13:28:09 +0200 From: Markus Friedl To: Frank Cusack Cc: Chris Lonvick , ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030403112809.GC29044@folly> References: <20030403005237.A3335@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030403005237.A3335@google.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Apr 03, 2003 at 12:52:37AM -0800, Frank Cusack wrote: > On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: > > 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. > > I believe the "none" cipher has legitimate uses besides debugging. You > may want the authentication mechanisms provided by SSH, but not the data > confidentiality. in this case you can use arcfour, i think. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 06:37:02 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 GAA14633 for ; Thu, 3 Apr 2003 06:37:01 -0500 (EST) Received: (qmail 25285 invoked by uid 605); 3 Apr 2003 11:39:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25272 invoked from network); 3 Apr 2003 11:39:25 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Apr 2003 11:39:25 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14616; Thu, 3 Apr 2003 06:36:56 -0500 (EST) Message-Id: <200304031136.GAA14616@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-04.txt Date: Thu, 03 Apr 2003 06:36:56 -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-04.txt Pages : 11 Date : 2003-4-2 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-dns-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-dns-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-2123654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dns-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dns-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-2123654.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 08:52:02 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 IAA19853 for ; Thu, 3 Apr 2003 08:52:01 -0500 (EST) Received: (qmail 8414 invoked by uid 605); 3 Apr 2003 13:54:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8407 invoked from network); 3 Apr 2003 13:54:10 -0000 Received: from fw.hel.fi.ssh.com (195.20.116.97) by mail.netbsd.org with SMTP; 3 Apr 2003 13:54:10 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.13) with SMTP id h33Ds9u7000881 for ; Thu, 3 Apr 2003 16:54:09 +0300 (EEST) Received: (qmail 17947 invoked from network); 3 Apr 2003 13:54:09 -0000 Received: from unknown (HELO tero.kivinen.iki.fi) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2003 13:54:09 -0000 Received: (from kivinen@localhost) by tero.kivinen.iki.fi (8.11.6/8.11.0) id h33Dmtu04803; Thu, 3 Apr 2003 16:48:55 +0300 (EEST) X-Authentication-Warning: tero.kivinen.iki.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.15291.323047.7500@tero.kivinen.iki.fi> Date: Thu, 3 Apr 2003 16:48:43 +0300 From: Tero Kivinen To: ietf-ssh@netbsd.org CC: clonvick@cisco.com (Chris Lonvick) Subject: Re: IESG feedback on core drafts. References: X-Mailer: VM 7.04 under Emacs 20.7.1 X-Edit-Time: 13 min X-Total-Time: 16 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > > 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? To the attack to work, the attacker needs to know the IV of the next block that is going to be encrypted. In CBC that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e it is in the internal buffers of the ssh implementation or even in the kernel) then he cannot use this attack. If the last packet has been sent out to the network (i.e attacker will know it) then he can use the attack. In optimal case we would need to add extra packet only if the packet has been sent out to network, and there is no other packets waiting in any buffers. Unfortunately it is not normally easy to see if there are unsent packets in the kernel, thus for example ssh's secsh checks if there is any data in its own buffers, and if not then it will add extra packet. If we add new packet to stream every time the attacker knows the IV that is supposed to be used for next packet, we will always cause the attacker to guess wrong IV, thus his attack will never be successfull. > 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. It is not to obfuscate the relative positions, it is to change the IV known by the attacker to something else, i.e something that is not known by the attacker. The contents of the packet actually does not matter, as long as attacker cannot affect its contents. As far as I can understand the attack (and remember about it, this was more than year ago when I last time checked this attack) this should make the attack impossible. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 09:53: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 JAA21894 for ; Thu, 3 Apr 2003 09:53:30 -0500 (EST) Received: (qmail 10869 invoked by uid 605); 3 Apr 2003 14:55:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10862 invoked from network); 3 Apr 2003 14:55:54 -0000 Received: from romeo.rtfm.com (198.144.203.242) by mail.netbsd.org with SMTP; 3 Apr 2003 14:55:54 -0000 Received: by romeo.rtfm.com (Postfix, from userid 556) id CFC75AB86; Thu, 3 Apr 2003 07:01:25 -0800 (PST) To: Tero Kivinen Cc: ietf-ssh@netbsd.org, clonvick@cisco.com (Chris Lonvick) Subject: Re: IESG feedback on core drafts. References: <16012.15291.323047.7500@tero.kivinen.iki.fi> Reply-To: EKR From: Eric Rescorla Date: 03 Apr 2003 07:01:25 -0800 In-Reply-To: <16012.15291.323047.7500@tero.kivinen.iki.fi> Message-ID: Lines: 78 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 Tero Kivinen writes: > > > > 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? > > To the attack to work, the attacker needs to know the IV of the next > block that is going to be encrypted. In CBC that is the output of the > encryption of the previous block. If the attacker does not have any > way to see the packet yet (i.e it is in the internal buffers of the > ssh implementation or even in the kernel) then he cannot use this > attack. If the last packet has been sent out to the network (i.e > attacker will know it) then he can use the attack. > > In optimal case we would need to add extra packet only if the packet > has been sent out to network, and there is no other packets waiting in > any buffers. Unfortunately it is not normally easy to see if there are > unsent packets in the kernel, thus for example ssh's secsh checks if > there is any data in its own buffers, and if not then it will add > extra packet. Yes, I'm familiar with the Rogaway attack, but it's a mistake to get fixated on TCP mapping. For instance, Consider the following case: Client Server ------ ------ TCP(seq=x, len=500) -> contains Record 1 [500 ms passes, no ACK] TCP(seq=x, len=1000) -> contains Records 1,2 <- ACK (1) The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment (2) Record 2 is *not* at the beginning of the TCP segment and never will be, since it gets ACKed. (3) Yet, the attack is possible because Record 1 has already been seen. As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. On the other hand, it's perfectly safe to have the following situation: Client Server ------ ------ TCP(seq=x, len=500) -> contains SSH_MSG_IGNORE TCP(seq=y, len=500) -> contains Data Provided that the IV for second SSH Record is fixed after the data for the Data packet is determined. I.e. you do: read from user encrypt null packet encrypt data packet The point is that you can't safely talk about TCP packets. If you want to talk about conditional empty packet insertion you should talk about the data being "written" "delivered to the network" -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 12:36: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 MAA03064 for ; Thu, 3 Apr 2003 12:36:48 -0500 (EST) Received: (qmail 13552 invoked by uid 605); 3 Apr 2003 17:37:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13294 invoked from network); 3 Apr 2003 17:37:38 -0000 Received: from firebird.cisco.com (HELO fire.cisco.com) (171.68.227.73) by mail.netbsd.org with SMTP; 3 Apr 2003 17:37:37 -0000 Received: from REMAKERW2K (remaker-w2k.cisco.com [171.69.103.87]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h33HbWr02012; Thu, 3 Apr 2003 09:37:32 -0800 (PST) Message-ID: <009601c2fa07$b4baeee0$576745ab@amer.cisco.com> From: "Phillip Remaker" To: "Simon Tatham" , References: Subject: Re: Please publish attached draft-ietf-secsh-break-01 Date: Thu, 3 Apr 2003 09:37:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > 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' :-) I am pushing to get it in Cisco, and I am trying to also get it on Cyclades's roadmap. Do you have any other vendors that we should hassle? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 14:41: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 OAA08708 for ; Thu, 3 Apr 2003 14:41:47 -0500 (EST) Received: (qmail 28786 invoked by uid 605); 3 Apr 2003 19:44:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28778 invoked from network); 3 Apr 2003 19:44:10 -0000 Received: from ip212-226-138-153.adsl.kpnqwest.fi (HELO mail.kivinen.iki.fi) (212.226.138.153) by mail.netbsd.org with SMTP; 3 Apr 2003 19:44:10 -0000 Received: (from kivinen@localhost) by mail.kivinen.iki.fi (8.11.6p2/8.12.6) id h33Jhrd01529; Thu, 3 Apr 2003 22:43:53 +0300 (EEST) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.36601.636048.47626@fireball.acr.fi> Date: Thu, 3 Apr 2003 22:43:53 +0300 From: Tero Kivinen To: EKR Cc: ietf-ssh@netbsd.org, clonvick@cisco.com (Chris Lonvick) Subject: Re: IESG feedback on core drafts. In-Reply-To: References: <16012.15291.323047.7500@tero.kivinen.iki.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 5 min Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Eric Rescorla writes: > > In optimal case we would need to add extra packet only if the packet > > has been sent out to network, and there is no other packets waiting in > > any buffers. Unfortunately it is not normally easy to see if there are > > unsent packets in the kernel, thus for example ssh's secsh checks if > > there is any data in its own buffers, and if not then it will add > > extra packet. > Yes, I'm familiar with the Rogaway attack, but it's a mistake to > get fixated on TCP mapping. ... > (3) Yet, the attack is possible because Record 1 has already > been seen. Yes, as I say above the important thing is if it has been ever sent out to network. > As this example indicates, it's totally unsafe to use the existence > of unflushed data in the TCP buffers proper as a guide to whether > you need an empty packet, since when you do the second write(), > the buffers will contain the un-ACKed Record 1. It is safe, if and only if you get the information from the TCP stack if that data at the end of the TCP buffers have ever been sent out to network. If it has never ever been sent out to network, then we do not need the extra packet, if it has already been sent out, then you do need extra packet. > The point is that you can't safely talk about TCP packets. If you want > to talk about conditional empty packet insertion you should talk about > the data being "written" "delivered to the network" I think I have been using term "seen on the network" all the time, I didn't talk about TCP packet. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 16:38:47 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 QAA15508 for ; Thu, 3 Apr 2003 16:38:46 -0500 (EST) Received: (qmail 7159 invoked by uid 605); 3 Apr 2003 21:41:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7143 invoked from network); 3 Apr 2003 21:40:58 -0000 Received: from romeo.rtfm.com (198.144.203.242) by mail.netbsd.org with SMTP; 3 Apr 2003 21:40:58 -0000 Received: by romeo.rtfm.com (Postfix, from userid 556) id ED590AB85; Thu, 3 Apr 2003 13:46:29 -0800 (PST) To: Tero Kivinen Cc: ietf-ssh@netbsd.org, clonvick@cisco.com (Chris Lonvick) Subject: Re: IESG feedback on core drafts. References: <16012.15291.323047.7500@tero.kivinen.iki.fi> <16012.36601.636048.47626@fireball.acr.fi> Reply-To: EKR From: Eric Rescorla Date: 03 Apr 2003 13:46:29 -0800 In-Reply-To: <16012.36601.636048.47626@fireball.acr.fi> Message-ID: Lines: 29 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 Tero Kivinen writes: > Eric Rescorla writes: > > As this example indicates, it's totally unsafe to use the existence > > of unflushed data in the TCP buffers proper as a guide to whether > > you need an empty packet, since when you do the second write(), > > the buffers will contain the un-ACKed Record 1. > > It is safe, if and only if you get the information from the TCP stack > if that data at the end of the TCP buffers have ever been sent out to > network. If it has never ever been sent out to network, then we do not > need the extra packet, if it has already been sent out, then you do > need extra packet. Yes, but since essentially no stack will tell you this, it's not really an optimization worth making. > > The point is that you can't safely talk about TCP packets. If you want > > to talk about conditional empty packet insertion you should talk about > > the data being "written" "delivered to the network" > > I think I have been using term "seen on the network" all the time, I > didn't talk about TCP packet. But that's the language that appeared in the text I was criticizing. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 3 17:35: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 RAA17515 for ; Thu, 3 Apr 2003 17:35:26 -0500 (EST) Received: (qmail 14035 invoked by uid 605); 3 Apr 2003 22:37:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13964 invoked from network); 3 Apr 2003 22:37:51 -0000 Received: from edison.cisco.com (171.70.144.164) by mail.netbsd.org with SMTP; 3 Apr 2003 22:37:51 -0000 Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA22499 for ; Thu, 3 Apr 2003 14:37:51 -0800 (PST) Date: Thu, 3 Apr 2003 14:37:51 -0800 (PST) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Newer Rev of Section 11 - was: 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, I've tried to revise Section 11 per all of the comments and came up with the following. There are some questions asked by Ran that still need to be addressed which are noted. I've corrected some typo's and will gladly pass this back to Joseph. :-) Thanks, Chris ======= 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 confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [2] provides a suite of mechanism which can be used to authenticating the client user to the server. Individual mechanisms specified in the in authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol. The connection protocol [3] specifies a mechanism to multiplex multiple streams [channels] of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 11.1 Transport 11.1.1 Confidentiality It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry. At the time of this writing, ciphers commonly in use include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has been accepted by The US Federal Information Processing Standards [FIPS-197] and the cryptographic community as being acceptable for this purpose as well. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410, which will show that its use does not meet the intent of this protocol. [Chris: While it may be obvious to everyone on this list that "none" [Chris: should not be used, it may not be obvious to all readers. I'd [Chris: like to keep this in for completeness. 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. Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack) to work, the attacker would need to know the IV of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e it is in the internal buffers of the ssh implementation or even in the kernel) then this attack will not work. If the last packet has been sent out to the network (i.e the attacker has access to it) then he can use the attack. In the optimal case an implementor would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementors may wish to check to see if there are any unsent packets awaiting transmission, but unfortunately it is not normally easy to obtain this information from the kernel or buffers. If there are not, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successfull. As an example, consider the following case: Client Server ------ ------ TCP(seq=x, len=500) -> contains Record 1 [500 ms passes, no ACK] TCP(seq=x, len=1000) -> contains Records 1,2 <- ACK (1) The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment (2) Record 2 is *not* at the beginning of the TCP segment and never will be, since it gets ACKed. (3) Yet, the attack is possible because Record 1 has already been seen. As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. On the other hand, it's perfectly safe to have the following situation: Client Server ------ ------ TCP(seq=x, len=500) -> contains SSH_MSG_IGNORE TCP(seq=y, len=500) -> contains Data Provided that the IV for second SSH Record is fixed after the data for the Data packet is determined -i.e. you do: read from user encrypt null packet encrypt data packet 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 might start to leak information after 2**32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [1] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2**28 packets at the very most. 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. [RJA: Is it random or pseudo-random ? [RJA: 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. [RJA: Citations would be pleasant for these claims. 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. [RJA: Narrow *which* window ? [RJA: 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. [RJA: 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 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 [RJA: 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. [RJA: ??? 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. [RJA: "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 confidentiality, 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 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. [RJA: 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 enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested. The server could require both password and public-key authentication, however, this requires the client to expose its password to the server (see section on password authentication below.) 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 compromises. 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 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 compromised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 11.3.2 Proxy forwarding The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls. As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data passed 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. [RJA: 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 administrators should, as a matter of course, use X11 security mechanism to prevent unauthorized use of the X11 server. [RJA: Which "X11 security mechanism" is meant ? [RJA: Also, please add a citation for that mechanism. References: [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 ===end=== From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 4 01:48: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 BAA27665 for ; Fri, 4 Apr 2003 01:48:15 -0500 (EST) Received: (qmail 2188 invoked by uid 605); 4 Apr 2003 06:50:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2158 invoked from network); 4 Apr 2003 06:50:31 -0000 Received: from elanus.its.uu.se (130.238.4.143) by mail.netbsd.org with SMTP; 4 Apr 2003 06:50:31 -0000 Received: from elanus (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7DF76489E; Fri, 4 Apr 2003 08:50:30 +0200 (DFT) Received: from elanus.its.uu.se(127.0.0.1) by elanus.its.uu.se via virus-scan id s20498; Fri, 4 Apr 03 08:50:22 +0200 Received: from r3.ekonomikum.uu.se (r3.ekonomikum.uu.se [130.238.166.240]) by elanus.its.uu.se (Postfix) with ESMTP id 44FA6489E; Fri, 4 Apr 2003 08:50:21 +0200 (DFT) Received: (from pont@localhost) by r3.ekonomikum.uu.se (8.10.2+Sun/8.10.2) id h346oKu27180; Fri, 4 Apr 2003 08:50:20 +0200 (MEST) X-Authentication-Warning: r3.ekonomikum.uu.se: pont set sender to pont@soua.net using -f From: Pontus Skoeld To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: Date: 04 Apr 2003 08:50:20 +0200 In-Reply-To: Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA27665 Simon Tatham writes: > > 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' :-) FWIW, I've just implemented (although not yet properly tested) it in lshd. /Pontus -- Pontus Sköld, see for more information. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 4 16:29:09 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 QAA08720 for ; Fri, 4 Apr 2003 16:29:08 -0500 (EST) Received: (qmail 6122 invoked by uid 605); 4 Apr 2003 21:31:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6115 invoked from network); 4 Apr 2003 21:31:30 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 4 Apr 2003 21:31:30 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA05314; Fri, 4 Apr 2003 13:31:30 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h34LVT5i013523; Fri, 4 Apr 2003 14:31:30 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h34LTHQx016394; Fri, 4 Apr 2003 13:29:17 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h34LTGmG016393; Fri, 4 Apr 2003 13:29:16 -0800 (PST) Date: Fri, 4 Apr 2003 13:29:16 -0800 From: Nicolas Williams To: Frank Cusack Cc: Chris Lonvick , ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030404132916.A16389@binky.central.sun.com> References: <20030403005237.A3335@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030403005237.A3335@google.com>; from fcusack@fcusack.com on Thu, Apr 03, 2003 at 12:52:37AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Another legit use of "none" would be with GSS keyex and a channel bindings that cryptographically bind the GSS context to some underlying secure channel (e.g., IPsec). Don't laugh. Exactly this sort of thing is being discussed on the NFSv4 list. The current approach is to define a new, trivial GSS pseudo-mechanism for the purpose of negotiating channel bindings - if you use this mechanism then channel bindings[*] must be used[**]. So, SSHv2 w/ GSS key exchange + this new GSS pseudo-mechanism + channel bindings to IPsec + SSH "none" crypto alg == SSH w/ crypto at IPsec layer only. This is much more useful in the context of NFSv4 than in the context of SSHv2, but it sure seems applicable to SSHv2. Cheers, Nico [*] GSS-API supports two kinds of channel bindings: network address, which are useless in this context, and "transformations of encryption keys" [rfc2743]. [**] GSS channel bindings are opitonal and generally not used, therefore a way to force their use is needed and by making it a pseudo-mechanism any protocols that can negotiate GSS mechanisms can negotiate the use of this pseudo-mech and so the use of channel bindings. On Thu, Apr 03, 2003 at 12:52:37AM -0800, Frank Cusack wrote: > On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: > > 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. > > I believe the "none" cipher has legitimate uses besides debugging. You > may want the authentication mechanisms provided by SSH, but not the data > confidentiality. EG: you are copying already encrypted data between > machines that have such low CPU power that encryption is a significant > overhead. Even if you disagree, *it goes without saying* that you > wouldn't use the "none" cipher where integrity/privacy matters. > > If you /were/ to keep this text, shouldn't 'should' be in caps? > > RFC 2410 seems too humorous to be referenced in a security considerations > section. Maybe I'm just in a bad mood though. > > /fc > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 4 16:38: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 QAA09052 for ; Fri, 4 Apr 2003 16:38:20 -0500 (EST) Received: (qmail 14271 invoked by uid 605); 4 Apr 2003 21:40:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14264 invoked from network); 4 Apr 2003 21:40:43 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 4 Apr 2003 21:40:43 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA16265; Fri, 4 Apr 2003 14:40:42 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h34Leg1q014033; Fri, 4 Apr 2003 14:40:42 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h34LcUQx016405; Fri, 4 Apr 2003 13:38:30 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h34LcTh5016404; Fri, 4 Apr 2003 15:38:29 -0600 (CST) Date: Fri, 4 Apr 2003 15:38:29 -0600 From: Nicolas Williams To: Frank Cusack Cc: Chris Lonvick , ietf-ssh@netbsd.org Subject: Re: IESG feedback on core drafts. Message-ID: <20030404153829.V12954@binky.central.sun.com> References: <20030403005237.A3335@google.com> <20030404132916.A16389@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030404132916.A16389@binky.central.sun.com>; from Nicolas.Williams@sun.com on Fri, Apr 04, 2003 at 01:29:16PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Note: this was merely an attempt to illustrate a possible future use of the SSHv2 "none" crypto alg. Perhaps there should be text explicitly allowing the use of "none" when the key exchange and/or userauth cryptographically binds authentication at the SSHv2 layer to integrity/confidentiality services at a lower layer: " The "none" encryption algorithm MAY be used where authentication at the SSHv2 layer is cryptographically bound to the cryptographic integrity and/or confidentiality services provided by a lower layer, such as IPsec. Other uses of the "none" encryption algorithm are NOT RECOMMENDED. " For more details on this proposed GSS pseudo-mechanism look at the NFSv4 WG list archives. And note that it's a trivial wrapper around an underlying non-pseudo mechanism (almost like an OID prefix, if you wish). Cheers, Nico On Fri, Apr 04, 2003 at 01:29:16PM -0800, Nicolas Williams wrote: > Another legit use of "none" would be with GSS keyex and a channel > bindings that cryptographically bind the GSS context to some underlying > secure channel (e.g., IPsec). > > Don't laugh. Exactly this sort of thing is being discussed on the NFSv4 > list. The current approach is to define a new, trivial GSS > pseudo-mechanism for the purpose of negotiating channel bindings - if you > use this mechanism then channel bindings[*] must be used[**]. > > So, SSHv2 w/ GSS key exchange + this new GSS pseudo-mechanism + channel > bindings to IPsec + SSH "none" crypto alg == SSH w/ crypto at IPsec > layer only. > > This is much more useful in the context of NFSv4 than in the context of > SSHv2, but it sure seems applicable to SSHv2. > > Cheers, > > Nico > > [*] GSS-API supports two kinds of channel bindings: network address, > which are useless in this context, and "transformations of > encryption keys" [rfc2743]. > > [**] GSS channel bindings are opitonal and generally not used, therefore > a way to force their use is needed and by making it a > pseudo-mechanism any protocols that can negotiate GSS mechanisms > can negotiate the use of this pseudo-mech and so the use of channel > bindings. > > > On Thu, Apr 03, 2003 at 12:52:37AM -0800, Frank Cusack wrote: > > On Mon, Mar 31, 2003 at 08:08:59AM -0800, Chris Lonvick wrote: > > > 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. > > > > I believe the "none" cipher has legitimate uses besides debugging. You > > may want the authentication mechanisms provided by SSH, but not the data > > confidentiality. EG: you are copying already encrypted data between > > machines that have such low CPU power that encryption is a significant > > overhead. Even if you disagree, *it goes without saying* that you > > wouldn't use the "none" cipher where integrity/privacy matters. > > > > If you /were/ to keep this text, shouldn't 'should' be in caps? > > > > RFC 2410 seems too humorous to be referenced in a security considerations > > section. Maybe I'm just in a bad mood though. > > > > /fc > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 7 20:48: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 UAA12522 for ; Mon, 7 Apr 2003 20:48:07 -0400 (EDT) Received: (qmail 11194 invoked by uid 605); 8 Apr 2003 00:50:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11187 invoked from network); 8 Apr 2003 00:50:09 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 8 Apr 2003 00:50:09 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA24348; Mon, 7 Apr 2003 18:50:05 -0600 (MDT) 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 h380o4uK012239; Mon, 7 Apr 2003 20:50:04 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h380o4aj017885; Mon, 7 Apr 2003 20:50:04 -0400 (EDT) Message-Id: <200304080050.h380o4aj017885@thunk.east.sun.com> From: Bill Sommerfeld To: Chris Lonvick cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. In-Reply-To: Your message of "Thu, 03 Apr 2003 14:37:51 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 07 Apr 2003 20:50:04 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Thanks for your edits. This thread seems to have died down. Are we done yet? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 7 21: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 VAA13105 for ; Mon, 7 Apr 2003 21:17:52 -0400 (EDT) Received: (qmail 25510 invoked by uid 605); 8 Apr 2003 01:20:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25501 invoked from network); 8 Apr 2003 01:20:20 -0000 Received: from mm02snlnto.sandia.gov (HELO mm02snlnto.son.sandia.gov) (132.175.109.21) by mail.netbsd.org with SMTP; 8 Apr 2003 01:20:20 -0000 Received: from 132.175.109.4 by mm02snlnto.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.0)); Mon, 07 Apr 2003 19:20:13 -0600 Received: from ES01SNLNT.sandia.gov (es01snlnt.sandia.gov [134.253.130.4]) by mailgate2.sandia.gov (8.12.9/8.12.9) with ESMTP id h381KBln025738 for ; Mon, 7 Apr 2003 19:20:11 -0600 (MDT) Received: by es01snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Mon, 7 Apr 2003 19:20:12 -0600 Message-ID: From: "Wachdorf, Daniel R" To: "'ietf-ssh@netbsd.org'" Subject: SSH_MSG_USERAUTH_GSSAPI_ERRTOK Date: Mon, 7 Apr 2003 19:20:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 128CFC47619788-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit In reading the draft draft-ietf-secsh-gsskeyex-06 it seems that the byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK is undefined as an integer. It is not defined in section 6 (at least in the draft version available on the IETF website). Am I missing something or is this a known problem. Does anyone know what the correct integer definition of SSH_MSG_USERAUTH_GSSAPI_ERRTOK is. Thank you for the help. Daniel Wachdorf Sandia National Labs System Security Research and Integration From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 8 07:10: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 HAA06465 for ; Tue, 8 Apr 2003 07:10:22 -0400 (EDT) Received: (qmail 27011 invoked by uid 605); 8 Apr 2003 11:12:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27004 invoked from network); 8 Apr 2003 11:12:50 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 8 Apr 2003 11:12:50 -0000 Received: from extremenetworks.com (unknown [10.0.8.77]) by gnat.inet.org (Postfix) with ESMTP id C3A8F67105; Tue, 8 Apr 2003 07:33:12 -0400 (EDT) Date: Tue, 8 Apr 2003 07:12:04 -0400 Subject: Re: Newer Rev of Section 11 - was: 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: sommerfeld@east.sun.com From: RJ Atkinson In-Reply-To: <200304080050.h380o4aj017885@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 Monday, Apr 7, 2003, at 20:50 America/Montreal, Bill Sommerfeld wrote: > Thanks for your edits. > > This thread seems to have died down. Are we done yet? No. Chris's text ignored a bunch of my questions/inputs. I'd really like to see those addressed. In some cases, it is a matter of editing the text to be more clear/precise. In other cases, it might be a matter of either deleting a poorly justified claim or justifying the claim more clearly (ideally via a citation to some paper in the published literature that supports the claim). I'm open to hearing about some other proposed resolution of those items, if such exists. The open issues need to be resolved in some deliberate manner, IMHO. Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 8 09:20: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 JAA09347 for ; Tue, 8 Apr 2003 09:20:42 -0400 (EDT) Received: (qmail 9013 invoked by uid 605); 8 Apr 2003 13:23:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9006 invoked from network); 8 Apr 2003 13:23:10 -0000 Received: from edison.cisco.com (171.70.144.164) by mail.netbsd.org with SMTP; 8 Apr 2003 13:23:10 -0000 Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA26653 for ; Tue, 8 Apr 2003 06:23:09 -0700 (PDT) Date: Tue, 8 Apr 2003 06:23:09 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: 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, On Tue, 8 Apr 2003, RJ Atkinson wrote: > > On Monday, Apr 7, 2003, at 20:50 America/Montreal, Bill Sommerfeld > wrote: > > Thanks for your edits. > > > > This thread seems to have died down. Are we done yet? > > No. Agreed. > > Chris's text ignored a bunch of my questions/inputs. I'd > really like to see those addressed. Ran's questions and comments are appropriate and do need to be addressed. I didn't make an attempt as the plane was landing, but instead incorported his comments into the revision before sending it out. > > In some cases, it is a matter of editing the text to be more > clear/precise. In other cases, it might be a matter of either deleting > a poorly justified claim or justifying the claim more clearly (ideally > via a citation to some paper in the published literature that supports > the claim). I'm open to hearing about some other proposed resolution > of those items, if such exists. > > The open issues need to be resolved in some deliberate manner, > IMHO. For the convenience of everyone who's now fired-up to complete this, I'm attaching the revision of Section 11 that I sent out a few days ago. Ran's comments may be found by looking for "[RJA :" at the start of lines. Thanks, Chris ======= 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 confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [2] provides a suite of mechanism which can be used to authenticating the client user to the server. Individual mechanisms specified in the in authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol. The connection protocol [3] specifies a mechanism to multiplex multiple streams [channels] of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 11.1 Transport 11.1.1 Confidentiality It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry. At the time of this writing, ciphers commonly in use include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has been accepted by The US Federal Information Processing Standards [FIPS-197] and the cryptographic community as being acceptable for this purpose as well. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410, which will show that its use does not meet the intent of this protocol. The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack is still deemed difficult and not considered fully practicable especially if relatively longer block sizes are used. Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack) to work, the attacker would need to know the IV of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e it is in the internal buffers of the ssh implementation or even in the kernel) then this attack will not work. If the last packet has been sent out to the network (i.e the attacker has access to it) then he can use the attack. In the optimal case an implementor would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementors may wish to check to see if there are any unsent packets awaiting transmission, but unfortunately it is not normally easy to obtain this information from the kernel or buffers. If there are not, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successfull. As an example, consider the following case: Client Server ------ ------ TCP(seq=x, len=500) -> contains Record 1 [500 ms passes, no ACK] TCP(seq=x, len=1000) -> contains Records 1,2 <- ACK (1) The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment (2) Record 2 is *not* at the beginning of the TCP segment and never will be, since it gets ACKed. (3) Yet, the attack is possible because Record 1 has already been seen. As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. On the other hand, it's perfectly safe to have the following situation: Client Server ------ ------ TCP(seq=x, len=500) -> contains SSH_MSG_IGNORE TCP(seq=y, len=500) -> contains Data Provided that the IV for second SSH Record is fixed after the data for the Data packet is determined -i.e. you do: read from user encrypt null packet encrypt data packet 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 might start to leak information after 2**32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [1] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2**28 packets at the very most. 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. [RJA: Is it random or pseudo-random ? [RJA: 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. [RJA: Citations would be pleasant for these claims. 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. [RJA: Narrow *which* window ? [RJA: 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. [RJA: 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 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 [RJA: 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. [RJA: ??? 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. [RJA: "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 confidentiality, 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 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. [RJA: 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 enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested. The server could require both password and public-key authentication, however, this requires the client to expose its password to the server (see section on password authentication below.) 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 compromises. 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 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 compromised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 11.3.2 Proxy forwarding The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls. As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data passed 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. [RJA: 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 administrators should, as a matter of course, use X11 security mechanism to prevent unauthorized use of the X11 server. [RJA: Which "X11 security mechanism" is meant ? [RJA: Also, please add a citation for that mechanism. References: [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 ===end=== From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 8 09:50: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 JAA10019 for ; Tue, 8 Apr 2003 09:50:41 -0400 (EDT) Received: (qmail 28168 invoked by uid 605); 8 Apr 2003 13:49:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28145 invoked from network); 8 Apr 2003 13:49:02 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 8 Apr 2003 13:49:02 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id DD2B267103; Tue, 8 Apr 2003 10:10:06 -0400 (EDT) Date: Tue, 8 Apr 2003 09:49:00 -0400 Subject: Re: Newer Rev of Section 11 - was: 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: Chris Lonvick 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 Tuesday, Apr 8, 2003, at 09:23 America/Montreal, Chris Lonvick wrote: > I didn't make an attempt as the plane was landing, but instead > incorported > his comments into the revision before sending it out. What was entirely reasonable, IMHO, as it resolved a bunch of the issues and let everyone review the update... Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 9 07:18: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 HAA21775 for ; Wed, 9 Apr 2003 07:18:43 -0400 (EDT) Received: (qmail 12101 invoked by uid 605); 9 Apr 2003 11:21:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12094 invoked from network); 9 Apr 2003 11:21:11 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 9 Apr 2003 11:21:11 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21742; Wed, 9 Apr 2003 07:18:35 -0400 (EDT) Message-Id: <200304091118.HAA21742@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-break-00.txt Date: Wed, 09 Apr 2003 07:18:35 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Session Channel Break Extension Author(s) : J. Galbraith, P. Remaker Filename : draft-ietf-secsh-break-00.txt Pages : 7 Date : 2003-4-8 The Break Extension provides a way to send a break signal during a SSH terminal session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-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-break-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-break-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-4-8141942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-break-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-break-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8141942.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 9 19:18: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 TAA19908 for ; Wed, 9 Apr 2003 19:18:29 -0400 (EDT) Received: (qmail 4739 invoked by uid 605); 9 Apr 2003 23:21:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4729 invoked from network); 9 Apr 2003 23:20:59 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 9 Apr 2003 23:20:59 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA08652 for ; Wed, 9 Apr 2003 16:20:58 -0700 (PDT) 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 h39NKwtY009596 for ; Wed, 9 Apr 2003 19:20:58 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h39NKwaj018310 for ; Wed, 9 Apr 2003 19:20:58 -0400 (EDT) Message-Id: <200304092320.h39NKwaj018310@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG Chair nits for draft-ietf-secsh-break-00.txt Reply-to: sommerfeld@east.sun.com Date: Wed, 09 Apr 2003 19:20:57 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, I'd like to do a last-call on this but there are the following nits which will require a re-spin to resolve: 1) security considerations section is missing. s-c fodder: Because "break" is typically used to enter low-level administrative or debugging functions, implementors of this extension SHOULD provide a mechanism to control whether this extension is accepted, and administrators should use care when deciding whether to enable this feature. 2) typos: > This operation SHOULD be support by most general purpose SSH clients. "supported"? > The telnet protocolprovides a means to send a "BREAK" signal, which missing space --------^ 3) no mention of what to do when the thing on the other end isn't (directly) connected to a traditional serial line. I'm in favor of saying "MAY implement functionally similar implementation-defined behavior". examples: - a ssh-to-telnet gateway could convert into the equivalent telnet option. - a service processor providing remote console access may use some other out-of-band signal to the system it manages rather than the traditional BREAK.. 4) usual normative/informative reference section gorp: these all look normative, so just "s/References/Normative References/" - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 10 13:30: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 NAA27379 for ; Thu, 10 Apr 2003 13:30:27 -0400 (EDT) Received: (qmail 27699 invoked by uid 605); 10 Apr 2003 17:32:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27692 invoked from network); 10 Apr 2003 17:32:52 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 10 Apr 2003 17:32:52 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1444180; Thu, 10 Apr 2003 11:32:48 -0600 Message-ID: <000a01c2ff87$28777360$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: , "RJ Atkinson" , "Chris Lonvick" Cc: References: Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Date: Thu, 10 Apr 2003 11:32:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit (Thanks Chris for gathering edits together. I've tried to respond to Ran's comments below, with revised text where 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. > > [RJA: Is it random or pseudo-random ? > [RJA: Does the difference matter in this case ? It is probably pseudo-random? I'm not sure if it matters. If no one else can say, I'll just change it to pseudo-random. > 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. > > [RJA: Citations would be pleasant for these claims. All right, I think I was just having a major incident of drain bamage. This section should be rewritten: The use of a MAC other than 'none' provides rigorerous protection agains replay attacks at the protocol level. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions. For example, the authentication protocol uses this to prevent replay of signatures from previous sessions. > 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. > > [RJA: Narrow *which* window ? > [RJA: Intended meaning is not crystal clear above. How about this? 1. Narrow the window during which the client is vulnerable to such a man-in-the-middle attack.. If the client ensures that the... > 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. > > [RJA: Is this really true and sufficient ? Hmm... I'm not sure if I missed something here or what? If the man-in-the-middle doesn't have the private key, he can't complete the authentication right? It seems that this is true and sufficient to prevent an attack, but maybe I'm missing something? > Use of this protocol without reliable association > > [RJA: association of what/whom ? How about: Use of this protocol without reliable association of hosts and host keys is inherently insecure, but but may be necessary in non-security critical environments, and still provides protection against passive attacks. However, implementors of applications running on top of this protocol should keep this possibility in mind. > 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. > > [RJA: "perfect forward secrecy" or "forward secrecy" ? I'm not sure; this paragraph is quoted from the previous security considerations section. Would any one else care to comment? > 11.2.3 Local security policy > > Implementer MUST ensure that the credentials provided > validate the professed user and also MUST ensure that > the local policy of the 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. > > [RJA: Unclear antecedent "this". How about: In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine the local security policy that should apply at the time of authentication, because the kind of service being requested is not yet clear. > 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. > > [RJA: Add citation for "magic cookie spoofing". How about: see "SSH Connection Protocol", Section 4.3.1, page 9. > 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 administrators should, as a matter of course, use > X11 security mechanism to prevent unauthorized use of > the X11 server. [RJA: Which "X11 security mechanism" is meant ? [RJA: Also, please add a citation for that mechanism. Well, I didn't have a particular one in mind. The advice is to use any X11 security mechanism. I'd be willing to remove the paragraph. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 10 14:07: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 OAA28847 for ; Thu, 10 Apr 2003 14:07:51 -0400 (EDT) Received: (qmail 20917 invoked by uid 605); 10 Apr 2003 18:10:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20910 invoked from network); 10 Apr 2003 18:10:22 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 10 Apr 2003 18:10:22 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id D26DB67109 for ; Thu, 10 Apr 2003 14:31:28 -0400 (EDT) Date: Thu, 10 Apr 2003 14:09:58 -0400 Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: ietf-ssh@netbsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <000a01c2ff87$28777360$4d00a8c0@galb.vandyke.com> Message-Id: X-Mailer: Apple Mail (2.551) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, Apr 10, 2003, at 13:32 America/Montreal, Joseph Galbraith wrote: >> 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. >> >> [RJA: Is it random or pseudo-random ? >> [RJA: Does the difference matter in this case ? > > It is probably pseudo-random? I'm not sure if > it matters. If no one else can say, I'll just > change it to pseudo-random. It would be good if we could find a cryptographer who could tell us whether it matters. >> 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. >> >> [RJA: Citations would be pleasant for these claims. > > All right, I think I was just having a major incident > of drain bamage. > > This section should be rewritten: > > The use of a MAC other than 'none' provides rigorerous > protection agains replay attacks at the protocol > level. I think of a MAC (by itself) as only providing integrity/authentication. I imagine that a sequence number does help preclude replay attacks, but I was hoping that someone else had actually done some analysis that we could cite to justify the claim that this MAC combined with this kind of sequence numbering would actually provide replay attack prevention. > In addition, the transport protocol provides a > unique session identifier (bound in part to pseudo-random > data that is part of the algorithm and key exchange process) > that can be used by higher level protocols to > bind data to a given session and prevent replay of > data from prior sessions. > > For example, the authentication protocol uses this to > prevent replay of signatures from previous sessions. > > >> 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. >> >> [RJA: Narrow *which* window ? >> [RJA: Intended meaning is not crystal clear above. > > How about this? > 1. Narrow the window during which the client is vulnerable > to such a man-in-the-middle attack.. If the client ensures > that the... OK with me. >> 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. >> >> [RJA: Is this really true and sufficient ? > > Hmm... I'm not sure if I missed something here or > what? If the man-in-the-middle doesn't have the > private key, he can't complete the authentication > right? It seems that this is true and sufficient > to prevent an attack, but maybe I'm missing something? Maybe you didn't miss anything. It really was a question on my part. Maybe massage the above new paragraph to include your sentence: "[Because] the man-in-the-middle does not have the private key [of whom ?], the he cannot correctly complete the authentication with [whom ?]." My main goal here is clarity, so avoiding pronouns and making the identities clear is appreciated. :-) >> Use of this protocol without reliable association >> >> [RJA: association of what/whom ? > > How about: > > Use of this protocol without reliable association > of hosts and host keys is inherently insecure, but > but may be necessary in non-security critical > environments, and still provides protection against > passive attacks. However, implementors of applications > running on top of this protocol should keep this > possibility in mind. Proposed slight edit to first clause: Use of this protocol without reliable authentication of the binding between a host and its host keys is inherently insecure, but ... >> 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. >> >> [RJA: "perfect forward secrecy" or "forward secrecy" ? > > I'm not sure; this paragraph is quoted from the previous > security considerations section. Would any one else care > to comment? I'm also not sure, but it would be nice if we could find someone who is sure -- preferably someone who can supply a citation or a more detailed rationale to support the claim. >> 11.2.3 Local security policy >> >> Implementer MUST ensure that the credentials provided >> validate the professed user and also MUST ensure that >> the local policy of the 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. >> >> [RJA: Unclear antecedent "this". > > How about: > > In particular, because of the flexible nature of the > SSH connection protocol, it may not be possible to determine > the local security policy that should apply at the time > of authentication, because the kind of service being > requested is not yet clear. Fine with me. >> 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. >> >> [RJA: Add citation for "magic cookie spoofing". > > How about: see "SSH Connection Protocol", Section 4.3.1, page 9. Maybe. Once upon a time there was a component of X11 called "MIT-magic-cookie" that was used to provide (very very weak) security. My original thought was that the original text was referring to that, hence some reference to the X11 protocol specification or to some relevant published paper on X11 would be the right one. With your new text, I'm now wondering whether the intended reference was to the "MIT-magic-cookie" part of the X11 protocol or to something else. I'm confused. >> 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 administrators should, as a matter of course, use >> X11 security mechanism to prevent unauthorized use of >> the X11 server. > > [RJA: Which "X11 security mechanism" is meant ? > [RJA: Also, please add a citation for that mechanism. > > Well, I didn't have a particular one in mind. The > advice is to use any X11 security mechanism. I'd > be willing to remove the paragraph. I'd like to keep text encouraging folks to use as much security as they can. I'm not an expert on the security properties of X11. I was thinking that there probably were some specific security mechanisms (e.g. my vague recollection of the MIT-magic-cookie hack noted above) that we ought to mention and cite. Cheers, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 11 02:20:56 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 CAA00896 for ; Fri, 11 Apr 2003 02:20:55 -0400 (EDT) Received: (qmail 24969 invoked by uid 605); 11 Apr 2003 06:23:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24958 invoked from network); 11 Apr 2003 06:23:26 -0000 Received: from p50852e6b.dip0.t-ipconnect.de (HELO tickit.tick-it.de) (80.133.46.107) by mail.netbsd.org with SMTP; 11 Apr 2003 06:23:26 -0000 Received: from siliconcircus.com (sircus@[192.168.1.102]) by tickit.tick-it.de (8.11.6/8.11.6) with ESMTP id h3B7Eet13924; Fri, 11 Apr 2003 09:14:40 +0200 Message-ID: <3E965F58.2020408@siliconcircus.com> Date: Fri, 11 Apr 2003 08:23:20 +0200 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: Joseph Galbraith CC: sommerfeld@east.sun.com, RJ Atkinson , Chris Lonvick , ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. References: <000a01c2ff87$28777360$4d00a8c0@galb.vandyke.com> In-Reply-To: <000a01c2ff87$28777360$4d00a8c0@galb.vandyke.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Joseph Galbraith wrote: > > The use of a MAC other than 'none' provides rigorerous rigorous -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 11 12:21: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 MAA19848 for ; Fri, 11 Apr 2003 12:21:21 -0400 (EDT) Received: (qmail 13034 invoked by uid 605); 11 Apr 2003 16:23:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13027 invoked from network); 11 Apr 2003 16:23:52 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 11 Apr 2003 16:23:52 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA02025; Fri, 11 Apr 2003 10:23:51 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3BGNp5i016033; Fri, 11 Apr 2003 10:23:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h3BGLYQx026646; Fri, 11 Apr 2003 09:21:34 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h3BGLYxH026645; Fri, 11 Apr 2003 09:21:34 -0700 (PDT) Date: Fri, 11 Apr 2003 09:21:33 -0700 From: Nicolas Williams To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Message-ID: <20030411092133.A26622@binky.central.sun.com> References: <000a01c2ff87$28777360$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rja@extremenetworks.com on Thu, Apr 10, 2003 at 02:09:58PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Apr 10, 2003 at 02:09:58PM -0400, RJ Atkinson wrote: > > On Thursday, Apr 10, 2003, at 13:32 America/Montreal, Joseph Galbraith > wrote: > >> 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. > >> > >> [RJA: Is it random or pseudo-random ? > >> [RJA: Does the difference matter in this case ? > > > > It is probably pseudo-random? I'm not sure if > > it matters. If no one else can say, I'll just > > change it to pseudo-random. > > It would be good if we could find a cryptographer > who could tell us whether it matters. IANAC, but what matters is that if the data in question (e.g., DH parameters) be pseudo-random then the PRNG should be cryptographically secure (i.e., its next output not easily guessed, even when knowing all previous outputs) and, furthermore, the PRNG should be seeded with some truly random inputs (or as random as can be available - not all implementations will have suitable sources of entropy). In any case, the amount of entropy available to a given client or server sometimes may be less than what is needed to run the protocol, in which case either one must resort to PRNGs anyways or refuse to run the protocol. In practice implementors will generally rely on some PRNG. [...] > > In addition, the transport protocol provides a > > unique session identifier (bound in part to pseudo-random > > data that is part of the algorithm and key exchange process) > > that can be used by higher level protocols to > > bind data to a given session and prevent replay of > > data from prior sessions. > > > > For example, the authentication protocol uses this to > > prevent replay of signatures from previous sessions. > > > > > >> 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. > >> > >> [RJA: Narrow *which* window ? > >> [RJA: Intended meaning is not crystal clear above. > > > > How about this? > > 1. Narrow the window during which the client is vulnerable > > to such a man-in-the-middle attack.. If the client ensures > > that the... > > OK with me. > > >> 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. > >> > >> [RJA: Is this really true and sufficient ? > > > > Hmm... I'm not sure if I missed something here or > > what? If the man-in-the-middle doesn't have the > > private key, he can't complete the authentication > > right? It seems that this is true and sufficient > > to prevent an attack, but maybe I'm missing something? > > Maybe you didn't miss anything. It really was a > question on my part. Maybe massage the above new > paragraph to include your sentence: > > "[Because] the man-in-the-middle does not have > the private key [of whom ?], the he cannot > correctly complete the authentication with > [whom ?]." > > My main goal here is clarity, so avoiding pronouns > and making the identities clear is appreciated. :-) Because public key authentication exchanges are cryptographically bound to the SSHv2 session (i.e., to the initial key exchange) they cannot be successfully replayed in other sessions. (Of course, if two session happen to have the same session ID [hash of kex exchanges] then packets from one can be replayed against the other; the chances of such an occurrence are, needless to say, minimal, all the more so the larger the hash function's output and DH parameters used.) Also note that the session ID can be made public without harming the security of the protocol. > >> Use of this protocol without reliable association > >> > >> [RJA: association of what/whom ? > > > > How about: > > > > Use of this protocol without reliable association > > of hosts and host keys is inherently insecure, but > > but may be necessary in non-security critical > > environments, and still provides protection against > > passive attacks. However, implementors of applications > > running on top of this protocol should keep this > > possibility in mind. > > Proposed slight edit to first clause: > > Use of this protocol without reliable authentication > of the binding between a host and its host keys is > inherently insecure, but ... Add "and NOT RECOMMENDED?" > >> 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. > >> > >> [RJA: "perfect forward secrecy" or "forward secrecy" ? > > > > I'm not sure; this paragraph is quoted from the previous > > security considerations section. Would any one else care > > to comment? > > I'm also not sure, but it would be nice if we could find > someone who is sure -- preferably someone who can supply > a citation or a more detailed rationale to support the claim. "Perfect forward secrecy" - see Google search: http://www.google.com/search?hl=en&ie=ISO-8859-1&q=Perfect+forward+secrecy and first link that comes up: http://www.itsecurity.com/asktecs/may201.htm A very simple difinition: http://www.atis.org/tg2k/_perfect_forward_secrecy.html "perfect forward secrecy: In cryptography, of a key-establishment protocol, the condition in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session." ... > >> 11.2.3 Local security policy > >> > >> Implementer MUST ensure that the credentials provided > >> validate the professed user and also MUST ensure that > >> the local policy of the 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. > >> > >> [RJA: Unclear antecedent "this". > > > > How about: > > > > In particular, because of the flexible nature of the > > SSH connection protocol, it may not be possible to determine > > the local security policy that should apply at the time > > of authentication, because the kind of service being > > requested is not yet clear. > > Fine with me. What if no policy is available? [...] Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 11 13:30:50 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 NAA22281 for ; Fri, 11 Apr 2003 13:30:49 -0400 (EDT) Received: (qmail 26652 invoked by uid 605); 11 Apr 2003 17:33:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26645 invoked from network); 11 Apr 2003 17:33:21 -0000 Received: from firebird.cisco.com (HELO fire.cisco.com) (171.68.227.73) by mail.netbsd.org with SMTP; 11 Apr 2003 17:33:21 -0000 Received: from REMAKERW2K (remaker-w2k.cisco.com [171.69.103.87]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h3BHXIr17554; Fri, 11 Apr 2003 10:33:18 -0700 (PDT) Message-ID: <010f01c30050$70adae00$576745ab@amer.cisco.com> From: "Phillip Remaker" To: , References: <200304092320.h39NKwaj018310@thunk.east.sun.com> Subject: Re: WG Chair nits for draft-ietf-secsh-break-00.txt Date: Fri, 11 Apr 2003 10:33:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > 1) security considerations section is missing. I would think that the main security considerations are: - Denial of service based on a long duration break. Should be addressed on the server side - Unauthorized parties sending break. Should be addressed by SSH security freamework. - There is no means in the protocol to make certain users able to view, but not send break. This is optionally addressed on the server side, based on authentication credentials. The protocol need not be concerned. Unauthorized break requests should be treated as if the server does not support break. Anything else? Should we fold all that in? > s-c fodder: > > Because "break" is typically used to enter low-level administrative > or debugging functions, implementors of this extension SHOULD provide > a mechanism to control whether this extension is accepted, and > administrators should use care when deciding whether to enable this > feature. > 3) no mention of what to do when the thing on the other end isn't > (directly) connected to a traditional serial line. I'm in favor of > saying "MAY implement functionally similar implementation-defined > behavior". > > examples: > - a ssh-to-telnet gateway could convert into the equivalent > telnet option. > - a service processor providing remote console access may use some > other out-of-band signal to the system it manages rather than > the traditional BREAK.. OK, excellent. I like those examples. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 14 22:05:45 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 WAA00354 for ; Mon, 14 Apr 2003 22:05:44 -0400 (EDT) Received: (qmail 13306 invoked by uid 605); 15 Apr 2003 02:08:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13261 invoked from network); 15 Apr 2003 02:08:12 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 15 Apr 2003 02:08:12 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id 1E0497FE76; Tue, 15 Apr 2003 05:07:39 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id 1BAD97FE75 for ; Tue, 15 Apr 2003 05:07:39 +0300 (EEST) Date: Tue, 15 Apr 2003 05:07:38 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@netbsd.org Subject: RE: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Some observations on the discussion on the security considerations. Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts., Nicolas Williams, Fri 4/11/2003 9:22 AM > > >> 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. > > >> > > >> [RJA: Is it random or pseudo-random ? > > >> [RJA: Does the difference matter in this case ? > > > > > > It is probably pseudo-random? I'm not sure if > > > it matters. If no one else can say, I'll just > > > change it to pseudo-random. > > > > It would be good if we could find a cryptographer > > who could tell us whether it matters. > > IANAC, but what matters is that if the data in question (e.g., DH > parameters) be pseudo-random then the PRNG should be cryptographically > secure (i.e., its next output not easily guessed, even when > knowing all > previous outputs) and, furthermore, the PRNG should be seeded > with some > truly random inputs (or as random as can be available - not all > implementations will have suitable sources of entropy). > > In any case, the amount of entropy available to a given > client or server > sometimes may be less than what is needed to run the > protocol, in which > case either one must resort to PRNGs anyways or refuse to run the > protocol. In practice implementors will generally rely on some PRNG. > > [...] I am not a cryptographer either, but cryptographically strong PRNG would be a safe choice. The cookies are supposed to be used in the generation of the exchange hash, for which: 1) it must not be possible for either party to affect the resulting hash 2) the resulting hash must be unique That being said, the use of the cookies is dependant on the key exchange method used. For what it's worth, it appears to me that 'diffie-hellman-group1-sha1' is safe even if the cookies were constant (don't take my word for it, though). [...] > > >> 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. > > >> > > >> [RJA: "perfect forward secrecy" or "forward secrecy" ? > > > > > > I'm not sure; this paragraph is quoted from the previous > > > security considerations section. Would any one else care > > > to comment? > > > > I'm also not sure, but it would be nice if we could find > > someone who is sure -- preferably someone who can supply > > a citation or a more detailed rationale to support the claim. > > "Perfect forward secrecy" - see Google search: [...] This is not "perfect forward secrecy". From what I understand, the text merely points out that the transport layer provides confidentiality and integrity protection [given encryption and mac] for authentication protocol (and methods within, e.g. password authentication) running on top of it. Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts., R.J Atkinson, Thu 4/10/2003 11:10 AM: >>> 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. >>> >>> [RJA: Citations would be pleasant for these claims. >> >> All right, I think I was just having a major incident >> of drain bamage. >> >> This section should be rewritten: >> >> The use of a MAC other than 'none' provides rigorerous >> protection agains replay attacks at the protocol >> level. > > I think of a MAC (by itself) as only providing integrity/authentication. > > I imagine that a sequence number does help preclude replay > attacks, but I was hoping that someone else had actually > done some analysis that we could cite to justify the claim > that this MAC combined with this kind of sequence numbering > would actually provide replay attack prevention. TLS uses sequence number as an input into a MAC for replay protection, but they don't cite any references either. Again, I am not a cryptographer, For HMAC constructs, if one assumes MAC(unencrypted packet) detects the tampering of the packet, MAC(sequence number || unencrypted packet) should be secure as well. The underlying hash function should make certain that a change in the sequence number with the rest of the data being replayed will result in an invalid MAC. Given no encryption, attacker knows: - next sequence number (nsn) - sequence number (sn) packet: - packet len (pkl) - padding len (pdl) - payload (pl) - padding (p) In order to replay a packet, attacker needs to find nsn, p' such that: H(K xor opad || H(K xor ipad || nsn || pkl || pdl || pl || p' )) = H(K xor opad || H(K xor ipad || sn || pkl || pdl || pl || p )) nsn is 32bit, p' is 32-2048bit depending on the captured packet; K is 512bit with sha1 and md5 (which of ???bits are secret with group1?) An attacker has no knowledge of nor control over the whole input of either the inner or the outer hashing operation. I can't work out the numbers, I'm afraid, but if the H is strong, HMAC(sequence_number || unencrypted packet) appears a good construct to me. Implementation must make sure the rekeying happens before the sequence number wraps around. Regards, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 14 22:50: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 WAA01222 for ; Mon, 14 Apr 2003 22:50:03 -0400 (EDT) Received: (qmail 6071 invoked by uid 605); 15 Apr 2003 02:52:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6064 invoked from network); 15 Apr 2003 02:52:38 -0000 Received: from shawidc-mo1.cg.shawcable.net (HELO pd6mo3so.prod.shaw.ca) (24.71.223.10) by mail.netbsd.org with SMTP; 15 Apr 2003 02:52:38 -0000 Received: from pd2mr3so.prod.shaw.ca (pd2mr3so-ser.prod.shaw.ca [10.0.141.108]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0HDD00H2V6NLC5@l-daemon> for ietf-ssh@netbsd.org; Mon, 14 Apr 2003 20:52:33 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca (pn2ml6so-qfe0.prod.shaw.ca [10.0.121.150]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0HDD002I06NLQQ@l-daemon> for ietf-ssh@netbsd.org; Mon, 14 Apr 2003 20:52:33 -0600 (MDT) Received: from shaw.ca (h24-78-167-227.vn.shawcable.net [24.78.167.227]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0HDD002JR6NLI0@l-daemon> for ietf-ssh@netbsd.org; Mon, 14 Apr 2003 20:52:33 -0600 (MDT) Date: Mon, 14 Apr 2003 19:52:35 -0700 From: lorneman Subject: openssh To: ietf-ssh@netbsd.org Message-id: <3E9B73F3.B656EB65@shaw.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.19-4GB i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7BIT i need it From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 14 23:59: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 XAA02455 for ; Mon, 14 Apr 2003 23:59:31 -0400 (EDT) Received: (qmail 13806 invoked by uid 605); 15 Apr 2003 04:02:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13799 invoked from network); 15 Apr 2003 04:02:06 -0000 Received: from unknown (HELO skull.piratehaven.org) (67.104.22.119) by mail.netbsd.org with SMTP; 15 Apr 2003 04:02:06 -0000 Received: by skull.piratehaven.org (Postfix, from userid 509) id D0B0E101D8; Mon, 14 Apr 2003 21:01:58 -0700 (PDT) Date: Mon, 14 Apr 2003 21:01:58 -0700 From: Dale Harris To: ietf-ssh@netbsd.org Subject: Re: openssh Message-ID: <20030415040158.GE26351@maybe.org> References: <3E9B73F3.B656EB65@shaw.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9B73F3.B656EB65@shaw.ca> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Apr 14, 2003 at 07:52:35PM -0700, lorneman elucidated: > i need it No you don't. ;-) -- Dale Harris rodmur@maybe.org /.-) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 11:53: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 LAA02278 for ; Tue, 15 Apr 2003 11:53:33 -0400 (EDT) Received: (qmail 6672 invoked by uid 605); 15 Apr 2003 15:56:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6665 invoked from network); 15 Apr 2003 15:56:07 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 Apr 2003 15:56:07 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA23179; Tue, 15 Apr 2003 09:56:07 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3FFu65i002610; Tue, 15 Apr 2003 09:56:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h3FFrlQx028524; Tue, 15 Apr 2003 08:53:47 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h3FFrkCq028523; Tue, 15 Apr 2003 08:53:46 -0700 (PDT) Date: Tue, 15 Apr 2003 08:53:46 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Message-ID: <20030415085346.A28517@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Tue, Apr 15, 2003 at 05:07:38AM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Apr 15, 2003 at 05:07:38AM +0300, Heikki Nousiainen wrote: > Some observations on the discussion on the security considerations. > > Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts., > Nicolas Williams, Fri 4/11/2003 9:22 AM [...] > > > I'm also not sure, but it would be nice if we could find > > > someone who is sure -- preferably someone who can supply > > > a citation or a more detailed rationale to support the claim. > > > > "Perfect forward secrecy" - see Google search: > [...] > > This is not "perfect forward secrecy". From what I understand, the text > merely points out that the transport layer provides confidentiality and > integrity protection [given encryption and mac] for authentication > protocol (and methods within, e.g. password authentication) running on top > of it. Diffie-Hellman (DH) key exchanges have PFS as a property; specifically, keys exchanged with DH are perfectly forward secure. SSHv2 uses DH as the basis of the key exchange and derives session keys from the DH exchange. Ergo SSHv2 has PFS as a property. The text should say so since this is an important cryptographic property of the protocol. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 12:30: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 MAA03289 for ; Tue, 15 Apr 2003 12:30:37 -0400 (EDT) Received: (qmail 26927 invoked by uid 605); 15 Apr 2003 16:30:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26087 invoked from network); 15 Apr 2003 16:29:58 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 15 Apr 2003 16:29:58 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id F29517FE76; Tue, 15 Apr 2003 19:29:44 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id F1CDA7FE75; Tue, 15 Apr 2003 19:29:44 +0300 (EEST) Date: Tue, 15 Apr 2003 19:29:44 +0300 (EEST) From: Heikki Nousiainen To: Nicolas Williams Cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. In-Reply-To: <20030415085346.A28517@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 15 Apr 2003, Nicolas Williams wrote: > On Tue, Apr 15, 2003 at 05:07:38AM +0300, Heikki Nousiainen wrote: > > Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts., > > Nicolas Williams, Fri 4/11/2003 9:22 AM > > [...] > > > > I'm also not sure, but it would be nice if we could find > > > > someone who is sure -- preferably someone who can supply > > > > a citation or a more detailed rationale to support the claim. > > > > > > "Perfect forward secrecy" - see Google search: > > [...] > > > > This is not "perfect forward secrecy". From what I understand, the text > > merely points out that the transport layer provides confidentiality and > > integrity protection [given encryption and mac] for authentication > > protocol (and methods within, e.g. password authentication) running on top > > of it. > > Diffie-Hellman (DH) key exchanges have PFS as a property; specifically, > keys exchanged with DH are perfectly forward secure. > > SSHv2 uses DH as the basis of the key exchange and derives session keys > from the DH exchange. > > Ergo SSHv2 has PFS as a property. > > The text should say so since this is an important cryptographic property > of the protocol. Yes, PFS is a property we get wih DH key exchanges, but I don't think it applies to paragraph 11.2. Clearly, compromise of a session key leads into a compromise of secret data, e.g. password, sent over that session. PFS is not property of the SSHv2 protocol, but a property of the key exchange method, and I'd be vary to lay claims on it in the SSHv2 protocol level. Regards, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 12:59:17 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 MAA03963 for ; Tue, 15 Apr 2003 12:59:16 -0400 (EDT) Received: (qmail 16740 invoked by uid 605); 15 Apr 2003 17:01:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16733 invoked from network); 15 Apr 2003 17:01:51 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 Apr 2003 17:01:51 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA10631; Tue, 15 Apr 2003 11:01:51 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3FH1p5i002170; Tue, 15 Apr 2003 11:01:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h3FGxVQx028563; Tue, 15 Apr 2003 09:59:31 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h3FGxVQs028562; Tue, 15 Apr 2003 09:59:31 -0700 (PDT) Date: Tue, 15 Apr 2003 09:59:31 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Message-ID: <20030415095931.D18860@binky.central.sun.com> References: <20030415085346.A28517@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Tue, Apr 15, 2003 at 07:29:44PM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Apr 15, 2003 at 07:29:44PM +0300, Heikki Nousiainen wrote: > On Tue, 15 Apr 2003, Nicolas Williams wrote: > > Ergo SSHv2 has PFS as a property. > > > > The text should say so since this is an important cryptographic property > > of the protocol. > > Yes, PFS is a property we get wih DH key exchanges, but I don't think it > applies to paragraph 11.2. Clearly, compromise of a session key leads into > a compromise of secret data, e.g. password, sent over that session. Of course. I'd lost track of the text in question - I was responding to the question of what is PFS and what is a good reference for it. Now that I look at it, I have to agree with you that the text should clearly state that PFS is a property of the key exchange, that SSHv2 key exchange provides PFS for the session keys used in the transport layer (the proposed text reads: "The transport layer provides forward secrecy for password authentication ...," this is not correct). > PFS is not property of the SSHv2 protocol, but a property of the key > exchange method, and I'd be vary to lay claims on it in the SSHv2 > protocol level. This is evident from the definition of PFS. SSHv2 sessions are secure even if private keying/authentication material is later revealed[*], but not if the session keys are revealed. So, given the definition of PFS, SSHv2 does have PFS. [*] Of course, if the DH private parameters for the client and server and revealed then the session key is revealed, but these items can be thrown away after the key exchange completes. It's worth pointing out that these items should not be allowed to end up on swap space and that they should be erased from memory as soon as the kex completes. Perhaps there should be a sub-section on the key exchange phase of the protocol. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 13:28: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 NAA04851 for ; Tue, 15 Apr 2003 13:28:39 -0400 (EDT) Received: (qmail 2703 invoked by uid 605); 15 Apr 2003 17:31:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2695 invoked from network); 15 Apr 2003 17:31:14 -0000 Received: from intra.cyclades.com (64.186.161.6) by mail.netbsd.org with SMTP; 15 Apr 2003 17:31:14 -0000 Received: from mail.cyclades.com (localhost.localdomain [127.0.0.1]) by mail.cyclades.com (Postfix) with SMTP id BECF7416A for ; Tue, 15 Apr 2003 10:31:14 -0700 (PDT) Received: from cyclades.com (64-186-161-165.cyclades.com [64.186.161.165]) by intra.cyclades.com (Postfix) with ESMTP id 9BAF14163 for ; Tue, 15 Apr 2003 13:31:14 -0400 (EDT) Message-ID: <3E9C41E1.A487A075@cyclades.com> Date: Tue, 15 Apr 2003 10:31:13 -0700 From: Ivan Passos Organization: Cyclades Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Re: Please publish attached draft-ietf-secsh-break-01 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Simon Tatham wrote: > > 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' :-) You can count Cyclades as a commited maintainer then! ;) Cyclades currently uses a modified version of OpenSSH with our own implementation of break-over-SSH (based on the interception of a pre-configurable string, which defaults to `~break'). Now that there is a standard using the SSH protocol itself, Cyclades will work on getting this implementation into OpenSSH (we'll make both implementations work on our products -- for backwards compatibility --, and will work with the OpenSSH folks to have the standard one included in the official OpenSSH release). Does anyone have pointers as to who we should contact in the OpenSSH team to work on this?!?! Thanks! Later, -- -------------------------------------------------------------------- Ivan Passos -o) Product Marketing Manager, Cyclades /\\ http://www.cyclades.com _\_V -------------------------------------------------------------------- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 14:14: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 OAA05904 for ; Tue, 15 Apr 2003 14:14:32 -0400 (EDT) Received: (qmail 25882 invoked by uid 605); 15 Apr 2003 18:16:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25730 invoked from network); 15 Apr 2003 18:16:44 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 15 Apr 2003 18:16:44 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id 5B71E7FE76; Tue, 15 Apr 2003 21:16:40 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id 58F987FE75; Tue, 15 Apr 2003 21:16:40 +0300 (EEST) Date: Tue, 15 Apr 2003 21:16:40 +0300 (EEST) From: Heikki Nousiainen To: Nicolas Williams Cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. In-Reply-To: <20030415095931.D18860@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 15 Apr 2003, Nicolas Williams wrote: > On Tue, Apr 15, 2003 at 07:29:44PM +0300, Heikki Nousiainen wrote: > > On Tue, 15 Apr 2003, Nicolas Williams wrote: > > > Ergo SSHv2 has PFS as a property. > > > > > > The text should say so since this is an important cryptographic property > > > of the protocol. > > > > Yes, PFS is a property we get wih DH key exchanges, but I don't think it > > applies to paragraph 11.2. Clearly, compromise of a session key leads into > > a compromise of secret data, e.g. password, sent over that session. > > Of course. I'd lost track of the text in question - I was responding > to the question of what is PFS and what is a good reference for it. > > Now that I look at it, I have to agree with you that the text should > clearly state that PFS is a property of the key exchange, that SSHv2 key > exchange provides PFS for the session keys used in the transport layer > (the proposed text reads: "The transport layer provides forward secrecy > for password authentication ...," this is not correct). Now that I read my e-mail again, I could have made my point clearer, sorry about that. In conclusion, I think RJ Atkinson's original question '"perfect forward secrecy" or "forward secrecy"' is irrelevent to 11.2. I believe the intention of this chapter is that authentication schemes based on shared secret are secured by the transport layer below, given encryption and MAC. > > PFS is not property of the SSHv2 protocol, but a property of the key > > exchange method, and I'd be vary to lay claims on it in the SSHv2 > > protocol level. > > This is evident from the definition of PFS. SSHv2 sessions are secure > even if private keying/authentication material is later revealed[*], but > not if the session keys are revealed. So, given the definition of PFS, > SSHv2 does have PFS. My point is, since we don't know whether the key exchange algorithm provides PFS, I think we can't make an explicit claim about PFS in SSHv2. Certainly that is the case for diffie-hellman-group1-sha1 (and as far as I know, for the rest of the key exchange methods drafted), but not necessarily for all key exchange methods used within the protocol. [...] > Perhaps there should be a sub-section on the key exchange phase of the > protocol. The core document should address diffie-hellman-group1-sha1, and each key exhance method draft should discuss the security considerations for the given alogrihm. Best regards, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 14:30: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 OAA06328 for ; Tue, 15 Apr 2003 14:30:36 -0400 (EDT) Received: (qmail 10710 invoked by uid 605); 15 Apr 2003 18:32:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10660 invoked from network); 15 Apr 2003 18:32:53 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Apr 2003 18:32:53 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA29244; Tue, 15 Apr 2003 12:32:53 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3FIWq1q024639; Tue, 15 Apr 2003 12:32:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h3FIUXQx028592; Tue, 15 Apr 2003 11:30:33 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h3FIUW22028591; Tue, 15 Apr 2003 11:30:32 -0700 (PDT) Date: Tue, 15 Apr 2003 11:30:32 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: ietf-ssh@netbsd.org Subject: Re: Newer Rev of Section 11 - was: Re: IESG feedback on core drafts. Message-ID: <20030415113032.E18860@binky.central.sun.com> References: <20030415095931.D18860@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Tue, Apr 15, 2003 at 09:16:40PM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Apr 15, 2003 at 09:16:40PM +0300, Heikki Nousiainen wrote: > My point is, since we don't know whether the key exchange algorithm > provides PFS, I think we can't make an explicit claim about PFS in SSHv2. > Certainly that is the case for diffie-hellman-group1-sha1 (and as far as > I know, for the rest of the key exchange methods drafted), but not > necessarily for all key exchange methods used within the protocol. Er, yes, but, a) today all key exchange methods specified for SSHv2 have PFS, and b) one would hope that all future ones will also. Of course, (b) is no guarantee of anything, so I must cede the point :) > [...] > > Perhaps there should be a sub-section on the key exchange phase of the > > protocol. > > The core document should address diffie-hellman-group1-sha1, and each key > exhance method draft should discuss the security considerations for the > given alogrihm. I think the core doc's security considerations section can certainly state that "if the kex used has PFS then the session keys can be perfectly forward secure" or something like that. Point is, it's worth pointing out, in the core drafts, that PFS is there [always today, even if perhaps not always tomorrow]. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 15 16:09:47 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 QAA10020 for ; Tue, 15 Apr 2003 16:09:46 -0400 (EDT) Received: (qmail 17488 invoked by uid 605); 15 Apr 2003 20:10:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17481 invoked from network); 15 Apr 2003 20:10:40 -0000 Received: from ibmx330-1.bodacion.com (208.254.152.41) by mail.netbsd.org with SMTP; 15 Apr 2003 20:10:40 -0000 Received: from ibmx330-1.bodacion.com ([207.208.90.41]) by ibmx330-1.bodacion.com with esmtp (Exim 3.35 #1 (Debian)) id 195V3a-000635-00 for ; Tue, 15 Apr 2003 13:21:22 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: NSA's SPOCK Program Uses HYDRA to Secure its Web site From: HYDRA PR To: ietf-ssh@netbsd.org Message-Id: Date: Tue, 15 Apr 2003 13:21:22 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit For Immediate Release: NSA's SPOCK Program Selects Bodacion's HYDRA Web Server National Security Agency Deploys Bodacion's Secure Web Technology to Deflect Hackers, Shorten Training Time and Reduce Maintenance Costs BARRINGTON, ILLINOIS (April 2, 2003) — The Security Proof of Concept Keystone (SPOCK), a Department of Defense consortium of corporate and government organizations sponsored by the National Security Agency (NSA), has selected Bodacion Technologies' HYDRA secure Web Services appliance as its primary Web server. The NSA cited HYDRA's extreme resistance to all known hacking attacks, as well as the appliance's simplicity and reliability, as reasons for choosing Bodacion's product. "After SPOCK demonstrations showed HYDRA's improved security and maintainability over current solutions, the NSA saw a clear fit for their own needs," said Eric Ridvan Uner, Co-Founder of Bodacion Technologies, Co-Inventor of HYDRA and his company's chief liaison to government agencies. "The NSA, of course, has a vested interest in making sure that hackers stay out of any NSA Web site, and so the SPOCK program selected HYDRA for its high level of resistance to hacking attacks of all kinds." Compatibility and maintenance were also primary SPOCK concerns, according to Uner. HYDRA was a simple drop-in replacement for the legacy solution, he said, which required minimal deployment effort. HYDRA also will require less maintenance and training than the legacy system, he added. Last year, SPOCK conducted a demonstration of HYDRA consisting of security claims by Bodacion Technologies and tests jointly agreed to by the participants. The results were that all Bodacion’s claims were verified. More than 350 technologists from civil and defense entities are involved in the SPOCK program; currently there are 65 security-related corporations and 19 government agencies participating in the program. Bodacion’s appliance is designed specifically for secure Web Services computing and has captured the attention of senior authorities at national intelligence and Department of Defense organizations because it does not suffer from common vulnerabilities of general purpose computers/servers that run general purpose operating systems. For example, HYDRA is the only Web server known to prevent “tunneling,” a technique malicious system users apply to observe the activities of other network users. Such protection is vital for federal agencies with multiple levels of security interests. Major General (retired) Michael Davidson, a former assistant to the Joint Chiefs of Staff and an advisor to Bodacion executives, facilitates the company's relationships with government organizations. “For federal agencies continually assaulted by hackers and other malicious cyber-criminals, HYDRA represents a critical Internet security technology,” Davidson said. About Bodacion Technologies Bodacion Technologies, LLC, creates revolutionary Web Services products for Internet-intensive enterprises that are seeking secure, reliable, high-performance systems to minimize the Internet's risks and maximize its rewards. The company’s flagship product, HYDRA, combines the security of complex mathematics with the reliability of embedded systems to create a Web Services appliance that cannot be hacked, will virtually never crash and can handle thousands of concurrent users. Based in Barrington, Illinois, Bodacion Technologies’ serves an international clientele of government agencies, financial institutions and other e-Business enterprises. For more information, visit http://www.bodacion.com/spock/ Jennifer Franzese Bodacion Technologies 847.842.9008 franzese@bodaction.com Bob Dirkes Tech Image, Ltd. (for Bodacion Technologies) 847.632.0040x237 bob.dirkes@techimage.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 16 09:17:29 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 JAA00137 for ; Wed, 16 Apr 2003 09:17:24 -0400 (EDT) Received: (qmail 19305 invoked by uid 605); 16 Apr 2003 13:19:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19289 invoked from network); 16 Apr 2003 13:19:50 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 16 Apr 2003 13:19:50 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3GDJngE025467 for ; Wed, 16 Apr 2003 06:19:49 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA12314 for ; Wed, 16 Apr 2003 06:19:48 -0700 (PDT) Date: Wed, 16 Apr 2003 06:19:48 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Even Newer Section 11 for Your Comments Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="836307491-579758561-1050443957=:15447" Content-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --836307491-579758561-1050443957=:15447 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi Folks, My thanks to everyone who's been discussing and making comments upon the proposed Section 11. Below is a revision based upon the recent email thread. Please look that over and provide your further comments. To make the task of looking at the revisions easier, I've attached a file with some html in it. (Your indulgences, please.) When viewed in a browser it displays redline striking to indicate deleted passages and green text to indicate insertions. It's not exact but it has markups at or near the places that have changed which will hopefully allow everyone to review these changes without having to hunt them down manually. I've edited some significant changes into Section 11.1.3 "Replay" and have added a new Section 11.1.7 "Forward Secrecy". Please look those over carefully. I've also tried very hard to keep outstanding questions in this which still need to be addressed. These should be findable by looking for "[xxx: " at the start of lines below. One comment that was raised was about adding a new section on the security of the key exchange. I have not attempted to address that and it is not noted below. If that is needed in this section, would someone (Joseph? :-) please propose text? Thanks, Chris ===vvv=== New Proposal for Section 11 ===vvv=== 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 confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [2] provides a suite of mechanism which can be used to authenticating the client user to the server. Individual mechanisms specified in the in authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol. The connection protocol [3] specifies a mechanism to multiplex multiple streams [channels] of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 11.1 Transport 11.1.1 Confidentiality It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry. At the time of this writing, ciphers commonly in use include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has been accepted by The US Federal Information Processing Standards [FIPS-197] and the cryptographic community as being acceptable for this purpose as well. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410, which will show that its use does not meet the intent of this protocol. The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack 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 Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack) to work, the attacker would need to know the IV of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e it is in the internal buffers of the ssh implementation or even in the kernel) then this attack will not work. If the last packet has been sent out to the network (i.e the attacker has access to it) then he can use the attack. In the optimal case an implementor would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementors may wish to check to see if there are any unsent packets awaiting transmission, but unfortunately it is not normally easy to obtain this information from the kernel or buffers. If there are not, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successfull. As an example, consider the following case: Client Server ------ ------ TCP(seq=x, len=500) -> contains Record 1 [500 ms passes, no ACK] TCP(seq=x, len=1000) -> contains Records 1,2 <- ACK (1) The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment (2) Record 2 is *not* at the beginning of the TCP segment and never will be, since it gets ACKed. (3) Yet, the attack is possible because Record 1 has already been seen. As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. On the other hand, it's perfectly safe to have the following situation: Client Server ------ ------ TCP(seq=x, len=500) -> contains SSH_MSG_IGNORE TCP(seq=y, len=500) -> contains Data Provided that the IV for second SSH Record is fixed after the data for the Data packet is determined -i.e. you do: read from user encrypt null packet encrypt data packet 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 might start to leak information after 2**32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [1] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2**28 packets at the very most. 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. If the random data here (e.g., DH parameters) are pseudo-random then the PRNG should be cryptographically secure (i.e., its next output not easily guessed, even when knowing all previous outputs) and, furthermore, the PRNG should be seeded with some truly random inputs, or as random as can be available. In any case, the amount of entropy available to a given client or server sometimes may be less than what is needed to run the protocol, in which case either one must resort to PRNGs anyways or refuse to run the protocol. In practice implementors will generally rely on some PRNG. RFC 1750 [1750] contains more discussion on this. [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. The use of a MAC other than 'none' provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions. For example, the authentication protocol uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange) they cannot be successfully replayed in other sessions. Note that the session ID can be made public without harming the security of the protocol. If two session happen to have the same session ID [hash of key exchanges] then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more so true when specifying larger hash function outputs and DH parameters. [RJA: I imagine that a sequence number does help preclude replay attacks, [RJA: but I was hoping that someone else had actually done some analysis [RJA: that we could cite to justify the claim that this MAC combined with [RJA: this kind of sequence numbering would actually provide replay [RJA: attack prevention. 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 during which the client is vulnerable to such a man-in-the-middle attack. 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 attacks. For example, public-key authentication is not vulnerable to man-in-the-middle attack as long as the public-key of the server has been securely distributed to the clients before the first SSH connection is made. This is because the signature is made across data that is session specific. The session specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session specific data from the server since he does not have the private key of that server. [RJA: Is this really true and sufficient ? 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 a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. It may however be necessary in non-security critical environments, and will still provide protection against passive attacks. Implementors of protocols and applications running on top of this protocol should keep this possibility in mind. 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.1.7 Forward Secrecy It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS). PFS is essentially defined as the cryptographic property of a key-establishment protocol in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session. [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using diffie-hellman-group1-sha1 are secure even if private keying/authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSHv2 does have PFS. It is hoped that all other key exchange mechanisms proposed and used in the future will also provide PFS. This property is not commuted to any of the applications or protocols using SSH as a transport however. The transport layer of SSH provides confidentiality for password authentication and other methods that rely on secret data. Of course, if the DH private parameters for the client and server and revealed then the session key is revealed, but these items can be thrown away after the key exchange completes. It's worth pointing out that these items should not be allowed to end up on swap space and that they should be erased from memory as soon as the key exchange completes. [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom Glossary 2000", American National Standards Institute, Inc., Approved February 28, 2001. 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 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 confidentiality, 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 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 the local security policy that should apply 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. [Nico: What if no policy is available? 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 enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested. The server could require both password and public-key authentication, however, this requires the client to expose its password to the server (see section on password authentication below.) 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 compromises. 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 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 compromised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 11.3.2 Proxy forwarding The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls. As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data passed 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. More information about the use of the X11 magic cookie may be found in many of the available manual references and implementation guides for X11. For example, viewing the manual page for "xauth" in BSD systems may be one place to start. 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 administrators should, as a matter of course, use X11 security mechanism to prevent unauthorized use of the X11 server. [RJA: Which "X11 security mechanism" is meant ? [RJA: Also, please add a citation for that mechanism. [JG: Well, I didn't have a particular one in mind. The [JG: advice is to use any X11 security mechanism. I'd [JG: be willing to remove the paragraph. [RJA: I'd like to keep text encouraging folks to use as much [RJA: security as they can. I'm not an expert on the security [RJA: properties of X11. I was thinking that there probably were [RJA: some specific security mechanisms (e.g. my vague recollection [RJA: of the MIT-magic-cookie hack noted above) that we ought [RJA: to mention and cite. ===^^^=== New Proposal for Section 11 ===^^^=== --836307491-579758561-1050443957=:15447 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ssh_diff2.html" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ssh_diff2.html" Content-Transfer-Encoding: BASE64 PHByZT4NCjExLiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBJbiBv cmRlciB0byBtYWtlIHRoZSBlbnRpcmUgYm9keSBvZiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBtb3JlDQogICBhY2Nlc3NpYmxlLCBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBmb3IgdGhlIHRyYW5zcG9ydCwgYXV0aGVudGljYXRpb24s DQogICBhbmQgY29ubmVjdGlvbiBkb2N1bWVudHMgaGF2ZSBiZWVuIGdhdGhl cmVkIGhlcmUuDQoNCiAgIFRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgWzFdIHBy b3ZpZGVzIGEgY29uZmlkZW50aWFsIGNoYW5uZWwgb3ZlciBhbg0KICAgaW5z ZWN1cmUgbmV0d29yay4gIEl0IHBlcmZvcm1zIHNlcnZlciBob3N0IGF1dGhl bnRpY2F0aW9uLCBrZXkNCiAgIGV4Y2hhbmdlLCBlbmNyeXB0aW9uLCBhbmQg aW50ZWdyaXR5IHByb3RlY3Rpb24uICBJdCBhbHNvIGRlcml2ZXMgYQ0KICAg dW5pcXVlIHNlc3Npb24gaWQgdGhhdCBtYXkgYmUgdXNlZCBieSBoaWdoZXIt bGV2ZWwgcHJvdG9jb2xzLg0KDQogICBUaGUgYXV0aGVudGljYXRpb24gcHJv dG9jb2wgWzJdIHByb3ZpZGVzIGEgc3VpdGUgb2YgbWVjaGFuaXNtIHdoaWNo DQogICBjYW4gYmUgdXNlZCB0byBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50 IHVzZXIgdG8gdGhlIHNlcnZlci4NCiAgIEluZGl2aWR1YWwgbWVjaGFuaXNt cyBzcGVjaWZpZWQgaW4gdGhlIGluIGF1dGhlbnRpY2F0aW9uIHByb3RvY29s IHVzZQ0KICAgdGhlIHNlc3Npb24gaWQgcHJvdmlkZWQgYnkgdGhlIHRyYW5z cG9ydCBwcm90b2NvbCBhbmQvb3IgZGVwZW5kIG9uIHRoZQ0KICAgc2VjdXJp dHkgYW5kIGludGVncml0eSBndWFyYW50ZWVzIG9mIHRoZSB0cmFuc3BvcnQg cHJvdG9jb2wuDQoNCiAgIFRoZSBjb25uZWN0aW9uIHByb3RvY29sIFszXSBz cGVjaWZpZXMgYSBtZWNoYW5pc20gdG8gbXVsdGlwbGV4IA0KICAgbXVsdGlw bGUgc3RyZWFtcyBbY2hhbm5lbHNdIG9mIGRhdGEgb3ZlciB0aGUgY29uZmlk ZW50aWFsIGFuZA0KICAgYXV0aGVudGljYXRlZCB0cmFuc3BvcnQuIEl0IGFs c28gc3BlY2lmaWVzIGNoYW5uZWxzIGZvciBhY2Nlc3NpbmcgYW4gDQogICBp bnRlcmFjdGl2ZSBzaGVsbCwgZm9yICdwcm94eS1mb3J3YXJkaW5nJyB2YXJp b3VzIGV4dGVybmFsIHByb3RvY29scw0KICAgb3ZlciB0aGUgc2VjdXJlIHRy YW5zcG9ydCAoaW5jbHVkaW5nIGFyYml0cmFyeSBUQ1AvSVAgcHJvdG9jb2xz KSwgYW5kIA0KICAgZm9yIGFjY2Vzc2luZyBzZWN1cmUgJ3N1YnN5c3RlbXMn IG9uIHRoZSBzZXJ2ZXIgaG9zdC4NCg0KMTEuMSBUcmFuc3BvcnQNCg0KDQox MS4xLjEgQ29uZmlkZW50aWFsaXR5DQoNCiAgIEl0IGlzIGJleW9uZCB0aGUg c2NvcGUgb2YgdGhpcyBkb2N1bWVudCBhbmQgdGhlIFNlY3VyZSBTaGVsbCBX b3JraW5nDQogICBHcm91cCB0byBhbmFseXplIG9yIHJlY29tbWVuZCBzcGVj aWZpYyBjaXBoZXJzIG90aGVyIHRoYW4gdGhlIG9uZXMNCiAgIHdoaWNoIGhh dmUgYmVlbiBlc3RhYmxpc2hlZCBhbmQgYWNjZXB0ZWQgd2l0aGluIHRoZSBp bmR1c3RyeS4gIEF0IHRoZQ0KICAgdGltZSBvZiB0aGlzIHdyaXRpbmcsIGNp cGhlcnMgY29tbW9ubHkgaW4gdXNlIGluY2x1ZGUgM0RFUywgQVJDRk9VUiwN CiAgIHR3b2Zpc2gsIHNlcnBlbnQgYW5kIGJsb3dmaXNoLiAgQUVTIGhhcyBi ZWVuIGFjY2VwdGVkIGJ5IFRoZSBVUyBGZWRlcmFsDQogICBJbmZvcm1hdGlv biBQcm9jZXNzaW5nIFN0YW5kYXJkcyBbRklQUy0xOTddIGFuZCB0aGUgY3J5 cHRvZ3JhcGhpYw0KICAgY29tbXVuaXR5IGFzIGJlaW5nIGFjY2VwdGFibGUg Zm9yIHRoaXMgcHVycG9zZSBhcyB3ZWxsLiAgQXMgYWx3YXlzLA0KICAgaW1w bGVtZW50b3JzIGFuZCB1c2VycyBzaG91bGQgY2hlY2sgY3VycmVudCBsaXRl cmF0dXJlIHRvIGVuc3VyZSB0aGF0DQogICBubyByZWNlbnQgdnVsbmVyYWJp bGl0aWVzIGhhdmUgYmVlbiBmb3VuZCBpbiBjaXBoZXJzIHVzZWQgd2l0aGlu DQogICBwcm9kdWN0cy4gIEltcGxlbWVudG9ycyBzaG91bGQgYWxzbyBjaGVj ayB0byBzZWUgd2hpY2ggY2lwaGVycyBhcmUNCiAgIGNvbnNpZGVyZWQgdG8g YmUgcmVsYXRpdmVseSBzdHJvbmdlciB0aGFuIG90aGVycyBhbmQgc2hvdWxk IHJlY29tbWVuZA0KICAgdGhlaXIgdXNlIHRvIHVzZXJzIG92ZXIgcmVsYXRp dmVseSB3ZWFrZXIgY2lwaGVycy4gIEl0IHdvdWxkIGJlDQogICBjb25zaWRl cmVkIGdvb2QgZm9ybSBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gcG9saXRl bHkgYW5kDQogICB1bm9idHJ1c2l2ZWx5IG5vdGlmeSBhIHVzZXIgdGhhdCBh IHN0cm9uZ2VyIGNpcGhlciBpcyBhdmFpbGFibGUgYW5kDQogICBzaG91bGQg YmUgdXNlZCB3aGVuIGEgd2Vha2VyIG9uZSBpcyBhY3RpdmVseSBjaG9zZW4u DQoNCiAgIFRoZSAibm9uZSIgY2lwaGVyIGlzIHByb3ZpZGVkIGZvciBkZWJ1 Z2dpbmcgYW5kIFNIT1VMRCBOT1QgYmUgdXNlZA0KICAgZXhjZXB0IGZvciB0 aGF0IHB1cnBvc2UuICBJdCdzIGNyeXB0b2dyYXBoaWMgcHJvcGVydGllcyBh cmUNCiAgIHN1ZmZpY2llbnRseSBkZXNjcmliZWQgaW4gUkZDIDI0MTAsIHdo aWNoIHdpbGwgc2hvdyB0aGF0IGl0cyB1c2UgZG9lcw0KICAgbm90IG1lZXQg dGhlIGludGVudCBvZiB0aGlzIHByb3RvY29sLg0KDQogICBUaGUgcmVsYXRp dmUgbWVyaXRzIG9mIHRoZXNlIGFuZCBvdGhlciBjaXBoZXJzIG1heSBhbHNv IGJlIGZvdW5kIGluDQogICBjdXJyZW50IGxpdGVyYXR1cmUuICBUd28gcmVm ZXJlbmNlcyB0aGF0IG1heSBwcm92aWRlIGluZm9ybWF0aW9uIG9uIHRoZQ0K ICAgc3ViamVjdCBhcmUgW1NDSE5FSUVSXSBhbmQgW0tBVUZNQU4sUEVSTE1B TixTUEVDSU5FUl0uICBCb3RoIG9mIHRoZXNlDQogICBkZXNjcmliZSB0aGUg Q0JDIG1vZGUgb2Ygb3BlcmF0aW9uIG9mIGNlcnRhaW4gY2lwaGVycyBhbmQg dGhlIHdlYWtuZXNzDQogICBvZiB0aGlzIHNjaGVtZS4gIEVzc2VudGlhbGx5 LCB0aGlzIG1vZGUgaXMgdGhlb3JldGljYWxseSB2dWxuZXJhYmxlIHRvDQog ICBjaG9zZW4gY2lwaGVyLXRleHQgYXR0YWNrcyBiZWNhdXNlIG9mIHRoZSBo aWdoIHByZWRpY3RhYmlsaXR5IG9mIHRoZQ0KICAgc3RhcnQgb2YgcGFja2V0 IHNlcXVlbmNlLiAgSG93ZXZlciwgdGhpcyBhdHRhY2sgaXMgc3RpbGwgZGVl bWVkDQogICBkaWZmaWN1bHQgYW5kIG5vdCBjb25zaWRlcmVkIGZ1bGx5IHBy YWN0aWNhYmxlIGVzcGVjaWFsbHkgaWYgcmVsYXRpdmVseQ0KICAgbG9uZ2Vy IGJsb2NrIHNpemVzIGFyZSB1c2VkLg0KDQpbU0NITkVJRVJdIEFwcGxpZWQg Q3J5cHRvZ3JhcGh5LCBTZWNvbmQgRWRpdGlvbiwgQnJ1Y2UgU2NobmVpZXIs IFdpbGV5DQphbmQgU29ucyBQdWJsaXNoZXIsIDE5OTYNCg0KW0tBVUZNQU4s UEVSTE1BTixTUEVDSU5FUl0gTmV0d29yayBTZWN1cml0eTsgUFJJVkFURSBD b21tdW5pY2F0aW9uIGluDQphIFBVQkxJQyBXb3JsZCwgQ2hhcmxpZSBLYXVm bWFuLCBSYWRpYSBQZXJsbWFuLCBNaWtlIFNwZWNpbmVyLCBQcmVudGljZQ0K SGFsbCBQdWJsaXNoZXIsIDE5OTUNCg0KICAgQWRkaXRpb25hbGx5LCBhbm90 aGVyIENCQyBtb2RlIGF0dGFjayBtYXkgYmUgbWl0aWdhdGVkIHRocm91Z2gg dGhlDQogICBpbnNlcnRpb24gb2YgcGFja2V0cyBjb250YWluaW5nIFNTSF9N U0dfSUdOT1JFLiAgV2l0aG91dCB0aGlzDQogICB0ZWNobmlxdWUsIGEgc3Bl Y2lmaWMgYXR0YWNrIG1heSBiZSBzdWNjZXNzZnVsLiAgRm9yIHRoaXMgYXR0 YWNrDQogICAoY29tbW9ubHkga25vd24gYXMgdGhlIFJvZ2F3YXkgYXR0YWNr KSB0byB3b3JrLCB0aGUgYXR0YWNrZXIgd291bGQNCiAgIG5lZWQgdG8ga25v dyB0aGUgSVYgb2YgdGhlIG5leHQgYmxvY2sgdGhhdCBpcyBnb2luZyB0byBi ZSBlbmNyeXB0ZWQuDQogICBJbiBDQkMgbW9kZSB0aGF0IGlzIHRoZSBvdXRw dXQgb2YgdGhlIGVuY3J5cHRpb24gb2YgdGhlIHByZXZpb3VzDQogICBibG9j ay4gSWYgdGhlIGF0dGFja2VyIGRvZXMgbm90IGhhdmUgYW55IHdheSB0byBz ZWUgdGhlIHBhY2tldCB5ZXQNCiAgIChpLmUgaXQgaXMgaW4gdGhlIGludGVy bmFsIGJ1ZmZlcnMgb2YgdGhlIHNzaCBpbXBsZW1lbnRhdGlvbiBvciBldmVu DQogICBpbiB0aGUga2VybmVsKSB0aGVuIHRoaXMgYXR0YWNrIHdpbGwgbm90 IHdvcmsuIElmIHRoZSBsYXN0IHBhY2tldCBoYXMNCiAgIGJlZW4gc2VudCBv dXQgdG8gdGhlIG5ldHdvcmsgKGkuZSB0aGUgYXR0YWNrZXIgaGFzIGFjY2Vz cyB0byBpdCkgdGhlbg0KICAgaGUgY2FuIHVzZSB0aGUgYXR0YWNrLg0KDQog ICBJbiB0aGUgb3B0aW1hbCBjYXNlIGFuIGltcGxlbWVudG9yIHdvdWxkIG5l ZWQgdG8gYWRkIGFuIGV4dHJhIHBhY2tldA0KICAgb25seSBpZiB0aGUgcGFj a2V0IGhhcyBiZWVuIHNlbnQgb3V0IG9udG8gdGhlIG5ldHdvcmsgYW5kIHRo ZXJlIGFyZSBubw0KICAgb3RoZXIgcGFja2V0cyB3YWl0aW5nIGZvciB0cmFu c21pc3Npb24uIEltcGxlbWVudG9ycyBtYXkgd2lzaCB0byBjaGVjaw0KICAg dG8gc2VlIGlmIHRoZXJlIGFyZSBhbnkgdW5zZW50IHBhY2tldHMgYXdhaXRp bmcgdHJhbnNtaXNzaW9uLCBidXQNCiAgIHVuZm9ydHVuYXRlbHkgaXQgaXMg bm90IG5vcm1hbGx5IGVhc3kgdG8gb2J0YWluIHRoaXMgaW5mb3JtYXRpb24g ZnJvbQ0KICAgdGhlIGtlcm5lbCBvciBidWZmZXJzLiAgSWYgdGhlcmUgYXJl IG5vdCwgdGhlbiBhIHBhY2tldCBjb250YWluaW5nDQogICBTU0hfTVNHX0lH Tk9SRSBTSE9VTEQgYmUgc2VudC4gIElmIGEgbmV3IHBhY2tldCBpcyBhZGRl ZCB0byB0aGUgc3RyZWFtDQogICBldmVyeSB0aW1lIHRoZSBhdHRhY2tlciBr bm93cyB0aGUgSVYgdGhhdCBpcyBzdXBwb3NlZCB0byBiZSB1c2VkIGZvcg0K ICAgdGhlIG5leHQgcGFja2V0LCB0aGVuIHRoZSBhdHRhY2tlciB3aWxsIG5v dCBiZSBhYmxlIHRvIGd1ZXNzIHRoZQ0KICAgY29ycmVjdCBJViwgdGh1cyB0 aGUgYXR0YWNrIHdpbGwgbmV2ZXIgYmUgc3VjY2Vzc2Z1bGwuDQoNCiAgIEFz IGFuIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgY2FzZToNCg0K ICAgICAgQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTZXJ2ZXINCiAgICAgIC0tLS0tLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0t LS0tDQogICAgICBUQ1Aoc2VxPXgsIGxlbj01MDApICAgICAgICAgICAgLSZn dDsNCiAgICAgICAgIGNvbnRhaW5zIFJlY29yZCAxDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgWzUwMCBtcyBwYXNzZXMsIG5vIEFDS10NCg0KICAg ICAgVENQKHNlcT14LCBsZW49MTAwMCkgICAgICAgICAgIC0mZ3Q7DQogICAg ICAgICBjb250YWlucyBSZWNvcmRzIDEsMg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmx0Oy0gICAgICAgICAgICAgICAgICAg ICAgICBBQ0sNCg0KDQogICAgICAoMSkgVGhlIE5hZ2xlIGFsZ29yaXRobSAr IFRDUCByZXRyYW5zbWl0cyBtZWFuIHRoYXQgdGhlIHR3bw0KICAgICAgICAg IHJlY29yZHMgZ2V0IGNvYWxlc2NlZCBpbnRvIGEgc2luZ2xlIFRDUCBzZWdt ZW50DQogICAgICAoMikgUmVjb3JkIDIgaXMgKm5vdCogYXQgdGhlIGJlZ2lu bmluZyBvZiB0aGUgVENQIHNlZ21lbnQNCiAgICAgICAgICBhbmQgbmV2ZXIg d2lsbCBiZSwgc2luY2UgaXQgZ2V0cyBBQ0tlZC4NCiAgICAgICgzKSBZZXQs IHRoZSBhdHRhY2sgaXMgcG9zc2libGUgYmVjYXVzZSBSZWNvcmQgMSBoYXMg YWxyZWFkeQ0KICAgICAgICAgIGJlZW4gc2Vlbi4NCg0KICAgQXMgdGhpcyBl eGFtcGxlIGluZGljYXRlcywgaXQncyB0b3RhbGx5IHVuc2FmZSB0byB1c2Ug dGhlIGV4aXN0ZW5jZQ0KICAgb2YgdW5mbHVzaGVkIGRhdGEgaW4gdGhlIFRD UCBidWZmZXJzIHByb3BlciBhcyBhIGd1aWRlIHRvIHdoZXRoZXINCiAgIHlv dSBuZWVkIGFuIGVtcHR5IHBhY2tldCwgc2luY2Ugd2hlbiB5b3UgZG8gdGhl IHNlY29uZCB3cml0ZSgpLA0KICAgdGhlIGJ1ZmZlcnMgd2lsbCBjb250YWlu IHRoZSB1bi1BQ0tlZCBSZWNvcmQgMS4NCg0KICAgT24gdGhlIG90aGVyIGhh bmQsIGl0J3MgcGVyZmVjdGx5IHNhZmUgdG8gaGF2ZSB0aGUgZm9sbG93aW5n DQogICBzaXR1YXRpb246DQoNCiAgICAgIENsaWVudCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyDQog ICAgICAtLS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLS0tLQ0KICAgICAgVENQKHNlcT14LCBsZW49 NTAwKSAgICAgICAgICAgLSZndDsNCiAgICAgICAgIGNvbnRhaW5zIFNTSF9N U0dfSUdOT1JFDQoNCiAgICAgIFRDUChzZXE9eSwgbGVuPTUwMCkgICAgICAg ICAgIC0mZ3Q7DQogICAgICAgICBjb250YWlucyBEYXRhDQoNCiAgIFByb3Zp ZGVkIHRoYXQgdGhlIElWIGZvciBzZWNvbmQgU1NIIFJlY29yZCBpcyBmaXhl ZCBhZnRlciB0aGUgZGF0YSBmb3INCiAgIHRoZSBEYXRhIHBhY2tldCBpcyBk ZXRlcm1pbmVkIC1pLmUuIHlvdSBkbzoNCiAgICAgICAgcmVhZCBmcm9tIHVz ZXINCiAgICAgICAgZW5jcnlwdCBudWxsIHBhY2tldA0KICAgICAgICBlbmNy eXB0IGRhdGEgcGFja2V0DQoNCg0KMTEuMS4yIERhdGEgSW50ZWdyaXR5DQoN CiAgIFRoaXMgcHJvdG9jb2wgZG9lcyBhbGxvdyB0aGUgRGF0YSBJbnRlZ3Jp dHkgbWVjaGFuaXNtIHRvDQogICBiZSBkaXNhYmxlZC4gIEltcGxlbWVudG9y cyBTSE9VTEQgYmUgd2FyeSBvZiBleHBvc2luZyB0aGlzDQogICBmZWF0dXJl IGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGRlYnVnZ2luZy4gIFVzZXJz IGFuZA0KICAgYWRtaW5pc3RyYXRvcnMgU0hPVUxEIGJlIGV4cGxpY2l0bHkg d2FybmVkIGFueXRpbWUgdGhlDQogICAibm9uZSIgbWFjIGlzIGVuYWJsZWQu DQoNCiAgIFNvIGxvbmcgYXMgdGhlICJub25lIiBtYWMgaXMgbm90IHVzZWQs IHRoaXMgcHJvdG9jb2wNCiAgIHByb3ZpZGVzIGRhdGEgaW50ZWdyaXR5Lg0K DQogICBCZWNhdXNlIE1BQ3MgdXNlIGEgMzIgYml0IHNlcXVlbmNlIG51bWJl ciwgdGhleSBtaWdodA0KICAgc3RhcnQgdG8gbGVhayBpbmZvcm1hdGlvbiBh ZnRlciAyKiozMiBwYWNrZXRzIGhhdmUNCiAgIGJlZW4gc2VudC4gIEhvd2V2 ZXIsIGZvbGxvd2luZyB0aGUgcmVrZXlpbmcNCiAgIHJlY29tbWVuZGF0aW9u cyBzaG91bGQgcHJldmVudCB0aGlzIGF0dGFjay4NCiAgIFRoZSB0cmFuc3Bv cnQgcHJvdG9jb2wgWzFdIHJlY29tbWVuZHMgcmVrZXlpbmcgYWZ0ZXINCiAg IG9uZSBnaWdhYnl0ZSBvZiBkYXRhLCBhbmQgdGhlIHNtYWxsZXN0IHBvc3Np YmxlDQogICBwYWNrZXQgaXMgMTYgYnl0ZXMuIFRoZXJlZm9yZSwgcmVrZXlp bmcgU0hPVUxEIGhhcHBlbg0KICAgYWZ0ZXIgMioqMjggcGFja2V0cyBhdCB0 aGUgdmVyeSBtb3N0Lg0KDQoxMS4xLjMgUmVwbGF5DQoNCiAgIFRoaXMgcHJv dG9jb2wgYmluZHMgZWFjaCBzZXNzaW9uIGtleSB0byB0aGUgc2Vzc2lvbiBi eSBpbmNsdWRpbmcNCiAgIHJhbmRvbSBkYXRhIHRoYXQgaXMgc3BlY2lmaWMg dG8gdGhlIHNlc3Npb24gaW4gdGhlIGhhc2ggdXNlZCB0bw0KICAgcHJvZHVj ZSBzZXNzaW9uIGtleXMuDQoNCiAgIDxzdHJpa2U+PGZvbnQgY29sb3I9cmVk PlRoaXM8L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPWdy ZWVuPklmIHRoZSByYW5kb20gZGF0YSBoZXJlIChlLmcuLCBESCBwYXJhbWV0 ZXJzKQ0KICAgYXJlIHBzZXVkby1yYW5kb20gdGhlbiB0aGUgUFJORyBzaG91 bGQgYmUgY3J5cHRvZ3JhcGhpY2FsbHkgc2VjdXJlDQogICAoaS5lLiwgaXRz IG5leHQgb3V0cHV0IG5vdCBlYXNpbHkgZ3Vlc3NlZCwgZXZlbiB3aGVuIGtu b3dpbmcgYWxsDQogICBwcmV2aW91cyBvdXRwdXRzKSBhbmQsIGZ1cnRoZXJt b3JlLCB0aGUgUFJORyBzaG91bGQgYmUgc2VlZGVkIHdpdGggc29tZQ0KICAg dHJ1bHkgcmFuZG9tIGlucHV0cywgb3IgYXMgcmFuZG9tIGFzIGNhbiBiZSBh dmFpbGFibGUuICBJbiBhbnkgY2FzZSwNCiAgIHRoZSBhbW91bnQgb2YgZW50 cm9weSBhdmFpbGFibGUgdG8gYSBnaXZlbiBjbGllbnQgb3Igc2VydmVyIHNv bWV0aW1lcw0KICAgbWF5IGJlIGxlc3MgdGhhbiB3aGF0IGlzIG5lZWRlZCB0 byBydW4gdGhlIHByb3RvY29sLCBpbiB3aGljaCBjYXNlDQogICBlaXRoZXIg b25lIG11c3QgcmVzb3J0IHRvIFBSTkdzIGFueXdheXMgb3IgcmVmdXNlIHRv IHJ1biB0aGUgcHJvdG9jb2wuDQogICBJbiBwcmFjdGljZSBpbXBsZW1lbnRv cnMgd2lsbCBnZW5lcmFsbHkgcmVseSBvbiBzb21lIFBSTkcuICBSRkMgMTc1 MA0KICAgWzE3NTBdIGNvbnRhaW5zIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGlz Lg0KDQpbMTc1MF0gRWFzdGxha2UsIEQuLCBDcm9ja2VyLCBTLiBhbmQgSi4g U2NoaWxsZXIsICJSYW5kb21uZXNzDQogICAgICAgUmVjb21tZW5kYXRpb25z IGZvciBTZWN1cml0eSIsIFJGQyAxNzUwLCBEZWNlbWJlciAxOTk0Lg0KDQoN CiAgIFRoZSB1c2Ugb2YgYSBNQUMgb3RoZXIgdGhhbiAnbm9uZScgcHJvdmlk ZXMgaW50ZWdyaXR5IGFuZA0KICAgYXV0aGVudGljYXRpb24uICBJbiBhZGRp dGlvbiwgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBwcm92aWRlcyBhIHVuaXF1 ZTwvZm9udD48L3N0cm9uZz4NCiAgIHNlc3Npb24gPHN0cmlrZT48Zm9udCBj b2xvcj1yZWQ+aWQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9Z3JlZW4+aWRlbnRpZmllciAoYm91bmQgaW4gcGFydCB0byBwc2V1ZG8t cmFuZG9tIGRhdGEgdGhhdDwvZm9udD48L3N0cm9uZz4gaXMgPHN0cm9uZz48 Zm9udCBjb2xvcj1ncmVlbj5wYXJ0DQogICBvZiB0aGUgYWxnb3JpdGhtIGFu ZCBrZXkgZXhjaGFuZ2UgcHJvY2VzcykgdGhhdCBjYW4gYmU8L2ZvbnQ+PC9z dHJvbmc+IHVzZWQgYnkgaGlnaGVyDQogICBsZXZlbCBwcm90b2NvbHMgdG8g PHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5iaW5kIGRhdGEgdG8gYSBnaXZl biBzZXNzaW9uIGFuZDwvZm9udD48L3N0cm9uZz4gcHJldmVudCByZXBsYXkg b2YgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+cGFja2V0cyBmb3JtPC9mb250 Pjwvc3RyaWtlPg0KICAgPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5kYXRh IGZyb20gcHJpb3Igc2Vzc2lvbnMuIEZvciBleGFtcGxlLCB0aGUgYXV0aGVu dGljYXRpb24gcHJvdG9jb2wgdXNlcw0KICAgdGhpcyB0byBwcmV2ZW50IHJl cGxheSBvZiBzaWduYXR1cmVzIGZyb208L2ZvbnQ+PC9zdHJvbmc+IHByZXZp b3VzIHNlc3Npb25zLg0KDQogICA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD5J biBhZGRpdGlvbiw8L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNv bG9yPWdyZWVuPkJlY2F1c2UgDQogICBwdWJsaWMga2V5IGF1dGhlbnRpY2F0 aW9uIGV4Y2hhbmdlcyBhcmUgY3J5cHRvZ3JhcGhpY2FsbHkgYm91bmQgdG88 L2ZvbnQ+PC9zdHJvbmc+IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD51 c2U8L2ZvbnQ+PC9zdHJpa2U+IA0KICAgPHN0cm9uZz48Zm9udCBjb2xvcj1n cmVlbj5zZXNzaW9uIChpLmUuLCB0byB0aGUgaW5pdGlhbCBrZXkgZXhjaGFu Z2UpIHRoZXkgY2Fubm90IGJlIHN1Y2Nlc3NmdWxseSANCiAgIHJlcGxheWVk IGluIG90aGVyIHNlc3Npb25zLiAgTm90ZSB0aGF0IHRoZSBzZXNzaW9uIElE IGNhbiBiZSBtYWRlIA0KICAgcHVibGljIHdpdGhvdXQgaGFybWluZyB0aGUg c2VjdXJpdHk8L2ZvbnQ+PC9zdHJvbmc+IG9mIDxzdHJpa2U+PGZvbnQgY29s b3I9cmVkPmNpcGhlciBjaGFpbmluZyBwcmV2ZW50cw0KICAgcmVwbGF5PC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPnRoZSBw cm90b2NvbC4NCg0KICAgSWYgdHdvIHNlc3Npb24gaGFwcGVuIHRvIGhhdmUg dGhlIHNhbWUgc2Vzc2lvbiBJRCBbaGFzaDwvZm9udD48L3N0cm9uZz4gb2Yg PHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5rZXkNCiAgIGV4Y2hhbmdlc10g dGhlbjwvZm9udD48L3N0cm9uZz4gcGFja2V0cyA8c3RyaWtlPjxmb250IGNv bG9yPXJlZD53aXRoaW48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQg Y29sb3I9Z3JlZW4+ZnJvbSBvbmUgY2FuIGJlIHJlcGxheWVkIGFnYWluc3Q8 L2ZvbnQ+PC9zdHJvbmc+IHRoZSA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD5z ZXNzaW9uLiAgQ2lwaGVyIGNoYWluaW5nDQogICBhbHNvIHByZXZlbnRzPC9m b250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPm90aGVy LiAgSXQNCiAgIG11c3QgYmUgc3RyZXNzZWQgdGhhdDwvZm9udD48L3N0cm9u Zz4gdGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPmluc2VydGlvbiBvciBk ZWxldGlvbjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj1n cmVlbj5jaGFuY2VzPC9mb250Pjwvc3Ryb25nPiBvZiA8c3RyaWtlPjxmb250 IGNvbG9yPXJlZD5wYWNrZXRzLjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj1ncmVlbj5zdWNoIGFuIG9jY3VycmVuY2UgYXJlLCBuZWVk bGVzcyANCiAgIHRvIHNheSwgbWluaW1hbCB3aGVuIHVzaW5nIG1vZGVybiBj cnlwdG9ncmFwaGljIG1ldGhvZHMuICBUaGlzIGlzIGFsbA0KICAgdGhlIG1v cmUgc28gdHJ1ZSB3aGVuIHNwZWNpZnlpbmcgbGFyZ2VyIGhhc2ggZnVuY3Rp b24gb3V0cHV0cyBhbmQgREggDQogICBwYXJhbWV0ZXJzLg0KDQpbUkpBOiAg SSBpbWFnaW5lIHRoYXQgYSBzZXF1ZW5jZSBudW1iZXIgZG9lcyBoZWxwIHBy ZWNsdWRlIHJlcGxheSBhdHRhY2tzLA0KW1JKQTogIGJ1dCBJIHdhcyBob3Bp bmcgdGhhdCBzb21lb25lIGVsc2UgaGFkIGFjdHVhbGx5IGRvbmUgc29tZSBh bmFseXNpcw0KW1JKQTogIHRoYXQgd2UgY291bGQgY2l0ZSB0byBqdXN0aWZ5 IHRoZSBjbGFpbSB0aGF0IHRoaXMgTUFDIGNvbWJpbmVkIHdpdGgNCltSSkE6 ICB0aGlzIGtpbmQgb2Ygc2VxdWVuY2UgbnVtYmVyaW5nIHdvdWxkIGFjdHVh bGx5IHByb3ZpZGUgcmVwbGF5DQpbUkpBOiAgYXR0YWNrIHByZXZlbnRpb24u PC9mb250Pjwvc3Ryb25nPg0KDQoNCjExLjEuNCBNYW4taW4tdGhlLW1pZGRs ZQ0KDQogICBUaGlzIHByb3RvY29sIG1ha2VzIG5vIGFzc3VtcHRpb25zIG5v ciBwcm92aXNpb25zIGZvcg0KICAgYW4gaW5mcmFzdHJ1Y3R1cmUgZm9yIGRp c3RyaWJ1dGluZyBwdWJsaWMga2V5cy4gIEl0IGlzDQogICBleHBlY3RlZCB0 aGF0IHRoaXMgcHJvdG9jb2wgd2lsbCBzb21ldGltZXMgYmUgdXNlZCB3aXRo b3V0DQogICBpbnNpc3Rpbmcgb24gcmVsaWFibGUgYXNzb2NpYXRpb24gYmV0 d2VlbiB0aGUgc2VydmVyIGhvc3QNCiAgIGtleSBhbmQgdGhlIHNlcnZlciBo b3N0IG5hbWUuICBTdWNoIHVzYWdlIGlzIHZ1bG5lcmFibGUNCiAgIHRvIG1h bi1pbi10aGUtbWlkZGxlIGF0dGFja3MuDQoNCiAgIFRoaXMgdnVsbmVyYWJp bGl0eSB0byBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tzIGNhbg0KICAgYmUg bWl0aWdhdGVkIGluIHNldmVyYWwgZmFzaGlvbnM6DQoNCiAgIDEuIE5hcnJv dyB0aGUgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+d2luZG93LjwvZm9udD48 L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj53aW5kb3cgZHVy aW5nIHdoaWNoIHRoZSBjbGllbnQgaXMgdnVsbmVyYWJsZSB0byBzdWNoIGEN CiAgICAgIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFjay48L2ZvbnQ+PC9zdHJv bmc+ICBJZiB0aGUgY2xpZW50IGVuc3VyZXMgdGhhdCB0aGUgaG9zdCBrZXkN CiAgICAgIGZvciBhIGdpdmVuIHNlcnZlciByZW1haW5zIGNvbnNpc3RhbnQs IGFuIGF0dGFja2VyIG11c3QgZXhlY3V0ZSB0aGUNCiAgICAgIG1hbi1pbi10 aGUtbWlkZGxlIGF0dGFjayBvbiB0aGUgX2ZpcnN0XyBjb25uZWN0aW9uIHRv IGEgZ2l2ZW4NCiAgICAgIHNlcnZlci4NCg0KICAgMi4gVXNlIGFuIGF1dGhl bnRpY2F0aW9uIG1ldGhvZCB0aGF0IGlzIG5vdCB2dWxuZXJhYmxlIHRvIDxz dHJpa2U+PGZvbnQgY29sb3I9cmVkPm1hbi1pbi10aGUtbWlkZGxlLjwvZm9u dD48L3N0cmlrZT4NCiAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+ bWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcy48L2ZvbnQ+PC9zdHJvbmc+ICBG b3IgZXhhbXBsZSwgcHVibGljLWtleSBhdXRoZW50aWNhdGlvbg0KICAgICAg aXMgbm90IHZ1bG5lcmFibGUgdG8gbWFuLWluLXRoZS1taWRkbGUNCiAgICAg IDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPmF0dGFjayw8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+YXR0YWNrIGFzIGxvbmcg YXMgdGhlDQogICAgICBwdWJsaWMta2V5IG9mIHRoZSBzZXJ2ZXIgaGFzIGJl ZW4gc2VjdXJlbHkgZGlzdHJpYnV0ZWQgdG8gdGhlDQogICAgICBjbGllbnRz IGJlZm9yZSB0aGUgZmlyc3QgU1NIIGNvbm5lY3Rpb24gaXMgbWFkZS4gIFRo aXMgaXM8L2ZvbnQ+PC9zdHJvbmc+IGJlY2F1c2UNCiAgICAgIHRoZSBzaWdu YXR1cmUgaXMgbWFkZSBhY3Jvc3MgZGF0YSB0aGF0IGlzIHNlc3Npb24gc3Bl Y2lmaWMuICBUaGUgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+YXR0YWNrIGNh biBub3QgdXNlDQogICAgICB0aGUgc2lnbmF0dXJlIGhlIHJlY2VpdmVzIGJl Y2F1c2UgdGhlPC9mb250Pjwvc3RyaWtlPg0KICAgICAgc2Vzc2lvbiBzcGVj aWZpYyBkYXRhIGJldHdlZW4gdGhlIGF0dGFja2VyIGFuZCBzZXJ2ZXIgPHN0 cmlrZT48Zm9udCBjb2xvcj1yZWQ+aXMgZGlmZmVyZW50LDwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj53aWxsIGJlDQogICAg ICBkaWZmZXJlbnQgYmV0d2VlbiB0aGUgY2xpZW50LXRvLWF0dGFja2VyIHNl c3Npb248L2ZvbnQ+PC9zdHJvbmc+IGFuZA0KICAgICAgPHN0cmlrZT48Zm9u dCBjb2xvcj1yZWQ+Y2FuPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPWdyZWVuPnRoZQ0KICAgICAgYXR0YWNrZXItdG8tc2VydmVyIHNl c3Npb25zIGR1ZSB0byB0aGUgcmFuZG9tbmVzcyBkaXNjdXNzZWQgYWJvdmUu DQogICAgICBGcm9tIHRoaXMsIHRoZSBhdHRhY2tlciB3aWxsPC9mb250Pjwv c3Ryb25nPiBub3QgPHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+Y3JlYXRlIGEg dmFsaWQgc2lnbmF0dXJlIGJlY2F1c2U8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJv bmc+PGZvbnQgY29sb3I9Z3JlZW4+YmUgYWJsZSB0byBtYWtlIHRoaXMgYXR0 YWNrIHdvcmsNCiAgICAgIHNpbmNlIHRoZSBhdHRhY2tlciB3aWxsIG5vdCBi ZSBhYmxlIHRvIGNvcnJlY3RseSBzaWduIHBhY2tldHMNCiAgICAgIGNvbnRh aW5pbmcgdGhpcyBzZXNzaW9uIHNwZWNpZmljIGRhdGEgZnJvbSB0aGUgc2Vy dmVyIHNpbmNlPC9mb250Pjwvc3Ryb25nPiBoZSBkb2VzDQogICAgICBub3Qg aGF2ZSB0aGUgcHJpdmF0ZSA8c3RyaWtlPjxmb250IGNvbG9yPXJlZD5rZXku DQoNCiAgIEhvd2V2ZXIsIHRoaXMgZG9lcyBhc3N1bWU8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+a2V5IG9mPC9mb250Pjwv c3Ryb25nPiB0aGF0IDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPnRoZSBwdWJs aWMta2V5IGhhcw0KICAgYmVlbiBkaXN0cmlidXRlZCB0byB0aGUgc2VydmVy IGhvc3QgaW4gc29tZSBzZWN1cmUNCiAgIGZhc2hpb24gYmVmb3JlIHRoZSBm aXJzdCBTU0ggY29ubmVjdGlvbiBjYW4gYmUgbWFkZS48L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+c2VydmVyLg0KDQpbUkpB OiAgSXMgdGhpcyByZWFsbHkgdHJ1ZSBhbmQgc3VmZmljaWVudCA/PC9mb250 Pjwvc3Ryb25nPg0KDQogICAzLiBCZWNhdXNlIHRoZSBwcm90b2NvbCBpcyBl eHRlbnNpYmxlLCBmdXR1cmUgZXh0ZW5zaW9ucw0KICAgICAgdG8gdGhlIHBy b3RvY29sIG1heSBwcm92aWRlIGJldHRlciBtZWNoYW5pc21zIGZvciBkZWFs aW5nDQogICAgICB3aXRoIHRoZSBuZWVkIHRvIGtub3cgdGhlIHNlcnZlcidz IGhvc3Qga2V5IGJlZm9yZQ0KICAgICAgY29ubmVjdGluZy4gIEZvciBleGFt cGxlLCBzdG9yaW5nIHRoZSBob3N0a2V5IGZpbmdlcnByaW50DQogICAgICBp biBhIHNlY3VyZSBkbnMgZGF0YWJhc2UsIG9yIHVzaW5nIGtlcmJlcm9zIG92 ZXIgZ3NzYXBpDQogICAgICBkdXJpbmcga2V5ZXhjaGFuZ2UgdG8gYXV0aGVu dGljYXRlIHRoZSBzZXJ2ZXIuDQoNCiAgIFNlcnZlciBhZG1pbmlzdHJhdG9y cyBhcmUgZW5jb3VyYWdlZCB0byBtYWtlIGhvc3Qga2V5DQogICBmaW5nZXJw cmludHMgYXZhaWxhYmxlIGZvciBjaGVja2luZyBieSBzb21lIG1lYW5zIHdo b3NlDQogICBzZWN1cml0eSBkb2VzIG5vdCByZWx5IG9uIHRoZSBpbnRlZ3Jp dHkgb2YgdGhlIGFjdHVhbCBob3N0DQogICBrZXlzLiAgUG9zc2libGUgbWVj aGFuaXNtcyBpbmNsdWRlIHNlY3VyZWQgV2ViIHBhZ2VzLCB0aGUgRE5TDQog ICBbZHJhZnQtaWV0Zi1zZWNzaC1kbnNdLCBwaHlzaWNhbCBwaWVjZXMgb2Yg cGFwZXIsIGV0Yy4NCiAgIEltcGxlbWVudG9ycyBTSE9VTEQgcHJvdmlkZSBy ZWNvbW1lbmRhdGlvbnMgb24gaG93IGJlc3QgdG8gZG8NCiAgIHRoaXMgd2l0 aCB0aGVpciBpbXBsZW1lbnRhdGlvbi4NCg0KICAgVXNlIG9mIHRoaXMgcHJv dG9jb2wgd2l0aG91dCA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPmE8L2Zv bnQ+PC9zdHJvbmc+IHJlbGlhYmxlIGFzc29jaWF0aW9uIDxzdHJvbmc+PGZv bnQgY29sb3I9Z3JlZW4+b2YgdGhlIGJpbmRpbmcNCiAgIGJldHdlZW4gYSBo b3N0IGFuZCBpdHMgaG9zdCBrZXlzPC9mb250Pjwvc3Ryb25nPiBpcyBpbmhl cmVudGx5IDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPmluc2VjdXJlLCBidXQ8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+aW5z ZWN1cmUgYW5kIGlzIE5PVA0KICAgUkVDT01NRU5ERUQuICBJdDwvZm9udD48 L3N0cm9uZz4gbWF5IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+aG93ZXZl cjwvZm9udD48L3N0cm9uZz4gYmUgbmVjZXNzYXJ5IGluIG5vbi1zZWN1cml0 eSBjcml0aWNhbA0KICAgZW52aXJvbm1lbnRzLCBhbmQgPHN0cm9uZz48Zm9u dCBjb2xvcj1ncmVlbj53aWxsPC9mb250Pjwvc3Ryb25nPiBzdGlsbA0KICAg PHN0cmlrZT48Zm9udCBjb2xvcj1yZWQ+cHJvdmlkZXM8L2ZvbnQ+PC9zdHJp a2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+cHJvdmlkZTwvZm9udD48 L3N0cm9uZz4gcHJvdGVjdGlvbiBhZ2FpbnN0IHBhc3NpdmUgPHN0cmlrZT48 Zm9udCBjb2xvcj1yZWQ+YXR0YWNrcy4gIEhvd2V2ZXIsDQogICBpbXBsZW1l bnRvcnM8L2ZvbnQ+PC9zdHJpa2U+DQogICA8c3Ryb25nPjxmb250IGNvbG9y PWdyZWVuPmF0dGFja3MuICBJbXBsZW1lbnRvcnM8L2ZvbnQ+PC9zdHJvbmc+ IG9mIHByb3RvY29scyA8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPmFuZCBh cHBsaWNhdGlvbnM8L2ZvbnQ+PC9zdHJvbmc+IHJ1bm5pbmcgb24gdG9wIG9m DQogICB0aGlzIHByb3RvY29sIHNob3VsZCBrZWVwIHRoaXMgcG9zc2liaWxp dHkgaW4gbWluZC4NCg0KMTEuMS41IERlbmlhbC1vZi1zZXJ2aWNlDQoNCiAg IFRoaXMgcHJvdG9jb2wgaXMgZGVzaWduZWQgdG8gYmUgdXNlZCBvdmVyIGEg cmVsaWFibGUgdHJhbnNwb3J0LiAgSWYNCiAgIHRyYW5zbWlzc2lvbiBlcnJv cnMgb3IgbWVzc2FnZSBtYW5pcHVsYXRpb24gb2NjdXIsIHRoZSBjb25uZWN0 aW9uIGlzDQogICBjbG9zZWQuICBUaGUgY29ubmVjdGlvbiBTSE9VTEQgYmUg cmUtZXN0YWJsaXNoZWQgaWYgdGhpcyBvY2N1cnMuDQogICBEZW5pYWwgb2Yg c2VydmljZSBhdHRhY2tzIG9mIHRoaXMgdHlwZSAoIndpcmUgY3V0dGVyIikg YXJlIGFsbW9zdA0KICAgaW1wb3NzaWJsZSB0byBhdm9pZC4NCg0KICAgSW4g YWRkaXRpb24sIHRoaXMgcHJvdG9jb2wgaXMgdnVsbmVyYWJsZSB0byBEZW5p YWwgb2YgU2VydmljZQ0KICAgYXR0YWNrcyBiZWNhdXNlIGFuIGF0dGFja2Vy IGNhbiBmb3JjZSB0aGUgc2VydmVyIHRvIGdvIHRocm91Z2gNCiAgIHRoZSBD UFUgYW5kIG1lbW9yeSBpbnRlbnNpdmUgdGFza3Mgb2YgY29ubmVjdGlvbiBz ZXR1cCBhbmQNCiAgIGtleSBleGNoYW5nZSB3aXRob3V0IGF1dGhlbnRpY2F0 aW5nLiAgSW1wbGVtZW50b3JzIFNIT1VMRCBwcm92aWRlDQogICBmZWF0dXJl cyB0aGF0IG1ha2UgdGhpcyBtb3JlIGRpZmZpY3VsdC4gIEZvciBleGFtcGxl LCBvbmx5IGFsbG93aW5nDQogICBjb25uZWN0aW9ucyBmcm9tIGEgc3Vic2V0 IG9mIElQcyBrbm93biB0byBoYXZlIHZhbGlkIHVzZXJzLg0KDQoxMS4xLjYg Q292ZXJ0IENoYW5uZWxzDQoNCiAgIFRoZSBwcm90b2NvbCB3YXMgbm90IGRl c2lnbmVkIHRvIGVsaW1pbmF0ZSBjb3ZlcnQgY2hhbm5lbHMuICBGb3INCiAg IGV4YW1wbGUsIHRoZSBwYWRkaW5nLCBTU0hfTVNHX0lHTk9SRSBtZXNzYWdl cywgYW5kIHNldmVyYWwgb3RoZXINCiAgIHBsYWNlcyBpbiB0aGUgcHJvdG9j b2wgY2FuIGJlIHVzZWQgdG8gcGFzcyBjb3ZlcnQgaW5mb3JtYXRpb24sIGFu ZA0KICAgdGhlIHJlY2lwaWVudCBoYXMgbm8gcmVsaWFibGUgd2F5IHRvIHZl cmlmeSB3aGV0aGVyIHN1Y2ggaW5mb3JtYXRpb24NCiAgIGlzIGJlaW5nIHNl bnQuDQogICANCjxzdHJvbmc+PGZvbnQgY29sb3I9Z3JlZW4+MTEuMS43ICBG b3J3YXJkIFNlY3JlY3kNCg0KICAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQg dGhlIERpZmZpZS1IZWxsbWFuIGtleSBleGNoYW5nZXMgbWF5IHByb3ZpZGUN CiAgIHBlcmZlY3QgZm9yd2FyZCBzZWNyZWN5IChQRlMpLiAgUEZTIGlzIGVz c2VudGlhbGx5IGRlZmluZWQgYXMgdGhlDQogICBjcnlwdG9ncmFwaGljIHBy b3BlcnR5IG9mIGEga2V5LWVzdGFibGlzaG1lbnQgcHJvdG9jb2wgaW4gd2hp Y2ggdGhlDQogICBjb21wcm9taXNlIG9mIGEgc2Vzc2lvbiBrZXkgb3IgbG9u Zy10ZXJtIHByaXZhdGUga2V5IGFmdGVyIGEgZ2l2ZW4NCiAgIHNlc3Npb24g ZG9lcyBub3QgY2F1c2UgdGhlIGNvbXByb21pc2Ugb2YgYW55IGVhcmxpZXIg c2Vzc2lvbi4NCiAgIFtBTlNJIFQxLjUyMy0yMDAxXSAgU1NIdjIgc2Vzc2lv bnMgcmVzdWx0aW5nIGZyb20gYSBrZXkgZXhjaGFuZ2UgdXNpbmcNCiAgIGRp ZmZpZS1oZWxsbWFuLWdyb3VwMS1zaGExIGFyZSBzZWN1cmUgZXZlbiBpZiBw cml2YXRlDQogICBrZXlpbmcvYXV0aGVudGljYXRpb24gbWF0ZXJpYWwgaXMg bGF0ZXIgcmV2ZWFsZWQsIGJ1dCBub3QgaWYgdGhlDQogICBzZXNzaW9uIGtl eXMgYXJlIHJldmVhbGVkLiBTbywgZ2l2ZW4gdGhpcyBkZWZpbml0aW9uIG9m IFBGUywgU1NIdjINCiAgIGRvZXMgaGF2ZSBQRlMuICBJdCBpcyBob3BlZCB0 aGF0IGFsbCBvdGhlciBrZXkgZXhjaGFuZ2UgbWVjaGFuaXNtcw0KICAgcHJv cG9zZWQgYW5kIHVzZWQgaW4gdGhlIGZ1dHVyZSB3aWxsIGFsc28gcHJvdmlk ZSBQRlMuICBUaGlzIHByb3BlcnR5DQogICBpcyBub3QgY29tbXV0ZWQgdG8g YW55IG9mIHRoZSBhcHBsaWNhdGlvbnMgb3IgcHJvdG9jb2xzIHVzaW5nIFNT SCBhcyBhDQogICB0cmFuc3BvcnQgaG93ZXZlci4gIFRoZSB0cmFuc3BvcnQg bGF5ZXIgb2YgU1NIIHByb3ZpZGVzDQogICBjb25maWRlbnRpYWxpdHkgZm9y IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIGFuZCBvdGhlciBtZXRob2RzIHRo YXQNCiAgIHJlbHkgb24gc2VjcmV0IGRhdGEuDQogICANCiAgIE9mIGNvdXJz ZSwgaWYgdGhlIERIIHByaXZhdGUgcGFyYW1ldGVycyBmb3IgdGhlIGNsaWVu dCBhbmQgc2VydmVyIGFuZCANCiAgIHJldmVhbGVkIHRoZW4gdGhlIHNlc3Np b24ga2V5IGlzIHJldmVhbGVkLCBidXQgdGhlc2UgaXRlbXMgY2FuIGJlIA0K ICAgdGhyb3duIGF3YXkgYWZ0ZXIgdGhlIGtleSBleGNoYW5nZSBjb21wbGV0 ZXMuICBJdCdzIHdvcnRoIHBvaW50aW5nIG91dCANCiAgIHRoYXQgdGhlc2Ug aXRlbXMgc2hvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIGVuZCB1cCBvbiBzd2Fw IHNwYWNlIGFuZCANCiAgIHRoYXQgdGhleSBzaG91bGQgYmUgZXJhc2VkIGZy b20gbWVtb3J5IGFzIHNvb24gYXMgdGhlIGtleSBleGNoYW5nZSANCiAgIGNv bXBsZXRlcy4NCg0KDQpbQU5TSSBUMS41MjMtMjAwMV0gQW1lcmljYW4gTmF0 aW9uYWwgU3RhbmRhcmQgVDEuNTIzLTIwMDEsICJUZWxlY29tDQpHbG9zc2Fy eSAyMDAwIiwgQW1lcmljYW4gTmF0aW9uYWwgU3RhbmRhcmRzIEluc3RpdHV0 ZSwgSW5jLiwgQXBwcm92ZWQNCkZlYnJ1YXJ5IDI4LCAyMDAxLjwvZm9udD48 L3N0cm9uZz4NCg0KDQoxMS4yIEF1dGhlbnRpY2F0aW9uIFByb3RvY29sDQoN CiAgIFRoZSBwdXJwb3NlIG9mIHRoaXMgcHJvdG9jb2wgaXMgdG8gcGVyZm9y bSBjbGllbnQgdXNlcg0KICAgYXV0aGVudGljYXRpb24uICBJdCBhc3N1bWVk IHRoYXQgdGhpcyBydW5zIG92ZXIgYSBzZWN1cmUgdHJhbnNwb3J0DQogICBs YXllciBwcm90b2NvbCwgd2hpY2ggaGFzIGFscmVhZHkgYXV0aGVudGljYXRl ZCB0aGUgc2VydmVyIG1hY2hpbmUsDQogICBlc3RhYmxpc2hlZCBhbiBlbmNy eXB0ZWQgY29tbXVuaWNhdGlvbnMgY2hhbm5lbCwgYW5kIGNvbXB1dGVkIGEN CiAgIHVuaXF1ZSBzZXNzaW9uIGlkZW50aWZpZXIgZm9yIHRoaXMgc2Vzc2lv bi4NCg0KICAgVGhlIDxzdHJpa2U+PGZvbnQgY29sb3I9cmVkPnRyYW5zcG9y dCBsYXllcg0KICAgcHJvdmlkZXMgZm9yd2FyZCBzZWNyZWN5IGZvciBwYXNz d29yZCBhdXRoZW50aWNhdGlvbiBhbmQgb3RoZXINCiAgIG1ldGhvZHMgdGhh dCByZWx5IG9uIHNlY3JldCBkYXRhLg0KDQogICBUaGU8L2ZvbnQ+PC9zdHJp a2U+IHNlcnZlciBtYXkgZ28gaW50byBhICJzbGVlcCIgcGVyaW9kIGFmdGVy IHJlcGVhdGVkIHVuc3VjY2Vzc2Z1bA0KICAgYXV0aGVudGljYXRpb25zIHRv IG1ha2Uga2V5IHNlYXJjaCBoYXJkZXIuDQoNCiAgIFNldmVyYWwgYXV0aGVu dGljYXRpb24gbWV0aG9kcyB3aXRoIGRpZmZlcmVudCBzZWN1cml0eQ0KICAg Y2hhcmFjdGVyaXN0aWNzIGFyZSBhbGxvd2VkLiAgSXQgaXMgdXAgdG8gdGhl IHNlcnZlcidzIGxvY2FsIHBvbGljeQ0KICAgdG8gZGVjaWRlIHdoaWNoIG1l dGhvZHMgKG9yIGNvbWJpbmF0aW9ucyBvZiBtZXRob2RzKSBpdCBpcyB3aWxs aW5nIHRvDQogICBhY2NlcHQgZm9yIGVhY2ggdXNlci4gIEF1dGhlbnRpY2F0 aW9uIGlzIG5vIHN0cm9uZ2VyIHRoYW4gdGhlIHdlYWtlc3QNCiAgIGNvbWJp bmF0aW9uIGFsbG93ZWQuDQoNCjExLjIuMSBXZWFrIFRyYW5zcG9ydA0KDQog ICBJZiB0aGUgdHJhbnNwb3J0IGxheWVyIGRvZXMgbm90IHByb3ZpZGUgY29u ZmlkZW50aWFsaXR5LCBhdXRoZW50aWNhdGlvbg0KICAgbWV0aG9kcyB0aGF0 IHJlbHkgb24gc2VjcmV0IGRhdGEgU0hPVUxEIGJlIGRpc2FibGVkLiAgSWYg aXQgZG9lcyBub3QNCiAgIHByb3ZpZGUgTUFDIHByb3RlY3Rpb24sIHJlcXVl c3RzIHRvIGNoYW5nZSBhdXRoZW50aWNhdGlvbiBkYXRhIChlLmcuDQogICBw YXNzd29yZCBjaGFuZ2UpIFNIT1VMRCBiZSBkaXNhYmxlZCB0byBhdm9pZCBh biBhdHRhY2tlciBmcm9tDQogICBtb2RpZnlpbmcgdGhlIGNpcGhlcnRleHQg d2l0aG91dCBiZWluZyBub3RpY2VkLCByZW5kZXJpbmcgdGhlIG5ldw0KICAg YXV0aGVudGljYXRpb24gZGF0YSB1bnVzYWJsZSAoZGVuaWFsIG9mIHNlcnZp Y2UpLg0KDQoxMS4yLjIgRGVidWcgbWVzc2FnZXMNCg0KICAgU3BlY2lhbCBj YXJlIHNob3VsZCBiZSB0YWtlbiB3aGVuIGRlc2lnbmluZyBkZWJ1ZyBtZXNz YWdlcy4gIFRoZXNlDQogICBtZXNzYWdlcyBtYXkgcmV2ZWFsIHN1cnByaXNp bmcgYW1vdW50cyBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaG9zdA0KICAg aWYgbm90IHByb3Blcmx5IGRlc2lnbmVkLiAgRGVidWcgbWVzc2FnZXMgY2Fu IGJlIGRpc2FibGVkIChkdXJpbmcNCiAgIHVzZXIgYXV0aGVudGljYXRpb24g cGhhc2UpIGlmIGhpZ2ggc2VjdXJpdHkgaXMgcmVxdWlyZWQuDQoNCjExLjIu MyBMb2NhbCBzZWN1cml0eSBwb2xpY3kNCg0KICAgSW1wbGVtZW50ZXIgTVVT VCBlbnN1cmUgdGhhdCB0aGUgY3JlZGVudGlhbHMgcHJvdmlkZWQNCiAgIHZh bGlkYXRlIHRoZSBwcm9mZXNzZWQgdXNlciBhbmQgYWxzbyBNVVNUIGVuc3Vy ZSB0aGF0DQogICB0aGUgbG9jYWwgcG9saWN5IG9mIHRoZSBzZXJ2ZXIgcGVy bWl0cyB0aGUgdXNlciB0aGUNCiAgIGFjY2VzcyByZXF1ZXN0ZWQuDQoNCiAg IEluIHBhcnRpY3VsYXIsIGJlY2F1c2Ugb2YgdGhlIGZsZXhpYmxlIG5hdHVy ZSBvZiB0aGUgU1NIIGNvbm5lY3Rpb24NCiAgIHByb3RvY29sLCBpdCBtYXkg bm90IGJlIHBvc3NpYmxlIHRvIGRldGVybWluZQ0KICAgPHN0cmlrZT48Zm9u dCBjb2xvcj1yZWQ+dGhpcyBjb21wbGV0ZWx5PC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPnRoZSBsb2NhbCBzZWN1cml0eQ0K ICAgcG9saWN5IHRoYXQgc2hvdWxkIGFwcGx5PC9mb250Pjwvc3Ryb25nPiBh dCB0aGUgdGltZSBvZiBhdXRoZW50aWNhdGlvbiwgYmVjYXVzZSB0aGUNCiAg IGtpbmQgb2Ygc2VydmljZSBiZWluZyByZXF1ZXN0ZWQgaXMgbm90IHlldCBj bGVhci4gRm9yIGV4YW1wbGUsIGxvY2FsDQogICBwb2xpY3kgbWlnaHQgYWxs b3cgYSB1c2VyIHRvIGFjY2VzcyBmaWxlcyBvbiB0aGUgc2VydmVyLCBidXQg bm90IHN0YXJ0DQogICBhbiBpbnRlcmFjdGl2ZSBzaGVsbC4gSG93ZXZlciwg ZHVyaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCwgaXQNCiAgIGlz IG5vdCBrbm93biB3aGV0aGVyIHRoZSB1c2VyIHdpbGwgYmUgYWNjZXNzaW5n IGZpbGVzIG9yIGF0dGVtcHRpbmcgdG8NCiAgIHVzZSBhbiBpbnRlcmFjdGl2 ZSBzaGVsbCwgb3IgZXZlbiBib3RoLiBJbiBhbnkgZXZlbnQsIGxvY2FsIHNl Y3VyaXR5DQogICBwb2xpY3kgZm9yIHRoZSBzZXJ2ZXIgaG9zdCBNVVNUIGJl IGFwcGxpZWQgYW5kIGVuZm9yY2VkIGNvcnJlY3RseS4NCg0KPHN0cm9uZz48 Zm9udCBjb2xvcj1ncmVlbj5bTmljbzogIFdoYXQgaWYgbm8gcG9saWN5IGlz IGF2YWlsYWJsZT88L2ZvbnQ+PC9zdHJvbmc+DQoNCg0KMTEuMi40IFB1Ymxp YyBrZXkgYXV0aGVudGljYXRpb24NCg0KICAgVGhlIHVzZSBvZiBwdWJsaWMt a2V5IGF1dGhlbnRpY2F0aW9uIGFzc3VtZXMgdGhhdCB0aGUNCiAgIGNsaWVu dCBob3N0IGhhcyBub3QgYmVlbiBjb21wcm9taXNlZC4NCg0KICAgVGhpcyBy aXNrIGNhbiBiZSBtaXRpZ2F0ZWQgYnkgdGhlIHVzZSBvZiBwYXNzcGhyYXNl cw0KICAgb24gcHJpdmF0ZSBrZXlzOyBob3dldmVyLCB0aGlzIGlzIG5vdCBh biBlbmZvcmNlYWJsZQ0KICAgcG9saWN5LiAgVGhlIHVzZSBvZiBzbWFydGNh cmRzLCBvciBvdGhlciB0ZWNobm9sb2d5DQogICB0byBtYWtlIHBhc3NwaHJh c2VzIGFuIGVuZm9yY2VhYmxlIHBvbGljeSBpcyBzdWdnZXN0ZWQuDQoNCiAg IFRoZSBzZXJ2ZXIgY291bGQgcmVxdWlyZSBib3RoIHBhc3N3b3JkIGFuZCBw dWJsaWMta2V5DQogICBhdXRoZW50aWNhdGlvbiwgaG93ZXZlciwgdGhpcyBy ZXF1aXJlcyB0aGUgY2xpZW50DQogICB0byBleHBvc2UgaXRzIHBhc3N3b3Jk IHRvIHRoZSBzZXJ2ZXIgKHNlZSBzZWN0aW9uIG9uDQogICBwYXNzd29yZCBh dXRoZW50aWNhdGlvbiBiZWxvdy4pDQoNCjExLjIuNSBQYXNzd29yZCBhdXRo ZW50aWNhdGlvbg0KDQogICBUaGUgcGFzc3dvcmQgbWVjaGFuaXNtIG9mIHNw ZWNpZmllZCBpbiB0aGUgYXV0aGVudGljYXRpb24NCiAgIHByb3RvY29sIGFz c3VtZXMgdGhhdCB0aGUgc2VydmVyIGhhcyBub3QgYmVlbiBjb21wcm9taXNl ZC4NCiAgIElmIHRoZSBzZXJ2ZXIgaGFzIGJlZW4gY29tcHJvbWlzZWQsIHVz aW5nIHBhc3N3b3JkDQogICBhdXRoZW50aWNhdGlvbiB3aWxsIHJldmVhbCBh IHZhbGlkIHVzZXJuYW1lIC8gcGFzc3dvcmQNCiAgIGNvbWJpbmF0aW9uIHRv IHRoZSBhdHRhY2tlciwgd2hpY2ggbWF5IGxlYWQgdG8gZnVydGhlcg0KICAg Y29tcHJvbWlzZXMuDQoNCiAgIFRoaXMgdnVsbmVyYWJpbGl0eSBjYW4gYmUg bWl0aWdhdGVkIGJ5IHVzaW5nIGFuIGFsdGVybmF0aXZlDQogICBmb3JtIG9m IGF1dGhlbnRpY2F0aW9uLiAgRm9yIGV4YW1wbGUsIHB1YmxpYy1rZXkgYXV0 aGVudGljYXRpb24NCiAgIG1ha2VzIG5vIGFzc3VtcHRpb25zIGFib3V0IHNl Y3VyaXR5IG9uIHRoZSBzZXJ2ZXIuDQoNCjExLjIuNiBIb3N0IGJhc2VkIGF1 dGhlbnRpY2F0aW9uDQoNCiAgIEhvc3QgYmFzZWQgYXV0aGVudGljYXRpb24g YXNzdW1lcyB0aGF0IHRoZSBjbGllbnQNCiAgIGhhcyBub3QgYmVlbiBjb21w cm9taXNlZC4gIFRoZXJlIGFyZSBubyBtaXRpZ2F0aW5nDQogICBzdHJhdGVn aWVzLCBvdGhlciB0aGFuIHRvIHVzZSBob3N0IGJhc2VkIGF1dGhlbnRpY2F0 aW9uDQogICBpbiBjb21iaW5hdGlvbiB3aXRoIGFub3RoZXIgYXV0aGVudGlj YXRpb24gbWV0aG9kLg0KDQoxMS4zIENvbm5lY3Rpb24gcHJvdG9jb2wNCg0K MTEuMy4xIEVuZCBwb2ludCBzZWN1cml0eQ0KDQogICBFbmQgcG9pbnQgc2Vj dXJpdHkgaXMgYXNzdW1lZCBieSB0aGUgY29ubmVjdGlvbiBwcm90b2NvbC4N CiAgIElmIHRoZSBzZXJ2ZXIgaGFzIGJlZW4gY29tcHJvbWlzZWQsIGFueSB0 ZXJtaW5hbCBzZXNzaW9ucywNCiAgIHBvcnQgZm9yd2FyZGluZywgb3Igc3lz dGVtcyBhY2Nlc3NlZCBvbiB0aGUgaG9zdCBhcmUgY29tcHJvbWlzZWQuDQog ICBUaGVyZSBhcmUgbm8gbWl0aWdhdGluZyBmYWN0b3JzIGZvciB0aGlzLg0K DQogICBJZiB0aGUgY2xpZW50IGVuZCBwb2ludCBoYXMgYmVlbiBjb21wcm9t aXNlZCwgYW5kIHRoZSBzZXJ2ZXINCiAgIGZhaWxzIHRvIHN0b3AgdGhlIGF0 dGFja2VyIGF0IHRoZSBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCwNCiAgIGFs bCBzZXJ2aWNlcyBleHBvc2VkIChlaXRoZXIgYXMgc3Vic3lzdGVtcyBvciB0 aHJvdWdoIGZvcndhcmRpbmcpDQogICB3aWxsIGJlIHZ1bG5lcmFibGUgdG8g YXR0YWNrLiAgSW1wbGVtZW50b3JzIFNIT1VMRCBwcm92aWRlDQogICBtZWNo YW5pc21zIGZvciBhZG1pbmlzdHJhdG9ycyB0byBjb250cm9sIHdoaWNoIHNl cnZpY2VzDQogICBhcmUgZXhwb3NlZCB0byBsaW1pdCB0aGUgdnVsbmVyYWJp bGl0eSBvZiBvdGhlciBzZXJ2aWNlcy4NCg0KICAgVGhlc2UgY29udHJvbHMg bWlnaHQgaW5jbHVkZSBjb250cm9sbGluZyB3aGljaCBtYWNoaW5lcyBhbmQN CiAgIHBvcnRzIGNhbiBiZSB0YXJnZXQgaW4gJ3BvcnQtZm9yd2FyZGluZycg b3BlcmF0aW9ucywgd2hpY2gNCiAgIHVzZXJzIGFyZSBhbGxvd2VkIHRvIHVz ZSBpbnRlcmFjdGl2ZSBzaGVsbCBmYWNpbGl0aWVzLCBvcg0KICAgd2hpY2gg dXNlcnMgYXJlIGFsbG93ZWQgdG8gdXNlIGV4cG9zZWQgc3Vic3lzdGVtcy4N Cg0KMTEuMy4yIFByb3h5IGZvcndhcmRpbmcNCg0KICAgVGhlIFNTSCBjb25u ZWN0aW9uIHByb3RvY29sIGFsbG93cyBmb3IgcHJveHkgZm9yd2FyZGluZyBv ZiBvdGhlcg0KICAgcHJvdG9jb2xzIHN1Y2ggYXMgU05NUCwgUE9QMywgYW5k IEhUVFAuICBUaGlzIG1heSBiZSBhIGNvbmNlcm4gZm9yDQogICBuZXR3b3Jr IGFkbWluaXN0cmF0b3JzIHdobyB3aXNoIHRvIGNvbnRyb2wgdGhlIGFjY2Vz cyBvZiBjZXJ0YWluDQogICBhcHBsaWNhdGlvbnMgYnkgdXNlcnMgbG9jYXRl ZCBvdXRzaWRlIG9mIHRoZWlyIHBoeXNpY2FsIGxvY2F0aW9uLg0KICAgRXNz ZW50aWFsbHksIHRoZSBmb3J3YXJkaW5nIG9mIHRoZXNlIHByb3RvY29scyBt YXkgdmlvbGF0ZSBzaXRlDQogICBzcGVjaWZpYyBzZWN1cml0eSBwb2xpY2ll cyBhcyB0aGV5IG1heSBiZSB1bmRldGVjdGFibHkgdHVubmVsZWQNCiAgIHRo cm91Z2ggYSBmaXJld2FsbC4gIEltcGxlbWVudG9ycyBTSE9VTEQgcHJvdmlk ZSBhbiBhZG1pbmlzdHJhdGl2ZQ0KICAgbWVjaGFuaXNtIHRvIGNvbnRyb2wg dGhlIHByb3h5IGZvcndhcmRpbmcgZnVuY3Rpb25hbGl0eSBzbyB0aGF0DQog ICBzaXRlIHNwZWNpZmljIHNlY3VyaXR5IHBvbGljaWVzIG1heSBiZSB1cGhl bGQuDQoNCiAgIEluIGFkZGl0aW9uLCBhIHJldmVyc2UgcHJveHkgZm9yd2Fy ZGluZyBmdW5jdGlvbmFsaXR5DQogICBpcyBhdmFpbGFibGUsIHdoaWNoIGFn YWluIGNhbiBiZSB1c2VkIHRvIGJ5cGFzcyBmaXJld2FsbA0KICAgY29udHJv bHMuDQoNCiAgIEFzIGluZGljYXRlZCBhYm92ZSwgZW5kLXBvaW50IHNlY3Vy aXR5IGlzIGFzc3VtZWQgZHVyaW5nDQogICBwcm94eSBmb3J3YXJkaW5nIG9w ZXJhdGlvbnMuICBGYWlsdXJlIG9mIGVuZC1wb2ludCBzZWN1cml0eQ0KICAg d2lsbCBjb21wcm9taXNlIGFsbCBkYXRhIHBhc3NlZCBvdmVyIHByb3h5IGZv cndhcmRpbmcuDQoNCjExLjMuMyBYMTEgZm9yd2FyZGluZw0KDQogICBBbm90 aGVyIGZvcm0gb2YgcHJveHkgZm9yd2FyZGluZyBwcm92aWRlZCBieSB0aGUg c3NoDQogICBjb25uZWN0aW9uIHByb3RvY29sIGlzIHRoZSBmb3J3YXJkaW5n IG9mIHRoZSBYMTEgcHJvdG9jb2wuDQoNCiAgIEltcGxlbWVudG9ycyBvZiB0 aGUgWDExIHByb3RvY29sIFNIT1VMRCBpbXBsZW1lbnQgdGhlIG1hZ2ljIGNv b2tpZSANCiAgIHNwb29maW5nLCB0byBwcmV2ZW50IHVuYXV0aG9yaXplZCB1 c2Ugb2YgdGhlIHByb3h5LiAgPHN0cm9uZz48Zm9udCBjb2xvcj1ncmVlbj5N b3JlIGluZm9ybWF0aW9uIA0KICAgYWJvdXQgdGhlIHVzZSBvZiB0aGUgWDEx IG1hZ2ljIGNvb2tpZSBtYXkgYmUgZm91bmQgaW4gbWFueSBvZiB0aGUgDQog ICBhdmFpbGFibGUgbWFudWFsIHJlZmVyZW5jZXMgYW5kIGltcGxlbWVudGF0 aW9uIGd1aWRlcyBmb3IgWDExLiAgRm9yDQogICBleGFtcGxlLCB2aWV3aW5n IHRoZSBtYW51YWwgcGFnZSBmb3IgInhhdXRoIiBpbiBCU0Qgc3lzdGVtcyBt YXkgYmUgb25lIA0KICAgcGxhY2UgdG8gc3RhcnQuPC9mb250Pjwvc3Ryb25n Pg0KDQogICBYMTEgZm9yd2FyZGluZyByZWxpZXMgb24gZW5kLXBvaW50IHNl Y3VyaXR5LiAgSWYgZW5kLXBvaW50DQogICBzZWN1cml0eSBoYXMgYmVlbiBj b21wcm9taXNlZCwgWDExIGZvcndhcmRpbmcgd2lsbCBhbGxvdw0KICAgYW55 IGF0dGFjayBhZ2FpbnN0IHRoZSBYMTEgc2VydmVyIHBvc3NpYmxlIGxvY2Fs bHkuDQoNCiAgIFVzZXJzIGFuZCBhZG1pbmlzdHJhdG9ycyBzaG91bGQsIGFz IGEgbWF0dGVyIG9mIGNvdXJzZSwgdXNlDQogICBYMTEgc2VjdXJpdHkgbWVj aGFuaXNtIHRvIHByZXZlbnQgdW5hdXRob3JpemVkIHVzZSBvZg0KICAgdGhl IFgxMSBzZXJ2ZXIuDQo8c3Ryb25nPjxmb250IGNvbG9yPWdyZWVuPg0KW1JK QTogIFdoaWNoICJYMTEgc2VjdXJpdHkgbWVjaGFuaXNtIiBpcyBtZWFudCA/ DQpbUkpBOiAgQWxzbywgcGxlYXNlIGFkZCBhIGNpdGF0aW9uIGZvciB0aGF0 IG1lY2hhbmlzbS4NCg0KW0pHOiAgV2VsbCwgSSBkaWRuJ3QgaGF2ZSBhIHBh cnRpY3VsYXIgb25lIGluIG1pbmQuICBUaGUNCltKRzogIGFkdmljZSBpcyB0 byB1c2UgYW55IFgxMSBzZWN1cml0eSBtZWNoYW5pc20uICBJJ2QNCltKRzog IGJlIHdpbGxpbmcgdG8gcmVtb3ZlIHRoZSBwYXJhZ3JhcGguDQpbUkpBOiAg SSdkIGxpa2UgdG8ga2VlcCB0ZXh0IGVuY291cmFnaW5nIGZvbGtzIHRvIHVz ZSBhcyBtdWNoDQpbUkpBOiAgc2VjdXJpdHkgYXMgdGhleSBjYW4uICBJJ20g bm90IGFuIGV4cGVydCBvbiB0aGUgc2VjdXJpdHkNCltSSkE6ICBwcm9wZXJ0 aWVzIG9mIFgxMS4gIEkgd2FzIHRoaW5raW5nIHRoYXQgdGhlcmUgcHJvYmFi bHkgd2VyZQ0KW1JKQTogIHNvbWUgc3BlY2lmaWMgc2VjdXJpdHkgbWVjaGFu aXNtcyAoZS5nLiBteSB2YWd1ZSByZWNvbGxlY3Rpb24NCltSSkE6ICBvZiB0 aGUgTUlULW1hZ2ljLWNvb2tpZSBoYWNrIG5vdGVkIGFib3ZlKSB0aGF0IHdl IG91Z2h0DQpbUkpBOiAgdG8gbWVudGlvbiBhbmQgY2l0ZS48L2ZvbnQ+PHN0 cm9uZz48L3ByZT4NCg== --836307491-579758561-1050443957=:15447-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 17 14:59: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 OAA02377 for ; Thu, 17 Apr 2003 14:59:03 -0400 (EDT) Received: (qmail 25524 invoked by uid 605); 17 Apr 2003 19:01:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25517 invoked from network); 17 Apr 2003 19:01:40 -0000 Received: from nbwww.isc.org (HELO narn.netbsd.org) (204.152.184.198) by mail.netbsd.org with SMTP; 17 Apr 2003 19:01:40 -0000 Received: from rediffmail.com (unknown [208.52.4.88]) by narn.netbsd.org (Postfix) with SMTP id 8EF4411152 for ; Thu, 17 Apr 2003 19:01:25 +0000 (UTC) From: "SAM" To: Subject: ASSOCIATES URGENTLY NEEDED. Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 17 Apr 2003 20:01:30 +0100 Reply-To: "SAM" X-Priority: 1 (Highest) Content-Transfer-Encoding: 8bit Message-Id: <20030417190125.8EF4411152@narn.netbsd.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Dear friend, My name is Sam ige, the son of the Late Minister of Justice and the former attorney general of the federations Chief Bola Ige, who was murdered in cold blood last year. After the assassination of my late father, our family attorney disclose to us that my father has deposited some funds with a Bank security vault, all the documents has been handed over to me for safe keeping, but due to the recent bill endorse by the Senate to probe official both in and out of government, I used this opportunity to reach out in looking for someone who can front as my late father's business associates in claiming the funds. Note that you can access these funds online before issuing appropriate instructions to effect transfer to any account that you may nominate for this purpose. My areas of investment is on real state, importation & Agriculture, if you have an existing company that will be able to handle a capital project kindly notify by forwarding your full information and online how you intend to go about his project. As soon as l hear from you, confirming your veritable information that you will provide, I will disclose every information that will enable you front on behalf of the family. Best regards, Sam Ige From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 21 06: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 GAA09084 for ; Mon, 21 Apr 2003 06:40:26 -0400 (EDT) Received: (qmail 14329 invoked by uid 605); 21 Apr 2003 10:41:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14322 invoked from network); 21 Apr 2003 10:41:15 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 21 Apr 2003 10:41:15 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.3) with ESMTP id h3LAfEZJ030642 for ; Mon, 21 Apr 2003 03:41:14 -0700 Received: from moma.corp.google.com (localhost [127.0.0.1]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h3LAfElr021069 for ; Mon, 21 Apr 2003 03:41:14 -0700 Received: (from frank@localhost) by moma.corp.google.com (8.12.9/8.12.3) id h3LAfE8o021068 for ietf-ssh@netbsd.org; Mon, 21 Apr 2003 03:41:14 -0700 Date: Mon, 21 Apr 2003 03:41:14 -0700 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: Re: WG chair nits on draft-ietf-secsh-auth-kbdinteract-04.txt Message-ID: <20030421034114.A11427@google.com> References: <200303181724.h2IHOn7J000392@syn.hamachi.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200303181724.h2IHOn7J000392@syn.hamachi.org>; from sommerfeld@east.sun.com on Tue, Mar 18, 2003 at 09:24:48AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 18, 2003 at 09:24:48AM -0800, Bill Sommerfeld wrote: > 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). ok > 2) security considerations. ok > 3) iana considerations. > > "protocol constants" should turn into "iana considerations". > > also an explicit allocation of the userauth type > "keyboard-interactive" needs to be listed. ok Here are proposed changes, covering the above and some other minor items. I think they are pretty non-contentious. I'm not sure if I addressed the allocation of "keyboard-interactive" very well. Comments, please. 1. Introduction - The SSH authentication protocol is a general-purpose user - authentication protocol. It is intended to be run over the SSH - transport layer protocol [SSH-TRANS]. The protocol assumes that the - underlying protocols provide integrity and confidentiality - protection. + The SSH authentication protocol [SSH-USERAUTH] is a general-purpose + user authentication protocol. It is intended to be run over the SSH + transport layer protocol [SSH-TRANS]. The authentication protocol + assumes that the underlying protocols provide integrity and + confidentiality protection. [The original text appears to have been lifted directly from SSH-USERAUTH and so needed some updating for references.] This document describes a general purpose authentication method for - the SSH protocol. This method is suitable for interactive + the SSH authentication protocol. This method is suitable for + interactive ... - somewhat out of the scope of a protocol specification, it is still - described here since some aspects of the protocol are specifically + somewhat out of the scope of a protocol specification, it is + described here anyway since some aspects of the protocol are [it is still described here -> it is described here anyway] 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 RFC 2119. + document are to be interpreted as described in [RFC-2119]. 3.1 Initial Exchange ... byte SSH_MSG_USERAUTH_REQUEST - string user name (ISO-10646 UTF-8) + string user name (ISO-10646 UTF-8, as defined in [RFC-2279]) [I left other mentions of UTF-8 without endnote refs, that's ok, yeah?] 4. Authentication Examples Here are two example exchanges between a client and server. The - first is an example of a challenge/response implementation. This is - an authentication that is not otherwise possible with other + first is an example of challenge/response with a handheld token. + This is an authentication that is not otherwise possible with other authentication methods. -5. Protocol constants +5. IANA Considerations + + The userauth type "keyboard-interactive" is used for this + authentication method. The following method-specific constants are used with this authentication method: -6. References +6. Security Considerations + The authentication protocol, and this authentication method, depends + on the security of the underlying SSH transport layer. Without the + confidentiality provided therein, any authentication data passed with + this method is subject to interception. + + The number of client-server exchanges required to complete an + authentication using this method may be variable. It is possible + that an observer may gain valuable information simply by counting + that number. For example, an observer may guess that a user's + password has expired, and with further observation may be able to + determine the frequency of a site's password expiration policy. +7. References +7.1 Normative References +7.2 Informative References + [PAM] Samar, V., Schemers, R., "Unified Login With + Pluggable Authentication Modules (PAM)", OSF RFC + 86.0, October 1995 That's it. I've also attached a complete copy. /fc --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pwplus.txt" Network Working Group F. Cusack INTERNET-DRAFT Google, Inc. Expires October 23, 2003 M. Forssen Appgate AB April 23, 2003 Generic Message Exchange Authentication For SSH Status of this Memo This document is an Internet-Draft and is subject to 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 . The list of Internet-Draft Shadow Directories can be accessed at . This Internet-Draft will expire on October 23, 2003. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). F. Cusack, M. Forssen Expires October 23, 2003 [Page 1] Internet Draft SSH Generic Interactive Authentication April 23, 2003 1. Introduction The SSH authentication protocol [SSH-USERAUTH] is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection. This document describes a general purpose authentication method for the SSH authentication protocol. This method is suitable for interactive authentication methods which do not need any special software support on the client side. Instead all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code. The name for this authentication method is "keyboard-interactive". This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation. This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is described here anyway since some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations. 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 [RFC-2119]. 2. Rationale Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. This makes it difficult to add new mechanisms for authentication as all clients must be updated to support the new mechanism. With the generic method defined here, clients will not require code changes to support new authentication mechanisms, and if a separate authentication layer is used, such as [PAM], then the server may not need any code changes either. F. Cusack, M. Forssen Expires October 23, 2003 [Page 2] Internet Draft SSH Generic Interactive Authentication April 23, 2003 This presents a significant advantage to other methods, such as the "password" method (defined in [SSH-USERAUTH]), as new (presumably stronger) methods may be added "at will" and system security can be transparently enhanced. Challenge-response and One Time Password mechanisms are also easily supported with this authentication method. This authentication method is however limited to authentication mechanisms which do not require any special code, such as hardware drivers or password mangling, on the client. 3. Protocol Exchanges The client initiates the authentication with a SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with a SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with a SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client. 3.1 Initial Exchange The authentication starts with the client sending the following packet: byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8, as defined in [RFC-2279]) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8) The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. The server SHOULD instead select the language used based on the tags communicated during key exchange [SSH-TRANS]. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. The language to be used if the server does not support the requested language is implementation-dependent. The submethods field is included so the user can give a hint of which F. Cusack, M. Forssen Expires October 23, 2003 [Page 3] Internet Draft SSH Generic Interactive Authentication April 23, 2003 actual methods he wants to use. It is a a comma-separated list of authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise it MUST send the empty string. The actual names of the submethods is something which the user and the server needs to agree upon. Server interpretation of the submethods field is implementation- dependent. One possible implementation strategy of the submethods field on the server is that, unless the user may use multiple different submethods, the server ignores this field. If the user may authenticate using one of several different submethods the server should treat the submethods field as a hint on which submethod the user wants to use this time. Note that when this message is sent to the server, the client has not yet prompted the user for a password, and so that information is NOT included with this initial message (unlike the "password" method). The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just like the one(s) which would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid usernames by just comparing the results when authenticating as different users. 3.2 Information Requests Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message. The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may not send another request before the client has answered. F. Cusack, M. Forssen Expires October 23, 2003 [Page 4] Internet Draft SSH Generic Interactive Authentication April 23, 2003 The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] The server SHOULD take into consideration that some clients may not be able to properly display a long name or prompt field (see next section), and limit the lengths of those fields if possible. For example, instead of an instruction field of "Enter Password" and a prompt field of "Password for user23@host.domain: ", a better choice might be an instruction field of "Password authentication for user23@host.domain" and a prompt field of "Password: ". It is expected that this authentication method would typically be backended by [PAM] and so such choices would not be possible. The name and instruction fields MAY be empty strings, the client MUST be prepared to handle this correctly. The prompt field(s) MUST NOT be empty strings. The language tag SHOULD describe the language used in the textual fields. If the server does not know the language used, or if multiple languages are used, the language tag MUST be the empty string. The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below). 3.3 User Interface Upon receiving a request message, the client SHOULD prompt the user as follows: A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then for each prompt in turn, the client SHOULD display the prompt and read the user input. A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly F. Cusack, M. Forssen Expires October 23, 2003 [Page 5] Internet Draft SSH Generic Interactive Authentication April 23, 2003 prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user, for example an implementation SHOULD NOT discard the name field because its windows lack titles; it SHOULD instead find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window. All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occured. The instruction field SHOULD NOT be truncated. Clients SHOULD use control character filtering as discussed in [SSH-ARCH] to avoid attacks by including terminal control characters in the fields to be displayed. For each prompt, the corresponding echo field indicates whether or not the user input should be echoed as characters are typed. Clients SHOULD correctly echo/mask user input for each prompt independently of other prompts in the request message. If a client does not honor the echo field for whatever reason, then the client MUST err on the side of masking input. A GUI client might like to have a checkbox toggling echo/mask. Clients SHOULD NOT add any additional characters to the prompt such as ": " (colon-space); the server is responsible for supplying all text to be displayed to the user. Clients MUST also accept empty responses from the user and pass them on as empty strings. 3.4 Information Responses After obtaining the requested information from the user, the client MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows: byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8) F. Cusack, M. Forssen Expires October 23, 2003 [Page 6] Internet Draft SSH Generic Interactive Authentication April 23, 2003 Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting. If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message. In the case that the server sends a `0' num-prompts field in the request message, the client MUST send a response message with a `0' num-responses field. The responses MUST be ordered as the prompts were ordered. That is, response[n] MUST be the answer to prompt[n]. After receiving the response, the server MUST send either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message. If the server fails to authenticate the user (through the underlying authentication mechanism(s)), it SHOULD NOT send another request message(s) in an attempt to obtain new authentication data, instead it SHOULD send a failure message. The only time the server should send multiple request messages is if additional authentication data is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user). If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending to the client. It is suspected that implementations are likely to make the time delay a configurable, a suggested default is 2 seconds. 4. Authentication Examples Here are two example exchanges between a client and server. The first is an example of challenge/response with a handheld token. This is an authentication that is not otherwise possible with other authentication methods. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string "" F. Cusack, M. Forssen Expires October 23, 2003 [Page 7] Internet Draft SSH Generic Interactive Authentication April 23, 2003 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "CRYPTOCard Authentication" S: string "The challenge is '14315716'" S: string "en-US" S: int 1 S: string "Response: " S: boolean TRUE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "6d757575" S: byte SSH_MSG_USERAUTH_SUCCESS The second example is of a standard password authentication, in this case the user's password is expired. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "en-US" C: string "" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Authentication" S: string "" S: string "en-US" S: int 1 S: string "Password: " S: boolean FALSE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "password" F. Cusack, M. Forssen Expires October 23, 2003 [Page 8] Internet Draft SSH Generic Interactive Authentication April 23, 2003 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Expired" S: string "Your password has expired." S: string "en-US" S: int 2 S: string "Enter new password: " S: boolean FALSE S: string "Enter it again: " S: boolean FALSE [Client prompts user for new password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 2 C: string "newpass" C: string "newpass" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password changed" S: string "Password successfully changed for user23." S: string "en-US" S: int 0 [Client displays message to user] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0 S: byte SSH_MSG_USERAUTH_SUCCESS 5. IANA Considerations The userauth type "keyboard-interactive" is used for this authentication method. The following method-specific constants are used with this authentication method: SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 6. Security Considerations The authentication protocol, and this authentication method, depends on the security of the underlying SSH transport layer. Without the confidentiality provided therein, any authentication data passed with this method is subject to interception. F. Cusack, M. Forssen Expires October 23, 2003 [Page 9] Internet Draft SSH Generic Interactive Authentication April 23, 2003 The number of client-server exchanges required to complete an authentication using this method may be variable. It is possible that an observer may gain valuable information simply by counting that number. For example, an observer may guess that a user's password has expired, and with further observation may be able to determine the frequency of a site's password expiration policy. 7. References 7.1 Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, October 1996. [RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Protocol Architecture", work in progress, draft-ietf-secsh-architecture-13.txt, September, 2002. [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Connection Protocol", work in progress, draft-ietf-secsh-connect-16.txt, September, 2002. [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Transport Layer Protocol", work in progress, draft-ietf-secsh-transport-15.txt, September, 2002. [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Authentication Protocol", work in progress, draft-ietf-secsh-userauth-16.txt, September, 2002. F. Cusack, M. Forssen Expires October 23, 2003 [Page 10] Internet Draft SSH Generic Interactive Authentication April 23, 2003 7.2 Informative References [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995 8. Author's Addresses Frank Cusack Google, Inc. 2400 Bayshore Parkway Mountain View, CA 94043 Email: frank@google.com Martin Forssen Appgate AB Stora Badhusgatan 18-20 SE-411 21 Gothenburg SWEDEN Email: maf@appgate.com F. Cusack, M. Forssen Expires October 23, 2003 [Page 11] --ReaqsoxgOBHFXBhH-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 23 07:14: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 HAA12146 for ; Wed, 23 Apr 2003 07:14:25 -0400 (EDT) Received: (qmail 21745 invoked by uid 605); 23 Apr 2003 11:17:06 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20030423111706.21744.qmail@mail.netbsd.org> Received: (qmail 21735 invoked from network); 23 Apr 2003 11:16:59 -0000 Received: from user204.net258.nc.sprint-hsd.net (HELO 208.17.66.204) (208.17.66.204) by mail.netbsd.org with SMTP; 23 Apr 2003 11:16:59 -0000 From: "James Hammond" To: Subject: Get a FREE Position!...Get $50/mo. for Each Person You Sponsor! Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 23 Apr 2003 07:16:47 -0400 Reply-To: "James Hammond" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit NEWLY LAUNCHED PROGRAM! * Proven EricWare Technology (e.g. BigLeadsPro, 28DayWealth, etc.) * No sponsoring required to be in profit - exclusive back-end matrix * $50 monthly for every personal enrollment * $5-10 monthly for everyone on your "weak" leg * Marketing products that everyone can use * Brian Garvin, Joe Schroeder, Jesus Mejias, Ken Langille, Jerome Chapman, Terin D'amico, Steve Sigman, Don Ticotin, Frank Mueller, Chris Nawada, Ryan Burgard, Jim Vigilante, and other top marketers in your upline * Free trial Lock in your position now! This is going to be bigger than all of the other EricWare systems COMBINED! Take a free test drive ... Send a blank e-mail, with "eBN" typed in the Subject line, to jlhammond@Argentina.com James Hammond Transitions21 ------<<>>----------<<>>----------<<>>----------<<>>---------- We Respect Your Privacy and Pledge not to Abuse This Privilege. To Stop Future Mailings, Send a Blank E-mail to the Address Below to be Removed Instantly: transitions21@bigfoot.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 24 16:06: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 QAA01419 for ; Thu, 24 Apr 2003 16:06:33 -0400 (EDT) Received: (qmail 14175 invoked by uid 605); 24 Apr 2003 20:09:17 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20030424200917.14174.qmail@mail.netbsd.org> Received: (qmail 14168 invoked from network); 24 Apr 2003 20:09:16 -0000 Received: from evrtwa1-ar8-4-65-027-183.evrtwa1.dsl-verizon.net (HELO 4.65.27.183) (4.65.27.183) by mail.netbsd.org with SMTP; 24 Apr 2003 20:09:16 -0000 From: "Quick & Easy Leasing" To: Subject: Quick & Easy Leasing Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 24 Apr 2003 13:09:23 -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Quick & Easy Leasing As an established leader in the Lease Finance industry, we look forward to being your partner in equipment lease financing. Our many years of successful experience will assure high approval ratios, low rates and great service. Our services and tools, when used effectively, will help you secure the equipment your business needs. They include: - 90 day deferred payments - $25.00 down (no 1st and last payment) - $100.00 a month for the first seven months - Corporate only leases - No PG - Start-Up Business Programs Available * Fast and flexible credit decisions (2 to 24 hours) * High approval rates * Leasing for both new and used equipment * Applications by telephone * Pre-funding available * No financials required under $75,000 * 100% Software Financing * Soft costs (install charges) can be included * Funding within 24 hours We look forward to working with you in the near future. If you have any questions or want to receive an application please reply to this message today. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 28 10:29: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 KAA02911 for ; Mon, 28 Apr 2003 10:29:47 -0400 (EDT) Received: (qmail 10486 invoked by uid 605); 28 Apr 2003 14:32:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10478 invoked from network); 28 Apr 2003 14:32:29 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 28 Apr 2003 14:32:29 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19A9gC-0004s1-00; Mon, 28 Apr 2003 15:32:28 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200302111146.GAA28668@ietf.org> Subject: Agent protocol Message-Id: Date: Mon, 28 Apr 2003 15:32:28 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list wrote: > Title : Secure Shell Authentication Agent Protocol > Author(s) : D. Moffat, T. Rinne, S. Lehtinen > Filename : draft-ietf-secsh-agent-01.txt I have a couple of comments on the document as it stands, and a proposal for an extension. > byte SSH_AGENT_ADD_KEY > string private key blob with empty passphrase > string public key and/or certificates for it > string description of the key > ... 0, 1 or several constraints follow Absolutely vital missing information here: what is the format of the private key blob? Unlike the public key blob, it hasn't been standardised in any existing documents for any other reason. I assume that the `public key and/or certificates' string is guaranteed suitable for use in SSH_MSG_USERAUTH_REQUEST as the `public key blob' string? Should this be made any clearer? > byte SSH_AGENT_FAILURE > uint32 error code Would it be too much trouble to allow an optional string after the error code? I can easily imagine some agents wanting to convey a human-readable message that contains more information than the small list of codes provided. We've only just got over this problem in SFTP; let's not have it all over again... Also I'd like to propose a simple extension to the protocol. When I implement this protocol in PuTTY's agent, I will want to add extra features which are not contained in this protocol. I could just pick an unused message number and hope nobody treads on it, but that's nasty. So I propose an additional message number, say 300, which has the format byte SSH_AGENT_EXTENSION string extension id ... extension-specific data follows ... `extension id' will of course be allocated in the same way all other SSH string ids are done: anything with an @ in it belongs to the owner of the domain after the @. That way, I can safely invent extensions to the agent protocol in a namespace I can be sure nobody else will attempt to re-use for other purposes. My vision of this message type is that it can be sent from client to agent _or_ from agent to client, depending on the extension. An agent should not be the first to send it, so a client can rely on not seeing strange unexpected extension messages in response to its requests; but if the client sends an extension message, the agent might need to respond with other extension messages if no existing response message is appropriate. If the agent sees an extension message it doesn't understand, then of course it should send back a complaint of some sort. Perhaps SSH_AGENT_FAILURE / SSH_AGENT_ERROR_UNSUPPORTED_OP. (One particular feature I want is to be able to add an _encrypted_ key to the agent, in such a way that the agent will list the public half of it, and will interactively request the passphrase from the user in response to the first attempt to actually use the key. This is the advantage of having your agent be GUI-aware... But of course this will be useless unless the encrypted blob is in PuTTY's own key format, otherwise the ssh-add analogue will have to reformat it which will involve decrypting and re-encrypting it.) Cheers, Simon -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 28 11:19: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 LAA04213 for ; Mon, 28 Apr 2003 11:19:23 -0400 (EDT) Received: (qmail 8159 invoked by uid 605); 28 Apr 2003 15:22:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8146 invoked from network); 28 Apr 2003 15:22:04 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 28 Apr 2003 15:22:04 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3SFM0EL023648 for ; Mon, 28 Apr 2003 08:22:02 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA08416 for ; Mon, 28 Apr 2003 08:22:00 -0700 (PDT) Date: Mon, 28 Apr 2003 08:22:00 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Re: Even Newer Section 11 for Your Comments 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 Everyone, My watchdog timer has gone off so I'm re-sending. There are comments below that SHOULD be addressed. Please take the time to look them over and comment upon them. Thanks, Chris On Wed, 16 Apr 2003, Chris Lonvick wrote: > Hi Folks, > > My thanks to everyone who's been discussing and making comments upon the > proposed Section 11. Below is a revision based upon the recent email > thread. Please look that over and provide your further comments. To make > the task of looking at the revisions easier, I've attached a file with > some html in it. (Your indulgences, please.) When viewed in a browser it > displays redline striking to indicate deleted passages and green text to > indicate insertions. It's not exact but it has markups at or near the > places that have changed which will hopefully allow everyone to review > these changes without having to hunt them down manually. > > I've edited some significant changes into Section 11.1.3 "Replay" and have > added a new Section 11.1.7 "Forward Secrecy". Please look those over > carefully. I've also tried very hard to keep outstanding questions in > this which still need to be addressed. These should be findable by > looking for "[xxx: " at the start of lines below. > > One comment that was raised was about adding a new section on the security > of the key exchange. I have not attempted to address that and it is not > noted below. If that is needed in this section, would someone > (Joseph? :-) please propose text? > > Thanks, > Chris > > ===vvv=== New Proposal for Section 11 ===vvv=== > > 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 confidential channel over an > insecure network. It performs server host authentication, key > exchange, encryption, and integrity protection. It also derives a > unique session id that may be used by higher-level protocols. > > The authentication protocol [2] provides a suite of mechanism which > can be used to authenticating the client user to the server. > Individual mechanisms specified in the in authentication protocol use > the session id provided by the transport protocol and/or depend on the > security and integrity guarantees of the transport protocol. > > The connection protocol [3] specifies a mechanism to multiplex > multiple streams [channels] of data over the confidential and > authenticated transport. It also specifies channels for accessing an > interactive shell, for 'proxy-forwarding' various external protocols > over the secure transport (including arbitrary TCP/IP protocols), and > for accessing secure 'subsystems' on the server host. > > 11.1 Transport > > > 11.1.1 Confidentiality > > It is beyond the scope of this document and the Secure Shell Working > Group to analyze or recommend specific ciphers other than the ones > which have been established and accepted within the industry. At the > time of this writing, ciphers commonly in use include 3DES, ARCFOUR, > twofish, serpent and blowfish. AES has been accepted by The US Federal > Information Processing Standards [FIPS-197] and the cryptographic > community as being acceptable for this purpose as well. As always, > implementors and users should check current literature to ensure that > no recent vulnerabilities have been found in ciphers used within > products. Implementors should also check to see which ciphers are > considered to be relatively stronger than others and should recommend > their use to users over relatively weaker ciphers. It would be > considered good form for an implementation to politely and > unobtrusively notify a user that a stronger cipher is available and > should be used when a weaker one is actively chosen. > > The "none" cipher is provided for debugging and SHOULD NOT be used > except for that purpose. It's cryptographic properties are > sufficiently described in RFC 2410, which will show that its use does > not meet the intent of this protocol. > > The relative merits of these and other ciphers may also be found in > current literature. Two references that may provide information on the > subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these > describe the CBC mode of operation of certain ciphers and the weakness > of this scheme. Essentially, this mode is theoretically vulnerable to > chosen cipher-text attacks because of the high predictability of the > start of packet sequence. However, this attack 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 > > Additionally, another CBC mode attack may be mitigated through the > insertion of packets containing SSH_MSG_IGNORE. Without this > technique, a specific attack may be successful. For this attack > (commonly known as the Rogaway attack) to work, the attacker would > need to know the IV of the next block that is going to be encrypted. > In CBC mode that is the output of the encryption of the previous > block. If the attacker does not have any way to see the packet yet > (i.e it is in the internal buffers of the ssh implementation or even > in the kernel) then this attack will not work. If the last packet has > been sent out to the network (i.e the attacker has access to it) then > he can use the attack. > > In the optimal case an implementor would need to add an extra packet > only if the packet has been sent out onto the network and there are no > other packets waiting for transmission. Implementors may wish to check > to see if there are any unsent packets awaiting transmission, but > unfortunately it is not normally easy to obtain this information from > the kernel or buffers. If there are not, then a packet containing > SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream > every time the attacker knows the IV that is supposed to be used for > the next packet, then the attacker will not be able to guess the > correct IV, thus the attack will never be successfull. > > As an example, consider the following case: > > Client Server > ------ ------ > TCP(seq=x, len=500) -> > contains Record 1 > > [500 ms passes, no ACK] > > TCP(seq=x, len=1000) -> > contains Records 1,2 > > <- ACK > > > (1) The Nagle algorithm + TCP retransmits mean that the two > records get coalesced into a single TCP segment > (2) Record 2 is *not* at the beginning of the TCP segment > and never will be, since it gets ACKed. > (3) Yet, the attack is possible because Record 1 has already > been seen. > > As this example indicates, it's totally unsafe to use the existence > of unflushed data in the TCP buffers proper as a guide to whether > you need an empty packet, since when you do the second write(), > the buffers will contain the un-ACKed Record 1. > > On the other hand, it's perfectly safe to have the following > situation: > > Client Server > ------ ------ > TCP(seq=x, len=500) -> > contains SSH_MSG_IGNORE > > TCP(seq=y, len=500) -> > contains Data > > Provided that the IV for second SSH Record is fixed after the data for > the Data packet is determined -i.e. you do: > read from user > encrypt null packet > encrypt data packet > > > 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 might > start to leak information after 2**32 packets have > been sent. However, following the rekeying > recommendations should prevent this attack. > The transport protocol [1] recommends rekeying after > one gigabyte of data, and the smallest possible > packet is 16 bytes. Therefore, rekeying SHOULD happen > after 2**28 packets at the very most. > > 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. If the random data here (e.g., DH parameters) > are pseudo-random then the PRNG should be cryptographically secure > (i.e., its next output not easily guessed, even when knowing all > previous outputs) and, furthermore, the PRNG should be seeded with some > truly random inputs, or as random as can be available. In any case, > the amount of entropy available to a given client or server sometimes > may be less than what is needed to run the protocol, in which case > either one must resort to PRNGs anyways or refuse to run the protocol. > In practice implementors will generally rely on some PRNG. RFC 1750 > [1750] contains more discussion on this. > > [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > Recommendations for Security", RFC 1750, December 1994. > > > The use of a MAC other than 'none' provides integrity and > authentication. In addition, the transport protocol provides a unique > session identifier (bound in part to pseudo-random data that is part > of the algorithm and key exchange process) that can be used by higher > level protocols to bind data to a given session and prevent replay of > data from prior sessions. For example, the authentication protocol uses > this to prevent replay of signatures from previous sessions. Because > public key authentication exchanges are cryptographically bound to the > session (i.e., to the initial key exchange) they cannot be successfully > replayed in other sessions. Note that the session ID can be made > public without harming the security of the protocol. > > If two session happen to have the same session ID [hash of key > exchanges] then packets from one can be replayed against the other. It > must be stressed that the chances of such an occurrence are, needless > to say, minimal when using modern cryptographic methods. This is all > the more so true when specifying larger hash function outputs and DH > parameters. > > [RJA: I imagine that a sequence number does help preclude replay attacks, > [RJA: but I was hoping that someone else had actually done some analysis > [RJA: that we could cite to justify the claim that this MAC combined with > [RJA: this kind of sequence numbering would actually provide replay > [RJA: attack prevention. > > > 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 during which the client is vulnerable to such a > man-in-the-middle attack. 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 attacks. For example, public-key authentication > is not vulnerable to man-in-the-middle attack as long as the > public-key of the server has been securely distributed to the > clients before the first SSH connection is made. This is because > the signature is made across data that is session specific. The > session specific data between the attacker and server will be > different between the client-to-attacker session and the > attacker-to-server sessions due to the randomness discussed above. > From this, the attacker will not be able to make this attack work > since the attacker will not be able to correctly sign packets > containing this session specific data from the server since he does > not have the private key of that server. > > [RJA: Is this really true and sufficient ? > > 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 a reliable association of the binding > between a host and its host keys is inherently insecure and is NOT > RECOMMENDED. It may however be necessary in non-security critical > environments, and will still provide protection against passive > attacks. Implementors of protocols and applications running on top of > this protocol should keep this possibility in mind. > > 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.1.7 Forward Secrecy > > It should be noted that the Diffie-Hellman key exchanges may provide > perfect forward secrecy (PFS). PFS is essentially defined as the > cryptographic property of a key-establishment protocol in which the > compromise of a session key or long-term private key after a given > session does not cause the compromise of any earlier session. > [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using > diffie-hellman-group1-sha1 are secure even if private > keying/authentication material is later revealed, but not if the > session keys are revealed. So, given this definition of PFS, SSHv2 > does have PFS. It is hoped that all other key exchange mechanisms > proposed and used in the future will also provide PFS. This property > is not commuted to any of the applications or protocols using SSH as a > transport however. The transport layer of SSH provides > confidentiality for password authentication and other methods that > rely on secret data. > > Of course, if the DH private parameters for the client and server and > revealed then the session key is revealed, but these items can be > thrown away after the key exchange completes. It's worth pointing out > that these items should not be allowed to end up on swap space and > that they should be erased from memory as soon as the key exchange > completes. > > > [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom > Glossary 2000", American National Standards Institute, Inc., Approved > February 28, 2001. > > > 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 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 confidentiality, 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 > > 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 the local security > policy that should apply 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. > > [Nico: What if no policy is available? > > > 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 enforceable > policy. The use of smartcards, or other technology > to make passphrases an enforceable policy is suggested. > > The server could require both password and public-key > authentication, however, this requires the client > to expose its password to the server (see section on > password authentication below.) > > 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 > compromises. > > 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 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 compromised. > There are no mitigating factors for this. > > If the client end point has been compromised, and the server > fails to stop the attacker at the authentication protocol, > all services exposed (either as subsystems or through forwarding) > will be vulnerable to attack. Implementors SHOULD provide > mechanisms for administrators to control which services > are exposed to limit the vulnerability of other services. > > These controls might include controlling which machines and > ports can be target in 'port-forwarding' operations, which > users are allowed to use interactive shell facilities, or > which users are allowed to use exposed subsystems. > > 11.3.2 Proxy forwarding > > The SSH connection protocol allows for proxy forwarding of other > protocols such as SNMP, POP3, and HTTP. This may be a concern for > network administrators who wish to control the access of certain > applications by users located outside of their physical location. > Essentially, the forwarding of these protocols may violate site > specific security policies as they may be undetectably tunneled > through a firewall. Implementors SHOULD provide an administrative > mechanism to control the proxy forwarding functionality so that > site specific security policies may be upheld. > > In addition, a reverse proxy forwarding functionality > is available, which again can be used to bypass firewall > controls. > > As indicated above, end-point security is assumed during > proxy forwarding operations. Failure of end-point security > will compromise all data passed 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. More information > about the use of the X11 magic cookie may be found in many of the > available manual references and implementation guides for X11. For > example, viewing the manual page for "xauth" in BSD systems may be one > place to start. > > 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 administrators should, as a matter of course, use > X11 security mechanism to prevent unauthorized use of > the X11 server. > > [RJA: Which "X11 security mechanism" is meant ? > [RJA: Also, please add a citation for that mechanism. > > [JG: Well, I didn't have a particular one in mind. The > [JG: advice is to use any X11 security mechanism. I'd > [JG: be willing to remove the paragraph. > [RJA: I'd like to keep text encouraging folks to use as much > [RJA: security as they can. I'm not an expert on the security > [RJA: properties of X11. I was thinking that there probably were > [RJA: some specific security mechanisms (e.g. my vague recollection > [RJA: of the MIT-magic-cookie hack noted above) that we ought > [RJA: to mention and cite. > > > ===^^^=== New Proposal for Section 11 ===^^^=== > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 30 06:29: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 GAA27617 for ; Wed, 30 Apr 2003 06:29:32 -0400 (EDT) Received: (qmail 1494 invoked by uid 605); 30 Apr 2003 10:32:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1487 invoked from network); 30 Apr 2003 10:32:20 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 30 Apr 2003 10:32:20 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27606; Wed, 30 Apr 2003 06:29:27 -0400 (EDT) Message-Id: <200304301029.GAA27606@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-auth-kbdinteract-05.txt Date: Wed, 30 Apr 2003 06:29:26 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-05.txt Pages : 11 Date : 2003-4-29 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-auth-kbdinteract-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-29164452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-29164453.I-D@ietf.org> --OtherAccess-- --NextPart--