From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 1 02:24:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02968 for ; Fri, 1 Feb 2002 02:24:09 -0500 (EST) Received: (qmail 13630 invoked by uid 605); 1 Feb 2002 07:23:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13534 invoked from network); 1 Feb 2002 07:23:53 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 1 Feb 2002 07:23:53 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 840A53BD01; Fri, 1 Feb 2002 08:23:52 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 3F1646C007; Fri, 1 Feb 2002 08:23:54 +0100 (MET) Date: Fri, 1 Feb 2002 08:22:34 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Joseph Galbraith Cc: Subject: Re: x509 In-Reply-To: <014501c1aa70$82c85270$2800a8c0@test.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 31 Jan 2002, Joseph Galbraith wrote: > > On the subject of whether to use PKCS7 or not I'm not sure what it would > > The only question is, are there some cases where we might not be able > to control it (or where it would be burdensome to execute that > control.) > > If there are, PKCS 7 is a win because even in the face of a hash > algorithm that we can't change to match SHA-1 as specified by the SSH > protocol (for example) we can still work. Hi, Since the PKCS7 packet carries more info it's more "complete", however rfc2459 defines one and only one algorithm-id for DSA keys and PKCS1 defines the format of the signature to contain the algorithm-id (OID) already (if I remember it correctly, it's been a while since I read/implemented it). PKCS7 is seems a bit overkill in this case (or I remember things incorrectly, sorry). Have you (vandyke) implemented x509 host/publickey auth in your client/servers yet? I haven't tried your stuff out in a while, is it available for evaluation on the web (server too?). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 1 11:16:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27876 for ; Fri, 1 Feb 2002 11:16:06 -0500 (EST) Received: (qmail 23353 invoked by uid 605); 1 Feb 2002 16:16:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23345 invoked from network); 1 Feb 2002 16:16:03 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 1 Feb 2002 16:16:03 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA08483 for ietf-ssh@netbsd.org; Fri, 1 Feb 2002 17:16:02 +0100 (MET) Date: Fri, 1 Feb 2002 17:16:02 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: SSH_MSG_USERAUTH_PASSWD_CHANGEREQ Message-ID: <20020201161601.GA8456@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list draft-ietf-secsh-userauth-13.txt says: Normally, the server responds to this message with success or failure. However, the server MAY also respond with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the software client SHOULD request a new password from the user, and send a new request using the following message. The client may also send this message instead of the normal password authentication request without the server asking for it. Does this mean a client has to send a reply to this message? or is it ok to ignore the request? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 1 11:40:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02615 for ; Fri, 1 Feb 2002 11:40:47 -0500 (EST) Received: (qmail 27059 invoked by uid 605); 1 Feb 2002 16:40:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27052 invoked from network); 1 Feb 2002 16:40:42 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 1 Feb 2002 16:40:42 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 467222; Fri, 01 Feb 2002 09:47:01 -0700 Message-ID: <01b701c1ab3e$e24a3280$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Markus Friedl" , References: <20020201161601.GA8456@faui02> Subject: Re: SSH_MSG_USERAUTH_PASSWD_CHANGEREQ Date: Fri, 1 Feb 2002 09:38:31 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > draft-ietf-secsh-userauth-13.txt says: > > Normally, the server responds to this message with success or > failure. However, the server MAY also respond with > SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. > > byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > string prompt (ISO-10646 UTF-8) > string language tag (as defined in [RFC1766]) > > In this case, the software client SHOULD request a new password from > the user, and send a new request using the following message. The > client may also send this message instead of the normal password > authentication request without the server asking for it. > > Does this mean a client has to send a reply to this message? > or is it ok to ignore the request? If the client ignores this message, it must do so by selecting another authentication mechanism -- the server hasn't sent a USERAUTH_SUCCESS yet. Perhaps the text could be changed to be more clear: Normally, the server responds to this message with success or failure. However, the server MAY also indicate that the request failed because the password must be changed by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 1 20:26:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15658 for ; Fri, 1 Feb 2002 20:26:17 -0500 (EST) Received: (qmail 6800 invoked by uid 605); 2 Feb 2002 01:26:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6793 invoked from network); 2 Feb 2002 01:26:15 -0000 Received: from mail3.panix.com (166.84.0.167) by mail.netbsd.org with SMTP; 2 Feb 2002 01:26:15 -0000 Received: from panix1.panix.com (panix1.panix.com [166.84.1.1]) by mail3.panix.com (Postfix) with ESMTP id 23FE798380; Fri, 1 Feb 2002 20:26:15 -0500 (EST) Received: (from tls@localhost) by panix1.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g121QF607777; Fri, 1 Feb 2002 20:26:15 -0500 (EST) Date: Fri, 1 Feb 2002 20:26:15 -0500 From: Thor Lancelot Simon To: Darren Reed , secureshell@securityfocus.com Subject: Re: Which protocol is better, version 1 or 2? Advantages disadva ntages? Message-ID: <20020202012615.GA6966@rek.tjls.com> Reply-To: tls@rek.tjls.com References: <20020202005704.GA1601@rek.tjls.com> <200202020108.MAA19464@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202020108.MAA19464@caligula.anu.edu.au> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Feb 02, 2002 at 12:08:51PM +1100, Darren Reed wrote: > > The package I am referring to is: > > http://ettercap.sourceforge.net So, I'm looking at the source code to that package. So far as I can tell, it runs a pretty ordinary man-in-the-middle attack (it can also MITM the SSL protocol). It appears that the only reason it doesn't currently work with SSHv2 is that the authors didn't bother to write the code to encode/ decode v2 packets. Yet. Note that this kind of attack will trigger a "HOST KEY HAS CHANGED!" message if run against a host you've already talked to. However, since, unlike SSL, no SSH implementation I'm aware of can really interact with a real public-key infrastructure, there is *NO WAY* you can avoid this kind of attack when connecting to a host you've never talked to before. Again, this is v1/v2 independent; it is indicative of a severe flaw in the way SSH and similar public-key-based protocols are used on the Internet: nobody wants to pay for (or have the bother of using) root-signed certificates for all of their machines, but without a way to validate a certificate you will always be vulnerable to man-in-the-middle attacks. Frankly, I am very surprised it's taken this long for a kit for attacking SSH to appear. -- Thor Lancelot Simon tls@rek.tjls.com But as he knew no bad language, he had called him all the names of common objects that he could think of, and had screamed: "You lamp! You towel! You plate!" and so on. --Sigmund Freud From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 07:22:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20103 for ; Mon, 4 Feb 2002 07:22:18 -0500 (EST) Received: (qmail 13700 invoked by uid 605); 4 Feb 2002 12:22:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13679 invoked from network); 4 Feb 2002 12:22:06 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 4 Feb 2002 12:22:06 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20047; Mon, 4 Feb 2002 07:22:03 -0500 (EST) Message-Id: <200202041222.HAA20047@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-15.txt Date: Mon, 04 Feb 2002 07:22:03 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-15.txt Pages : 21 Date : 01-Feb-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-15.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020201164556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020201164556.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 07:22:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20124 for ; Mon, 4 Feb 2002 07:22:40 -0500 (EST) Received: (qmail 13878 invoked by uid 605); 4 Feb 2002 12:22:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13704 invoked from network); 4 Feb 2002 12:22:11 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 4 Feb 2002 12:22: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 HAA20075; Mon, 4 Feb 2002 07:22:09 -0500 (EST) Message-Id: <200202041222.HAA20075@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-12.txt Date: Mon, 04 Feb 2002 07:22:08 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-architecture-12.txt Pages : 15 Date : 01-Feb-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-12.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: <20020201164608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020201164608.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 07:23:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20137 for ; Mon, 4 Feb 2002 07:23:01 -0500 (EST) Received: (qmail 13954 invoked by uid 605); 4 Feb 2002 12:22:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13865 invoked from network); 4 Feb 2002 12:22:17 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 4 Feb 2002 12:22:17 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20091; Mon, 4 Feb 2002 07:22:13 -0500 (EST) Message-Id: <200202041222.HAA20091@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-12.txt Date: Mon, 04 Feb 2002 07:22:13 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-12.txt Pages : 27 Date : 01-Feb-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-12.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: <20020201164619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020201164619.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 07:23:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20150 for ; Mon, 4 Feb 2002 07:23:19 -0500 (EST) Received: (qmail 14055 invoked by uid 605); 4 Feb 2002 12:22:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13869 invoked from network); 4 Feb 2002 12:22:17 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 4 Feb 2002 12:22:17 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20030; Mon, 4 Feb 2002 07:21:58 -0500 (EST) Message-Id: <200202041221.HAA20030@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-14.txt Date: Mon, 04 Feb 2002 07:21:58 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-14.txt Pages : 15 Date : 01-Feb-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-14.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: <20020201164545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020201164545.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:04:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06864 for ; Mon, 4 Feb 2002 17:04:31 -0500 (EST) Received: (qmail 25091 invoked by uid 605); 4 Feb 2002 22:04:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25084 invoked from network); 4 Feb 2002 22:04:27 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 22:04:27 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05549 for ; Mon, 4 Feb 2002 15:04:25 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13396 for ; Mon, 4 Feb 2002 17:04:25 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g14M4PKx027098 for ; Mon, 4 Feb 2002 17:04:25 -0500 (EST) Message-Id: <200202042204.g14M4PKx027098@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG Last Call (third time's the charm?) for SSH core drafts Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Feb 2002 17:04:24 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list A Working Group Last Call begins today and will end in one week for the following four drafts: draft-ietf-secsh-architecture-12.txt draft-ietf-secsh-transport-12.txt draft-ietf-secsh-userauth-14.txt draft-ietf-secsh-connect-15.txt I believe that these documents represent the current consensus of the working group and should be submitted to the IESG for consideration for publication as a Proposed Standard RFC. Comments regarding the content of these documents should be sent to the working group mailing list, . If you believe a change to a document is necessary, please include revised wording along with your comment. This Last Call period extends until February 11th, 2002. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:14:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07020 for ; Mon, 4 Feb 2002 17:14:11 -0500 (EST) Received: (qmail 28509 invoked by uid 605); 4 Feb 2002 22:14:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28502 invoked from network); 4 Feb 2002 22:14:10 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 4 Feb 2002 22:14:10 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29618 for ; Mon, 4 Feb 2002 14:14:09 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA07962 for ; Mon, 4 Feb 2002 14:15:44 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.81.131]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g14ME73g827976; Mon, 4 Feb 2002 14:14:07 -0800 (PST) Message-Id: <200202042214.g14ME73g827976@jurassic.eng.sun.com> Date: Mon, 4 Feb 2002 14:13:54 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts To: ietf-ssh@netbsd.org, sommerfeld@east.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: z5oAtxERwfQIE86a3STeqQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >I believe that these documents represent the current consensus of the >working group and should be submitted to the IESG for consideration >for publication as a Proposed Standard RFC. Based on recent traffic I think we might have one outstanding issue, to do with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Currently the text allows the client to ignore the message and assume SUCCESS (at least that is how I read it). I don't think this is correct and I belive others shared the same concern. Do people want it changed ? Has anyone actually implemented this in either the client or server ? Is it even useful given we have keyboard interactive ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:46:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07489 for ; Mon, 4 Feb 2002 17:46:09 -0500 (EST) Received: (qmail 10576 invoked by uid 605); 4 Feb 2002 22:46:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10569 invoked from network); 4 Feb 2002 22:46:08 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Feb 2002 22:46:08 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 470151; Mon, 04 Feb 2002 15:52:33 -0700 Message-ID: <00b501c1adcd$692778e0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , References: <200202042204.g14M4PKx027098@thunk.east.sun.com> Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Date: Mon, 4 Feb 2002 15:43:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit What about x.509? - Joseph ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Monday, February 04, 2002 15:04 Subject: WG Last Call (third time's the charm?) for SSH core drafts > A Working Group Last Call begins today and will end in one week for > the following four drafts: > > draft-ietf-secsh-architecture-12.txt > draft-ietf-secsh-transport-12.txt > draft-ietf-secsh-userauth-14.txt > draft-ietf-secsh-connect-15.txt > > I believe that these documents represent the current consensus of the > working group and should be submitted to the IESG for consideration > for publication as a Proposed Standard RFC. > > Comments regarding the content of these documents should be sent to > the working group mailing list, . If you believe > a change to a document is necessary, please include revised wording > along with your comment. > > This Last Call period extends until February 11th, 2002. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:46:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07502 for ; Mon, 4 Feb 2002 17:46:17 -0500 (EST) Received: (qmail 10787 invoked by uid 605); 4 Feb 2002 22:46:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10769 invoked from network); 4 Feb 2002 22:46:13 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 22:46:13 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01615 for ; Mon, 4 Feb 2002 15:46:12 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12384; Mon, 4 Feb 2002 17:46:10 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g14Mk9Kx027489; Mon, 4 Feb 2002 17:46:09 -0500 (EST) Message-Id: <200202042246.g14Mk9Kx027489@thunk.east.sun.com> From: Bill Sommerfeld To: Darren Moffat cc: ietf-ssh@netbsd.org, sommerfeld@east.sun.com Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: Your message of "Mon, 04 Feb 2002 14:13:54 PST." <200202042214.g14ME73g827976@jurassic.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Feb 2002 17:46:09 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Based on recent traffic I think we might have one outstanding issue, > to do with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Currently the text allows > the client to ignore the message and assume SUCCESS (at least that is how > I read it). I don't read it that way -- the current text is just plain silent about both client and server behavior should the client not send a password change request. I assume the proposed fix is to say something like: server MAY send an error message and drop the connection if client fails to send a password change request. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:47:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07537 for ; Mon, 4 Feb 2002 17:47:04 -0500 (EST) Received: (qmail 11285 invoked by uid 605); 4 Feb 2002 22:47:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11278 invoked from network); 4 Feb 2002 22:47:01 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 4 Feb 2002 22:47:01 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13306; Mon, 4 Feb 2002 14:46:57 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22539; Mon, 4 Feb 2002 17:46:55 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g14MktKx027514; Mon, 4 Feb 2002 17:46:55 -0500 (EST) Message-Id: <200202042246.g14MktKx027514@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Galbraith" cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: Your message of "Mon, 04 Feb 2002 15:43:48 MST." <00b501c1adcd$692778e0$2800a8c0@test.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Feb 2002 17:46:55 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > What about x.509? i do not want to hold up the core drafts waiting for folks to figure out how to use x.509 with ssh. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:52:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07624 for ; Mon, 4 Feb 2002 17:52:24 -0500 (EST) Received: (qmail 12700 invoked by uid 605); 4 Feb 2002 22:52:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12685 invoked from network); 4 Feb 2002 22:52:11 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 22:52:11 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05314 for ; Mon, 4 Feb 2002 15:52:10 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.105]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA23047 for ; Mon, 4 Feb 2002 14:53:45 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.81.131]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g14Mq93g835196 for ; Mon, 4 Feb 2002 14:52:09 -0800 (PST) Message-Id: <200202042252.g14Mq93g835196@jurassic.eng.sun.com> Date: Mon, 4 Feb 2002 14:51:57 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: v6mcUFgdfav0dMD6SoglxQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >> Based on recent traffic I think we might have one outstanding issue, >> to do with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Currently the text allows >> the client to ignore the message and assume SUCCESS (at least that is how >> I read it). > >I don't read it that way -- the current text is just plain silent >about both client and server behavior should the client not send a >password change request. > >I assume the proposed fix is to say something like: > > server MAY send an error message and drop the connection if > client fails to send a password change request. I could live with that but I would change the MAY to a SHOULD (I think the final outcome is pretty much the same but it is more a hint to where the burden of responsibility should be). Compare this to telnet if you have to change your password you probably can't get past giving a good new password. Actually it might even be better to have it as a MUST since not doing so allows for the potential of a client/server pair that can bypass admin policy and we shouldn't really encourage that. I'm okay with the server ignoring the client sending PASSWD_CHANGEREQ messages. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:54:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07669 for ; Mon, 4 Feb 2002 17:54:47 -0500 (EST) Received: (qmail 14017 invoked by uid 605); 4 Feb 2002 22:54:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14010 invoked from network); 4 Feb 2002 22:54:45 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Feb 2002 22:54:45 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 470182; Mon, 04 Feb 2002 16:01:11 -0700 Message-ID: <00c801c1adce$9dea70e0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , "Darren Moffat" Cc: , References: <200202042246.g14Mk9Kx027489@thunk.east.sun.com> Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Date: Mon, 4 Feb 2002 15:52:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > Based on recent traffic I think we might have one outstanding issue, > > to do with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Currently the text allows > > the client to ignore the message and assume SUCCESS (at least that is how > > I read it). > > I don't read it that way -- the current text is just plain silent > about both client and server behavior should the client not send a > password change request. > > I assume the proposed fix is to say something like: > > server MAY send an error message and drop the connection if > client fails to send a password change request. Saying this would make password a stateful mechanism -- something to be avoided. As things stand, I consider the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ is a special failure message that gives the client a hint about what would be necessary for password authentication to succeed. Any future password request is independent though, regardless of whether is a normal password request or a request that includes a new password. This was the proposed fix: Normally, the server responds to this message with success or failure. However, the server MAY also indicate that the request failed because the password must be changed by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:58:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07725 for ; Mon, 4 Feb 2002 17:58:48 -0500 (EST) Received: (qmail 14761 invoked by uid 605); 4 Feb 2002 22:58:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14754 invoked from network); 4 Feb 2002 22:58:48 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Feb 2002 22:58:48 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 470189; Mon, 04 Feb 2002 16:05:14 -0700 Message-ID: <00d001c1adcf$2e61ee50$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Cc: , References: <200202042246.g14MktKx027514@thunk.east.sun.com> Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Date: Mon, 4 Feb 2002 15:56:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > What about x.509? > > i do not want to hold up the core drafts waiting for folks to figure > out how to use x.509 with ssh. The current draft is woefully underspecified. I think we either have to take it out and put it in it's own document, or add some language that specifies more explicitly how to encode the certificate and signatures into the SSH protocol. If we want to put it in it's own document, that's fine -- but I think it would be a mistake to proceed with it in the main document as underspecified as it is. A poor, ambiguous specification is worse than none at all. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 17:59:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07755 for ; Mon, 4 Feb 2002 17:59:35 -0500 (EST) Received: (qmail 15135 invoked by uid 605); 4 Feb 2002 22:59:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15126 invoked from network); 4 Feb 2002 22:59:34 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 22:59:34 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09795 for ; Mon, 4 Feb 2002 15:59:34 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14469; Mon, 4 Feb 2002 17:59:31 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g14MxVKx027837; Mon, 4 Feb 2002 17:59:31 -0500 (EST) Message-Id: <200202042259.g14MxVKx027837@thunk.east.sun.com> From: Bill Sommerfeld To: Darren Moffat cc: ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: Your message of "Mon, 04 Feb 2002 14:51:57 PST." <200202042252.g14Mq93g835196@jurassic.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Feb 2002 17:59:31 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Actually it might even be better to have it as a MUST since not doing > so allows for the potential of a client/server pair that can bypass admin > policy and we shouldn't really encourage that. Well, the password policy should be entirely enforced by the server. MUST would rule out a "soft password expiration" policy where the server could strongly suggest, but not require, a password change, for some time interval before the change became mandatory.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:00:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07791 for ; Mon, 4 Feb 2002 18:00:56 -0500 (EST) Received: (qmail 15789 invoked by uid 605); 4 Feb 2002 23:00:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15780 invoked from network); 4 Feb 2002 23:00:49 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 23:00:49 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10597 for ; Mon, 4 Feb 2002 16:00:47 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA26298 for ; Mon, 4 Feb 2002 15:02:22 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.81.131]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g14N0k3g837125 for ; Mon, 4 Feb 2002 15:00:46 -0800 (PST) Message-Id: <200202042300.g14N0k3g837125@jurassic.eng.sun.com> Date: Mon, 4 Feb 2002 15:00:33 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: F6az5V3KSvYD5msYwziJJg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >This was the proposed fix: > > Normally, the server responds to this message with success or > failure. However, the server MAY also indicate that the > request failed because the password must be changed by responding > with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. > > byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > string prompt (ISO-10646 UTF-8) > string language tag (as defined in [RFC1766]) > > In this case, the client MAY continue with a different > authentication method, or request a new password from > the user and retry password authentication using the > following message. The client MAY also send this message > instead of the normal password authentication request > without the server asking for it. That sounds okay to me, though I would rather that the "the server MAY" be stronger: SHOULD or MUST. I guess what I'm saying is that it either is or isn't a failure making it a maybe opens up for different implementations and potentailly different user experiences on different client/server pairs. I just want it to be clear that this is actually a failure condition. Joseph, do you have this implemented on either side ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:03:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07859 for ; Mon, 4 Feb 2002 18:03:21 -0500 (EST) Received: (qmail 16235 invoked by uid 605); 4 Feb 2002 23:03:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16227 invoked from network); 4 Feb 2002 23:03:19 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 23:03:19 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12900 for ; Mon, 4 Feb 2002 16:03:18 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA27496 for ; Mon, 4 Feb 2002 15:04:53 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.81.131]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g14N3G3g837689; Mon, 4 Feb 2002 15:03:16 -0800 (PST) Message-Id: <200202042303.g14N3G3g837689@jurassic.eng.sun.com> Date: Mon, 4 Feb 2002 15:03:04 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VQOXCuYUA2NuG94NTTd2sw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >> Actually it might even be better to have it as a MUST since not doing >> so allows for the potential of a client/server pair that can bypass admin >> policy and we shouldn't really encourage that. > >Well, the password policy should be entirely enforced by the server. > >MUST would rule out a "soft password expiration" policy where the >server could strongly suggest, but not require, a password change, for >some time interval before the change became mandatory.. I was assuming that case would be dealt with by telling the user their password was going to expire and letting them do the appropriate thing for their system; however that might not be suitable in all cases so I see that MUST is probably too strong. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:04:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07876 for ; Mon, 4 Feb 2002 18:04:05 -0500 (EST) Received: (qmail 16618 invoked by uid 605); 4 Feb 2002 23:04:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16611 invoked from network); 4 Feb 2002 23:04:03 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 4 Feb 2002 23:04:03 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20059; Mon, 4 Feb 2002 15:03:25 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25121; Mon, 4 Feb 2002 18:01:47 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g14N1lKx027868; Mon, 4 Feb 2002 18:01:47 -0500 (EST) Message-Id: <200202042301.g14N1lKx027868@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Galbraith" cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: Your message of "Mon, 04 Feb 2002 15:56:28 MST." <00d001c1adcf$2e61ee50$2800a8c0@test.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 04 Feb 2002 18:01:47 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > but I think it would be a mistake to proceed with it in the main > document as underspecified as it is. A poor, ambiguous > specification is worse than none at all. so, until recently, we had clear consensus to go forward with the admittedly woefully underspecified x.509 wording pending actual implementation experience. do we want more delay? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:04:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07891 for ; Mon, 4 Feb 2002 18:04:19 -0500 (EST) Received: (qmail 16965 invoked by uid 605); 4 Feb 2002 23:04:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16958 invoked from network); 4 Feb 2002 23:04:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Feb 2002 23:04:19 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 470216; Mon, 04 Feb 2002 16:10:42 -0700 Message-ID: <00d701c1adcf$f227e1a0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Darren Moffat" , References: <200202042300.g14N0k3g837125@jurassic.eng.sun.com> Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Date: Mon, 4 Feb 2002 16:01:57 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > Normally, the server responds to this message with success or > > failure. However, the server MAY also indicate that the > > request failed because the password must be changed by responding > > with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. > > > > byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > > string prompt (ISO-10646 UTF-8) > > string language tag (as defined in [RFC1766]) > > > > In this case, the client MAY continue with a different > > authentication method, or request a new password from > > the user and retry password authentication using the > > following message. The client MAY also send this message > > instead of the normal password authentication request > > without the server asking for it. > > That sounds okay to me, though I would rather that the "the server MAY" > be stronger: SHOULD or MUST. I guess what I'm saying is that it either > is or isn't a failure making it a maybe opens up for different implementations > and potentailly different user experiences on different client/server > pairs. I just want it to be clear that this is actually a failure condition. We would probably need to reword as follows to get the strength you want (I'm okay with this.) Normally, the server responds to this message with success or failure. However, if the password has expired the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In anycase the server MUST NOT allow an expired password to be used for authentication. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. > Joseph, do you have this implemented on either side ? Yes. Both sides. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:06:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07918 for ; Mon, 4 Feb 2002 18:06:35 -0500 (EST) Received: (qmail 17371 invoked by uid 605); 4 Feb 2002 23:06:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17364 invoked from network); 4 Feb 2002 23:06:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Feb 2002 23:06:34 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 470222; Mon, 04 Feb 2002 16:12:59 -0700 Message-ID: <00e301c1add0$4381afe0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Cc: References: <200202042301.g14N1lKx027868@thunk.east.sun.com> Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Date: Mon, 4 Feb 2002 16:04:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > but I think it would be a mistake to proceed with it in the main > > document as underspecified as it is. A poor, ambiguous > > specification is worse than none at all. > > so, until recently, we had clear consensus to go forward with the > admittedly woefully underspecified x.509 wording pending actual > implementation experience. > > do we want more delay? We agreed to change the draft in August but it didn't get done, and now there doesn't currently appear to be consensus. I would say create a new working group document for x.509 and remove it from the transport draft. I'll edit it unless Darren wants to. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:08:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07934 for ; Mon, 4 Feb 2002 18:08:25 -0500 (EST) Received: (qmail 17840 invoked by uid 605); 4 Feb 2002 23:08:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17815 invoked from network); 4 Feb 2002 23:08:02 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 4 Feb 2002 23:08:02 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15685; Mon, 4 Feb 2002 16:07:57 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA29451; Mon, 4 Feb 2002 15:09:33 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.81.131]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g14N7u3g838558; Mon, 4 Feb 2002 15:07:57 -0800 (PST) Message-Id: <200202042307.g14N7u3g838558@jurassic.eng.sun.com> Date: Mon, 4 Feb 2002 15:07:44 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts To: ietf-ssh@netbsd.org, galb-list@vandyke.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8KxF/qEbfiCi0F3y1JXY4A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >We would probably need to reword as follows to get >the strength you want (I'm okay with this.) > > Normally, the server responds to this message with success or > failure. However, if the password has expired the server SHOULD > indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. > In anycase the server MUST NOT allow an expired password > to be used for authentication. > > byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > string prompt (ISO-10646 UTF-8) > string language tag (as defined in [RFC1766]) > > In this case, the client MAY continue with a different > authentication method, or request a new password from > the user and retry password authentication using the > following message. The client MAY also send this message > instead of the normal password authentication request > without the server asking for it. I like this wording but it does mean that Bill's "soft password expiration" isn't workable with this. Does anyone else care about this ? >> Joseph, do you have this implemented on either side ? > >Yes. Both sides. > >- Joseph -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:48:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08441 for ; Mon, 4 Feb 2002 18:48:13 -0500 (EST) Received: (qmail 25428 invoked by uid 605); 4 Feb 2002 23:48:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25421 invoked from network); 4 Feb 2002 23:48:12 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 4 Feb 2002 23:48:12 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA23187 for ietf-ssh@netbsd.org; Mon, 4 Feb 2002 23:46:11 GMT Date: Mon, 4 Feb 2002 23:46:11 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Message-ID: <20020204234611.A21942@edinburgh.cisco.com> References: <200202042204.g14M4PKx027098@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200202042204.g14M4PKx027098@thunk.east.sun.com>; from sommerfeld@east.sun.com on Mon, Feb 04, 2002 at 05:04:24PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I've got a slightly different issue with the userauth spec, section 3 states: Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting (preferably with a proper disconnect message sent first to ease troubleshooting). Maybe I'm missing something, but I can't see the need to disconnect in this case, as opposed to simply discarding these messages. At the moment an extra RTT is required to wait for the SSH_MSG_USERAUTH_SUCCESS, assuming that the log in method succeeds. Given that I happen to frequently log into machines over long slow (long RTT) links, it gets painful. Unless there is a valid security reason for disconnecting, I'd suggest a change to: Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so any of these messages received before authentication has completed cannot be processed; if this situation occurs the server MUST silently discard those messages. An alternative would be to generate some sort of error response to the messages. However silent discard serves the purpose of allowing one to pipeline the initial connection protocol messages after a USERAUTH_REQUEST on the assumption that it will succeed, and still automatically deal with the request failing. The failure response indicating that the subsequent higher level protocol messages have been discarded. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 18:53:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08547 for ; Mon, 4 Feb 2002 18:53:55 -0500 (EST) Received: (qmail 28371 invoked by uid 605); 4 Feb 2002 23:53:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28347 invoked from network); 4 Feb 2002 23:53:50 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 4 Feb 2002 23:53:50 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 470327; Mon, 04 Feb 2002 17:00:16 -0700 Message-ID: <010a01c1add6$de8be040$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , "Darren Moffat" Cc: References: <200202042259.g14MxVKx027837@thunk.east.sun.com> Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Date: Mon, 4 Feb 2002 16:51:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > Actually it might even be better to have it as a MUST since not doing > > so allows for the potential of a client/server pair that can bypass admin > > policy and we shouldn't really encourage that. > > Well, the password policy should be entirely enforced by the server. > > MUST would rule out a "soft password expiration" policy where the > server could strongly suggest, but not require, a password change, for > some time interval before the change became mandatory.. I think this would be difficult to achieve because of the way the authentication service works. Quite frankly, in most real world cases, the user is either going to have to change their password or disconnect. The new wording allows the user to pick an alternative to password, but if the user had an alternative they probably would have used it in the first place. On the other hand, the new wording does take the burden of enforcing this away when the server really doesn't need to enforce it -- the server just MUST NOT accept an expired password. The challenge in allowing "soft password expiration" as I understand what you mean is the question of what the client should do if he/she has only a password to authenticate with and they don't want to change it. In this case, the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ message really isn't a failure message (we'd probably want two different messages one that meant you can't authenticate with password until you change it, and one that meant you should change your password soon.) If it isn't a failure message, what's the next step? There is really only one thing that really make sense to me -- The server sends a SUCCESS message or a partial failure. (We need this because of the partial failure case -- the password is okay, but more authentication is necessary.) If the server does this, in the success case it is no longer possible for the user to change their password (authentication messages after success must be ignored.) We could treat the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ as a failure message, in which case how does the client proceed to success? The password mechanism would have to behave differently the second time through (stateful) -- I find this distasteful. If we really wanted to clean this up, we should (and I really don't think we want to do all this now): 1. Allow authentication messages at any time -- requests after success are immediately failed without further checking if they use a different username. Authentication requests after success MAY NOT change the authorization status of the connection. (Processes already running, etc.) Failed requests don't affect the authentication / authorization status. (We need this because the client might have sent a whole bunch of requests without waiting to find out which one would succeed.) The server MAY count failed requests against a authentication attempt counter even after success, though any such counter SHOULD be reset to zero upon success. 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING which included how much time was left before expiration. The server would send this and the usual success or partial failure message. The client would display a "You password will expire in n days. Would you like to change it now?" 3. The client could issue a change request at any time (because of #1) And as long as were making changes like this, we should: 4. Add a message that the server can send to the client to require re-authentication (credentials expired.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 21:29:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10223 for ; Mon, 4 Feb 2002 21:29:44 -0500 (EST) Received: (qmail 26006 invoked by uid 605); 5 Feb 2002 02:29:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25999 invoked from network); 5 Feb 2002 02:29:30 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 5 Feb 2002 02:29:30 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id SAA21646; Mon, 4 Feb 2002 18:29:27 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id SAA22553; Mon, 4 Feb 2002 18:29:27 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g152TRB09413; Mon, 4 Feb 2002 18:29:27 -0800 Date: Mon, 4 Feb 2002 18:29:27 -0800 From: Frank Cusack To: Joseph Galbraith Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Message-ID: <20020204182927.K9212@google.com> References: <200202042259.g14MxVKx027837@thunk.east.sun.com> <010a01c1add6$de8be040$2800a8c0@test.vandyke.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: <010a01c1add6$de8be040$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Mon, Feb 04, 2002 at 04:51:30PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Feb 04, 2002 at 04:51:30PM -0700, Joseph Galbraith wrote: > > > Actually it might even be better to have it as a MUST since not doing > > > so allows for the potential of a client/server pair that can bypass > admin > > > policy and we shouldn't really encourage that. > > > > Well, the password policy should be entirely enforced by the server. > > > > MUST would rule out a "soft password expiration" policy where the > > server could strongly suggest, but not require, a password change, for > > some time interval before the change became mandatory.. > > I think this would be difficult to achieve > because of the way the authentication service works. You mean, "the way it works now". ie, trying to shoehorn in a soft password expiration will be difficult. [ problems with having only a single SSH_MSG for change password ] > We could treat the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > as a failure message, in which case how does the > client proceed to success? The password mechanism > would have to behave differently the second > time through (stateful) -- I find this distasteful. I agree, that would be poor. > If we really wanted to clean this up, > we should (and I really don't think we > want to do all this now): > > 1. Allow authentication messages at any time -- > requests after success are immediately failed > without further checking if they use a different > username. [...] > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > which included how much time was left before > expiration. The server would send this and > the usual success or partial failure message. > The client would display a "You password will > expire in n days. Would you like to change > it now?" This seems superior. > 3. The client could issue a change request at > any time (because of #1) > > And as long as were making changes like this, > we should: > > 4. Add a message that the server can send to > the client to require re-authentication > (credentials expired.) Interesting. I'd just like to note that keyboard-interactive can handle this transparently and cleanly. For the "password" auth type, I think you really do need to implement option #2. Also, I think this should be implemented. Almost all (if not all) modern unices support warning before password expiration; ssh should support this. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 21:32:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10302 for ; Mon, 4 Feb 2002 21:32:44 -0500 (EST) Received: (qmail 26713 invoked by uid 605); 5 Feb 2002 02:32:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26706 invoked from network); 5 Feb 2002 02:32:43 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 5 Feb 2002 02:32:43 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id SAA21939; Mon, 4 Feb 2002 18:32:43 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id SAA24771; Mon, 4 Feb 2002 18:32:42 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g152WgQ09425; Mon, 4 Feb 2002 18:32:42 -0800 Date: Mon, 4 Feb 2002 18:32:42 -0800 From: Frank Cusack To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Message-ID: <20020204183242.L9212@google.com> References: <200202042204.g14M4PKx027098@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200202042204.g14M4PKx027098@thunk.east.sun.com>; from sommerfeld@east.sun.com on Mon, Feb 04, 2002 at 05:04:24PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Feb 04, 2002 at 05:04:24PM -0500, Bill Sommerfeld wrote: > A Working Group Last Call begins today and will end in one week for > the following four drafts: > > draft-ietf-secsh-architecture-12.txt > draft-ietf-secsh-transport-12.txt > draft-ietf-secsh-userauth-14.txt > draft-ietf-secsh-connect-15.txt What about keyboard-interactive? I should have an updated draft in a day's time for review. There is unlikely to be any [serious] contentious issues. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 21:36:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11276 for ; Mon, 4 Feb 2002 21:36:01 -0500 (EST) Received: (qmail 27157 invoked by uid 605); 5 Feb 2002 02:36:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27147 invoked from network); 5 Feb 2002 02:35:59 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 5 Feb 2002 02:35:59 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KDVYW7G41S984INP@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Mon, 04 Feb 2002 19:35:57 -0700 (MST) Date: Mon, 04 Feb 2002 19:35:50 -0700 From: "Dan O'Reilly" Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-reply-to: <20020204182927.K9212@google.com> X-Sender: oreilly@raptor.psccos.com To: Frank Cusack Cc: Joseph Galbraith , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020204193352.01cb1d68@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from galb-list"@vandyke.com> <200202042259.g14MxVKx027837@thunk.east.sun.com> <010a01c1add6$de8be040$2800a8c0@test.vandyke.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 07:29 PM 2/4/2002, Frank Cusack wrote: >On Mon, Feb 04, 2002 at 04:51:30PM -0700, Joseph Galbraith wrote: > > > > Actually it might even be better to have it as a MUST since not doing > > > > so allows for the potential of a client/server pair that can bypass > > admin > > > > policy and we shouldn't really encourage that. > > > > > > Well, the password policy should be entirely enforced by the server. > > > > > > MUST would rule out a "soft password expiration" policy where the > > > server could strongly suggest, but not require, a password change, for > > > some time interval before the change became mandatory.. > > > > I think this would be difficult to achieve > > because of the way the authentication service works. > >You mean, "the way it works now". ie, trying to shoehorn in a soft password >expiration will be difficult. > >[ problems with having only a single SSH_MSG for change password ] > > > We could treat the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > > as a failure message, in which case how does the > > client proceed to success? The password mechanism > > would have to behave differently the second > > time through (stateful) -- I find this distasteful. > >I agree, that would be poor. > > > If we really wanted to clean this up, > > we should (and I really don't think we > > want to do all this now): > > > > 1. Allow authentication messages at any time -- > > requests after success are immediately failed > > without further checking if they use a different > > username. > >[...] > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > which included how much time was left before > > expiration. The server would send this and > > the usual success or partial failure message. > > The client would display a "You password will > > expire in n days. Would you like to change > > it now?" > >This seems superior. > > > 3. The client could issue a change request at > > any time (because of #1) > > > > And as long as were making changes like this, > > we should: > > > > 4. Add a message that the server can send to > > the client to require re-authentication > > (credentials expired.) > >Interesting. > >I'd just like to note that keyboard-interactive can handle this >transparently and cleanly. For the "password" auth type, I think you >really do need to implement option #2. > >Also, I think this should be implemented. Almost all (if not all) >modern unices support warning before password expiration; ssh should >support this. True, they support warning, but how many prompt as option 2 would? From my standpoint, I'm more interested in VMS than UNIX systems, but the same question applies. If none do, this strikes me more as "gilding the lilly"; i.e., putting something in because it's potentially neat to do, rather than useful or being used in the real world. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 21:41:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11357 for ; Mon, 4 Feb 2002 21:41:31 -0500 (EST) Received: (qmail 28110 invoked by uid 605); 5 Feb 2002 02:41:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28103 invoked from network); 5 Feb 2002 02:41:30 -0000 Received: from iron.ibs.com.au (202.14.182.249) by mail.netbsd.org with SMTP; 5 Feb 2002 02:41:30 -0000 Received: from xenon.mel.ibs.com.au (xenon.mel.ibs.com.au [10.3.0.3]) by iron.ibs.com.au (Postfix) with ESMTP id 911CD16C8A; Tue, 5 Feb 2002 13:11:27 +1100 (EST) Date: Tue, 5 Feb 2002 13:17:04 +1100 (EST) From: Damien Miller X-X-Sender: To: Joseph Galbraith Cc: "sommerfeld@east.sun.com" , "ietf-ssh@netbsd.org" Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: <00e301c1add0$4381afe0$2800a8c0@test.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 4 Feb 2002, Joseph Galbraith wrote: > I would say create a new working group > document for x.509 and remove it > from the transport draft. I support this approach. The current spec is too vague to implement. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 22:18:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11719 for ; Mon, 4 Feb 2002 22:18:00 -0500 (EST) Received: (qmail 2698 invoked by uid 605); 5 Feb 2002 03:17:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2691 invoked from network); 5 Feb 2002 03:17:58 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 5 Feb 2002 03:17:58 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id TAA24978; Mon, 4 Feb 2002 19:17:55 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id TAA17713; Mon, 4 Feb 2002 19:17:55 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g153Htj09465; Mon, 4 Feb 2002 19:17:55 -0800 Date: Mon, 4 Feb 2002 19:17:55 -0800 From: Frank Cusack To: "Dan O'Reilly" Cc: Joseph Galbraith , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Message-ID: <20020204191755.M9212@google.com> References: <"from <200202042259.g14MxVKx027837@thunk.east.sun.com> <010a01c1add6$de8be040$2800a8c0@test.vandyke.com> <20020204182927.K9212@google.com> <5.1.0.14.2.20020204193352.01cb1d68@raptor.psccos.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: <5.1.0.14.2.20020204193352.01cb1d68@raptor.psccos.com>; from dano@process.com on Mon, Feb 04, 2002 at 07:35:50PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Feb 04, 2002 at 07:35:50PM -0700, Dan O'Reilly wrote: > At 07:29 PM 2/4/2002, Frank Cusack wrote: > >On Mon, Feb 04, 2002 at 04:51:30PM -0700, Joseph Galbraith wrote: > > > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > > which included how much time was left before > > > expiration. The server would send this and > > > the usual success or partial failure message. > > > The client would display a "You password will > > > expire in n days. Would you like to change > > > it now?" > > > >Also, I think this should be implemented. Almost all (if not all) > >modern unices support warning before password expiration; ssh should > >support this. > > True, they support warning, but how many prompt as option 2 would? From Yeah, you are right, no system (I know of) prompts and then gives you the option to change your password. > my standpoint, I'm more interested in VMS than UNIX systems, but the same > question applies. If none do, this strikes me more as "gilding the lilly"; > i.e., putting something in because it's potentially neat to do, rather > than useful or being used in the real world. I think there does need to be a way to pass the warning message, which currently does not exist in the "password" method. There could be a generic SSH_MSG_USERAUTH_PASSWD_MESSAGE. The PASSWD_EXPIRING message has the advantage that the client can prompt the user to change it now, but the disadvantage of being a very specific message. While in principle I like the general case, the "password" method already has a design of very specific messages, I believe this should continue for consistency. If you want to handle generic/arbitrary messages, use keyboard-interactive. So, in the above, instead of "The client would display ...", it seems better to read "The client would display a warning message, and possibly prompt the user to change the password now". /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 4 23:10:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13505 for ; Mon, 4 Feb 2002 23:10:41 -0500 (EST) Received: (qmail 10999 invoked by uid 605); 5 Feb 2002 04:10:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10992 invoked from network); 5 Feb 2002 04:10:39 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 5 Feb 2002 04:10:39 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KDW27KOEXS984INP@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Mon, 04 Feb 2002 21:10:36 -0700 (MST) Date: Mon, 04 Feb 2002 21:10:05 -0700 From: "Dan O'Reilly" Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-reply-to: <20020204191755.M9212@google.com> X-Sender: oreilly@raptor.psccos.com To: Frank Cusack Cc: Joseph Galbraith , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020204210751.01cdd2e8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from dano"@process.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 08:17 PM 2/4/2002, Frank Cusack wrote: >On Mon, Feb 04, 2002 at 07:35:50PM -0700, Dan O'Reilly wrote: > > At 07:29 PM 2/4/2002, Frank Cusack wrote: > > >On Mon, Feb 04, 2002 at 04:51:30PM -0700, Joseph Galbraith wrote: > > > > > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > > > which included how much time was left before > > > > expiration. The server would send this and > > > > the usual success or partial failure message. > > > > The client would display a "You password will > > > > expire in n days. Would you like to change > > > > it now?" > > > > > >Also, I think this should be implemented. Almost all (if not all) > > >modern unices support warning before password expiration; ssh should > > >support this. > > > > True, they support warning, but how many prompt as option 2 would? From > >Yeah, you are right, no system (I know of) prompts and then gives you the >option to change your password. > > > my standpoint, I'm more interested in VMS than UNIX systems, but the same > > question applies. If none do, this strikes me more as "gilding the lilly"; > > i.e., putting something in because it's potentially neat to do, rather > > than useful or being used in the real world. > >I think there does need to be a way to pass the warning message, which >currently does not exist in the "password" method. There could be a >generic SSH_MSG_USERAUTH_PASSWD_MESSAGE. The PASSWD_EXPIRING message >has the advantage that the client can prompt the user to change it now, >but the disadvantage of being a very specific message. While in principle >I like the general case, the "password" method already has a design of >very specific messages, I believe this should continue for consistency. > >If you want to handle generic/arbitrary messages, use keyboard-interactive. > >So, in the above, instead of "The client would display ...", it seems better >to read "The client would display a warning message, and possibly prompt >the user to change the password now". I would change it to "the client MAY display a warning message...". In VMS, for example, a warning message of that nature would be displayed as part of the normal login sequence. Taking something like that out of sequence, regardless of the fact that its sequence would largely be inconsequential, tends to rile the feathers of many users. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 03:31:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25283 for ; Tue, 5 Feb 2002 03:31:18 -0500 (EST) Received: (qmail 18730 invoked by uid 605); 5 Feb 2002 08:31:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18723 invoked from network); 5 Feb 2002 08:31:16 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 5 Feb 2002 08:31:16 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 883603BD2A; Tue, 5 Feb 2002 09:31:10 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 212DA6C007; Tue, 5 Feb 2002 09:31:09 +0100 (MET) Date: Tue, 5 Feb 2002 09:29:50 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Joseph Galbraith Cc: , Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: <00e301c1add0$4381afe0$2800a8c0@test.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 4 Feb 2002, Joseph Galbraith wrote: > I would say create a new working group document for x.509 and remove > it from the transport draft. I'm in favour of this too (if needed I can help editing it). In there we can iron out the ambiguities with the format of the signature including explicit referral to rfc2459/pkcs1 (see my earlier post on this). However, I think that at least the generic format of signatures should be explicitly stated in the current transport-draft(rfc) the same as the generic format for keys/certs are. Also, the paragraph which starts with the ("buggy") sentence: "The certificate part may have be a zero length string,..." should be clarified to say something like: ... byte[n] key/certificate data The key/certificate data here is a format specific encoding of the public key or certificate. ... Apart from the sentence not beeing correct english (not that I'm the person to write perfect english... :-) it also hints something about a "zero length string" which is not otherwise defined (as Markus has stated previously). Also, why public key AND certificate? A certificate is a public key which has been signed, in which situation would it be useful to have both? (see earlier discussion on possible implementation pitfalls with public key AND certificate, though that might not be an issue). Since the format of signatures has been discussed it's clearly something not obvious from the spec. The ambiguity comes from the explicitly stated format for public keys/certs along with the fact that the signatures for ssh-dss/ssh-rsa are explicitly given and are "hinting" on a similar encoding of signatures too: On the subject of keys/certs it now says: ... Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data ... But it doesn't say anything explicitly about signatures, IMHO we should EITHER add: ... Signatures are encoded as follows: string signature format identifier (same as public key/cert format) byte[n] signature blob in format specific encoding ... OR explicitly write something like: ... Signatures are encoded in an algorithm specific format not necessarily including the format identifier such as: byte[n] signature in format specific encoding. ... Just to avoid the speculations about how signatures should be encoded (apart from the discussion about the specific case of x509 on how it should be encoded). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 03:42:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25373 for ; Tue, 5 Feb 2002 03:42:55 -0500 (EST) Received: (qmail 21233 invoked by uid 605); 5 Feb 2002 08:42:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21226 invoked from network); 5 Feb 2002 08:42:48 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 5 Feb 2002 08:42:48 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA25552; Tue, 5 Feb 2002 09:42:43 +0100 (MET) Date: Tue, 5 Feb 2002 09:42:43 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: Joseph Galbraith , ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Message-ID: <20020205084243.GD25255@faui02> References: <00d001c1adcf$2e61ee50$2800a8c0@test.vandyke.com> <200202042301.g14N1lKx027868@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202042301.g14N1lKx027868@thunk.east.sun.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Feb 04, 2002 at 06:01:47PM -0500, Bill Sommerfeld wrote: > > but I think it would be a mistake to proceed with it in the main > > document as underspecified as it is. A poor, ambiguous > > specification is worse than none at all. > > so, until recently, we had clear consensus to go forward with the > admittedly woefully underspecified x.509 wording pending actual > implementation experience. since the existing x509 implementations are kind of broken, we should not care right now. > do we want more delay? NO. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 04:33:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25841 for ; Tue, 5 Feb 2002 04:33:52 -0500 (EST) Received: (qmail 28106 invoked by uid 605); 5 Feb 2002 09:33:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28099 invoked from network); 5 Feb 2002 09:33:50 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 5 Feb 2002 09:33:50 -0000 Received: from folly.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id KAA29667; Tue, 5 Feb 2002 10:33:45 +0100 (MET) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id D7C4E4564; Tue, 5 Feb 2002 10:33:37 +0100 (CET) Date: Tue, 5 Feb 2002 10:33:37 +0100 From: Markus Friedl To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts Message-ID: <20020205103337.A26861@folly> References: <200202042300.g14N0k3g837125@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200202042300.g14N0k3g837125@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Mon, Feb 04, 2002 at 03:00:33PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Feb 04, 2002 at 03:00:33PM -0800, Darren Moffat wrote: > Joseph, do you have this implemented on either side ? i have a client side implementation, but i'm not sure what to do if the client user does not want to change the password. probably just ignore the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ and continue with something different. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 06:21:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27281 for ; Tue, 5 Feb 2002 06:21:44 -0500 (EST) Received: (qmail 16960 invoked by uid 605); 5 Feb 2002 11:21:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16953 invoked from network); 5 Feb 2002 11:21:41 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 5 Feb 2002 11:21:41 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id F06233BD2A; Tue, 5 Feb 2002 12:21:39 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id B3D366C007; Tue, 5 Feb 2002 12:21:42 +0100 (MET) Date: Tue, 5 Feb 2002 12:20:22 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Markus Friedl Cc: Darren Moffat , Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts In-Reply-To: <20020205103337.A26861@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 5 Feb 2002, Markus Friedl wrote: > > Joseph, do you have this implemented on either side ? > > i have a client side implementation, but i'm not sure what to do We have it implemented too (in the client side). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 06:23:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27301 for ; Tue, 5 Feb 2002 06:22:56 -0500 (EST) Received: (qmail 17384 invoked by uid 605); 5 Feb 2002 11:22:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17333 invoked from network); 5 Feb 2002 11:22:27 -0000 Received: from tourian.nerim.net (62.4.16.79) by mail.netbsd.org with SMTP; 5 Feb 2002 11:22:27 -0000 Received: from 000 (aboukir-101-2-1-novamed.adsl.nerim.net [62.4.19.16]) by tourian.nerim.net (Postfix) with SMTP id 484D1DA03; Tue, 5 Feb 2002 12:21:47 +0100 (CET) From: =?Windows-1252?Q?C=E9cile_Osta?= To: Subject: CONFERENCE PKC 2002 - URGENT Date: Tue, 5 Feb 2002 12:18:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00AC_01C1AE3F.33AE05E0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: ietf-ssh-owner@netbsd.org Precedence: list C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_00AC_01C1AE3F.33AE05E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Don't miss the: Discover the State of the Art in Cryptography and meet the world specialists and leaders! This conference, organized for the first time in Paris will cover the latest results from the Research community and the industry. PKC 2002 : Workshop on the Practice and Theory in Public Key Cryptography Paris February 12 - 14, 2002 Maison de la Chimie: 28 rue Saint-Dominique 75007 PARIS Register today and benefit of the promotional offer -30% : 478 $ instead of 335 $ (speakers) 634 $ instead of 444 $ (Industry) 239 $ instead of 167 $ (Student) Visit our website: For the details of the program: http://www.novamedia.fr/conferences/conferences/pkc/programmepkc02.html Register today! Conference registration includes: - Admission to all conference sessions. - Proceedings from Springer Verlag. - Tuesday and Wednesday lunchs. - Refreshments during the breaks. Don't be left out! Executives from leading Cryptography companies worldwide attend this prestigious annual event. Register now! NOVAMEDIA ------=_NextPart_000_00AC_01C1AE3F.33AE05E0 Content-Type: application/msword; name="bulletin d'inscription-30%1.doc" Content-Disposition: attachment; filename="bulletin d'inscription-30%1.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAXAAAAAAAAAAA EAAAXgAAAAEAAAD+////AAAAAFsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATSAJBAAA+BK/AAAAAAAAEAAAAAAABAAAShIAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAA AAAMBBYAmmIAAIBXAACAVwAAQggAAAAAAAAFAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAD4DAAAAAAAAPgMAAD4D AAAAAAAAPgMAAAAAAACOAwAAAAAAAI4DAAAAAAAAjgMAABQAAAAAAAAAAAAAAKIDAAAAAAAAlAkA AAAAAACUCQAAAAAAAJQJAAA4AAAAzAkAABwAAADoCQAAJAAAAKIDAAAAAAAAKR0AAHIBAAAYCgAA KAAAAEAKAAAAAAAAQAoAAAAAAABACgAAAAAAAEAKAAAAAAAA7wsAAHYAAABlDAAAJAAAAIkMAAAU AAAABxkAAAIAAAAJGQAAAAAAAAkZAAAAAAAACRkAAGkAAAByGQAAcgEAAOQaAAByAQAAVhwAACQA AACbHgAAIAIAALsgAAA4AAAAehwAAGkAAAAAAAAAAAAAAAAAAAAAAAAAjgMAAAAAAACdDAAAAAAA AAAAAAAAAAAAAAAAAAAAAADNCwAAIgAAAO8LAAAAAAAAnQwAAAAAAACdDAAAAAAAAHocAAAAAAAA IQ8AAAAAAAA+AwAAAAAAAD4DAAAAAAAAQAoAAAAAAAAAAAAAAAAAAEAKAACNAQAA4xwAABYAAAAh DwAAAAAAACEPAAAAAAAAIQ8AAAAAAACdDAAACAIAAD4DAAA4AAAAQAoAAAAAAACOAwAAAAAAAEAK AAAAAAAABxkAAAAAAAAAAAAAAAAAACEPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAnQwAAAAAAAAHGQAAAAAAACEPAADGBgAAIQ8AAAAAAADnFQAA qgAAACMYAAB8AAAAdgMAABgAAACOAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwxgAAAAAAABACgAAAAAAAAwKAAAMAAAAwMP6MZOt wQGiAwAA8gUAAJQJAAAAAAAApQ4AAAAAAACfGAAAEgAAAAAAAAAAAAAAwxgAAEQAAAD5HAAAMAAA ACkdAAAAAAAAsRgAABIAAADzIAAAAAAAAKUOAAB8AAAA8yAAAAAAAADDGAAAAAAAACEPAAAAAAAA ogMAAAAAAACiAwAAAAAAAD4DAAAAAAAAPgMAAAAAAAA+AwAAAAAAAD4DAAAAAAAAAgDZAAAADQgJ CQlQVUJMSUMgS0VZIENSWVBUT0dSQVBISUMgMjAwMiAoUEtDIDIwMDIpDQ1Mb2NhdGlvbjoHTWFp c29uIGRlIGxhIGNoaW1pZQ0yOCBydWUgU2FpbnQtRG9taW5pcXVlLCA3NTAwNyBQYXJpcyCWIEZy YW5jZQ1QaG9uZaA6IDMzICgwKSAxIDQwIDYyIDI3IDAwDUZlYnJ1YXJ5IDEyLCAxMyAmIDE0LCAy MDAyBwcNCVJFR0lTVFJBVE9OIEZPUk0JIC0tLSAgT25seSBvbmUgcmVnaXN0cmFudCBwZXIgcmVn aXN0cmF0aW9uIGZvcm0NUGxlYXNlIGZpbGwgZm9ybSB3aXRoIGEgd29yZCBwcm9jZXNzb3Igb3Ig cHJpbnQgY2xlYXJseSBpbiBDQVBJVEFMIGxldHRlcnMsIHRoZW46DUVtYWlsIG9yIEZheCBDb21w bGV0ZWQgRm9ybSB0bzoJCQlSZWdpc3RyYXRpb24gd2lsbCBiZSBjb21wbGV0ZWQgb25seSB1cG9u IHJlY2VpcHQgb2YgcGF5bWVudC4NQ2VjaWxlIE9TVEEgLSBOT1ZBTUVESUEJCQkJRm9yIG1vcmUg aW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSB3b3Jrc2hvcCwgc2VlDUZheDogICAgICszMyAoADAA KQAgADEAIAA0ADUAIAAzADUAIAAzADkAIAAyADcAIAAJAAkACQAJAGgAdAB0AHAAOgAvAC8AdwB3 AHcALgBpAHAAawBjAC4AbwByAGcADQBFAG0AYQBpAGwAOgAgACAAIAATACAASABZAFAARQBSAEwA SQBOAEsAIABtAGEAaQBsAHQAbwA6AGMAZQBjAGkAbABlAC4AbwBzAHQAYQBAAG4AbwB2AGEAbQBl AGQAaQBhAC4AZgByACAAAQAUAGMAZQBjAGkAbABlAC4AbwBzAHQAYQBAAG4AbwB2AGEAbQBlAGQA aQBhAC4AZgByABUACQAJAAkAEwAgAEgAWQBQAEUAUgBMAEkATgBLACAAIgBoAHQAdABwADoALwAv ACIAIAABABQAaAB0AHQAcAA6AC8ALwAVAHcAdwB3AC4AbgBvAHYAYQBtAGUAZABpAGEALgBmAHIA DQAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAARABhAHYAaQBkAC4AbgBhAGMAYwBhAGMAaABl AEAAZwBlAG0AcABsAHUAcwAuAGMAbwBtAAkACQAJAA0ADQBx8CAARAByAC4AIAAgAHHwIABNAHIA LgAgACAAcfAgAE0AcwAuAA0ACQAJAAkARgBpAHIAcwB0ACAAbgBhAG0AZQAJAAkACQAJAAkACQBM AGEAcwB0ACAAbgBhAG0AZQANAA0AQwBvAG0AcABhAG4AeQAvAE8AcgBnAGEAbgBpAHoAYQB0AGkA bwBuAAkACQAJAAkACQBTAHQAcgBlAGUAdAAgAEEAZABkAHIAZQBzAHMADQANAEMAaQB0AHkACQAJ AAkAUAByAG8AdgAvAFMAdABhAHQAZQAJAAkACQBaAGkAcAAgAG8AcgAgAFAAbwBzAHQAYQBsACAA QwBvAGQAZQAJAAkAQwBvAHUAbgB0AHIAeQANAA0AVABlAGwAZQBwAGgAbwBuAGUAIABOAHUAbQBi AGUAcgAJAAkARgBhAHgAIABOAHUAbQBiAGUAcgAJAAkACQAJAAkACQBFAC0AbQBhAGkAbAANAA0A CQAJAAkADQBQAFIATwBNAE8AVABJAE8ATgBBAEwAIABPAEYARgBFAFIAIAATIDMAMAAlAA0ACQAJ AAkADQANAHHwIABQAEsAQwAgAFIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAARgBlAGUAIAAgAGYA bwByACAAUwBwAGUAYQBrAGUAcgBzAC8AQQBjAGEAZABlAG0AaQBhAG4AcwAvAE4AbwBuAC0AcABy AG8AZgBpAHQAIABvAHIAZwBhAG4AaQB6AGEAdABpAG8AbgBzAAkAMwA4ADAAIACsICAAVABUAEMA CQAkACAAMwAzADUAIAAgACQAIAAqAF8AXwBfAF8AXwBfAF8AXwBfAA0AVABoAGkAcwAgAGkAbgBj AGwAdQBkAGUAcwA6AA0AcAByAGUALQBwAHIAbwBjAGUAZQBkAGkAbgBnAHMAIABhAHQAIAB0AGgA ZQAgAHcAbwByAGsAcwBoAG8AcAANAHAAbwBzAHQALQBwAHIAbwBjAGUAZQBkAGkAbgBnAHMAIABm AHIAbwBtACAAUwBwAHIAaQBuAGcAZQByACAAVgBlAHIAbABhAGcADQBHAGEAbABhACAARABpAG4A ZQByACAADQBNAG8AbgBkAGEAeQAgAGEAbgBkACAAVAB1AGUAcwBkAGEAeQAgAGwAdQBuAGMAaABl AHMAIAANAHIAZQBmAHIAZQBzAGgAbQBlAG4AdABzACAAZAB1AHIAaQBuAGcAIAB0AGgAZQAgAGIA cgBlAGEAawBzAA0ACQANAHHwIABQAEsAQwAgAFIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAARgBl AGUAIAAgAGYAbwByACAASQBuAGQAdQBzAHQAcgB5ACAAQQB0AHQAZQBuAGQAZQBlAHMACQAJAAkA IAA1ADAAMwAgAKwgVABUAEMACQAkACAANAA0ADQAIAAkACoAIABfAF8AXwBfAF8AXwBfAF8AXwAN AFQAaABpAHMAIABpAG4AYwBsAHUAZABlAHMAOgANAHMAYQBtAGUAIABhAHMAIABhAGIAbwB2AGUA DQANAHHwIABQAEsAQwAgAFIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAARgBlAGUAIABmAG8AcgAg AFMAdAB1AGQAZQBuAHQAcwAJAAkACQAJAAkAIAAxADkAMAAgAKwgVABUAEMACQAkADEANgA3ACAA IAAkACAAKgBfAF8AXwBfAF8AXwBfAF8AXwANAFQAaABpAHMAIABpAG4AYwBsAHUAZABlAHMAOgAN AHMAYQBtAGUAIABhAHMAIABhAGIAbwB2AGUAIABiAHUAdAAgAHcAaQB0AGgAbwB1AHQAIABwAG8A cwB0AC0AcAByAG8AYwBlAGUAZABpAG4AZwBzAA0ADQANACoAIABBAGwAbAAgAHQAaABlACAAdABh AHgAZQBzACAAaQBuAGMAbAB1AGQAZQBkACAAaQBuACAARQB1AHIAbwBzACAAYQBuAGQAIABVAFMA IAAkAA0ADQAgACAAIAAgACAAIAAgACAAIABUAG8AdABhAGwAIABBAG0AbwB1AG4AdAAgACAALQAz ADAAJQAgACAAIAAkAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8ADQAgACAAIAAgACAAIAAgAFQA bwB0AGEAbAAgAEEAbQBvAHUAbgB0ACAAEyAzADAAJQAgAKwgIABfAF8AXwBfAF8AXwBfAF8AXwBf AF8AXwBfAA0ADQBQAGwAZQBhAHMAZQAgAGMAaABhAHIAZwBlACAAbQB5ACAACQAgACAAIABx8CAA VgBJAFMAQQAgACAAIAAgACAAIAAgACAAIABx8CAATQBBAFMAVABFAFIAIAAgACAAIAAgACAAIAAg ACAAcfAgAEEATQBFAFIASQBDAEEATgAgAEUAWABQAFIARQBTAFMADQANAA0ADQBDAGEAcgBkAGgA bwBsAGQAZQByABkgcwAgAG4AYQBtAGUAIAAJAAkACQAJACAAIAAgACAAIAAgACAAQwBhAHIAZAAg AG4AdQBtAGIAZQByAAkACQAJAAkACQBFAHgAcABpAHIAYQB0AGkAbwBuACAAZABhAHQAZQANAA0A cfAgAFAAbABlAGEAcwBlACAAZgBpAG4AZAAgAGUAbgBjAGwAbwBzAGUAZAAgAGEAIABjAGgAZQBj AGsAIABvAHIAIABtAG8AbgBlAHkAIABvAHIAZABlAHIAIABwAGEAeQBhAGIAbABlACAAdABvACAA TgBPAFYAQQBNAEUARABJAEEAOgAgADIAMQAsACAAUgB1AGUAIABUAG8AdQByAG4AZQBmAG8AcgB0 ACAANwA1ADAAMAA1ACAAUABhAHIAaQBzACAALQBGAFIAQQBOAEMARQANAHHwIABQAGwAZQBhAHMA ZQAgAGYAaQBuAGQAIABlAG4AYwBsAG8AcwBlAGQAIABhACAAYwBvAHAAeQAgAG8AZgAgAHQAaABl ACAAYgBhAG4AawAvAHcAaQByAGUAIAB0AHIAYQBuAHMAZgBlAHIAIABwAGEAeQBtAGUAbgB0ACAA dABvACAATgBPAFYAQQBNAEUARABJAEEALAAtACAAQgBJAEMAUwAgAEIAYQBuAHEAdQBlACAAUABv AHAAdQBsAGEAaQByAGUAIABJAG4AZAB1AHMAdAByAGkAZQBsAGwAZQAgAGUAdAAgAEMAbwBtAG0A ZQByAGMAaQBhAGwAZQAgAGQAZQAgAGwAYQAgAHIAZQBnAGkAbwBuACAAUwB1AGQAIABkAGUAIABQ AGEAcgBpAHMALAA1ADQALwA1ADYAIABCAGQAIABTAGEAaQBuAHQAIABHAGUAcgBtAGEAaQBuACAA NwA1ADAAMAA1ACAAUABhAHIAaQBzACAARgBSAEEATgBDAEUAIABCAGEAbgBrACAAQwBvAGQAZQAg ADoAIAAxADAAMgAwADcALAAgAEIAcgBhAG4AYwBoACAAQwBvAGQAZQAgADoAIAAwMDA0MSwgQWNj b3VudCBudW1iZXIgMDQwNDEwMjc4MjYgIFJJQiA6IDQyIA0NDQ1EYXRlCQkJCVNpZ25hdHVyZQ0N DQ0NDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAABBAAAAgQA AC4EAAAvBAAANwQAADgEAAA5BAAATQQAAJcEAACxBAAAtAQAALUEAAD2BAAADAUAAB0FAAAlBQAA LgUAADEFAAA5BQAASAUAAGcFAABqBQAApgUAAKcFAADyBQAA8wUAACwGAABSBgAAVAYAAGYGAABo BgAAvgYAAMAGAADCBgAA8gYAAPQGAAD6BgAAAPoA9Ovh69vr1gDUzMnFycXJxcm7tLustKyhjoKh d6Fpd2J3oQAAAAAAAAAMMEoSAG1IDARzSAwEABsCCIEDagAAAAAGCAFDShAAT0oCAFFKAgBVCAEV A2oAAAAAQ0oQAE9KAgBRSgIAVQgBFzYIgUNKEABPSgIAUUoCAG1IDARzSAwEJDBKEgA+KgBCKgBD ShAAT0oCAFFKAgBtSAwEcGgAAAD/c0gMBAAUQ0oQAE9KAgBRSgIAbUgMBHNIDAQADzYIgUNKEABP SgIAUUoCAAxDShAAT0oCAFFKAgAAEjUIgTYIgUNKEABPSgIAUUoCAAAHNQiBQ0oQAARDShAAAA41 CIE2CIFPSgIAUUoCAAADNgiBCE9KAgBRSgIAAAs2CIFtSAwEc0gMBBM2CIFPSgIAUUoCAG1IDARz SAwEEE9KAgBRSgIAbUgMBHNIDAQACjUIgTYIgUNKGAAACQNqAAAAAFUIAQAlAAQAAAEEAAAuBAAA LwQAADkEAABNBAAAegQAAJcEAACyBAAAswQAALQEAAD2BAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAA uQAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAGsAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkPAA3GCQLgEMAhAQAAwDEkAAABAAAAQgAA FiQBFyQBSWYBAAAAApZsAAjWMAAClP/gAzgWAAZMBAAAAAAAAAAAAAAAAAAAAAAABlgSAAAAAAAA AAAAAAAAAAAAABT2AQAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAA AP801gYAAQoDbABh9gMAAAAWDwANxgkC4BDAIQEAAMAWJAEYhMIRGYTM/xsmoCMkAi+EtAAxJABJ ZgEAAAASBAADJAAWJAEYhMIRGYTM/xsmoCMkAi+EtABJZgEAAABhJAAPAAAWJAEYhMIRGYTM/xsm oCMkAi+EtABJZgEAAAAACAQAAyQADcYFAAGwE8BhJAAABAEAAyQBYSQBAAsABAAAQhIAAEcSAABJ EgAA/v7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBA/YEAABIBQAApwUAAPMF AABUBgAAXAcAALQHAAC2BwAA3gcAABgIAAAaCAAAaggAAGwIAADMCAAAzggAACAJAAAiCQAAKgkA AFgJAABgCQAAYgkAAPUAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAANsAAAAA AAAAAAAAAADbAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAADMAAAAAAAAAAAA AAAAwAAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAAAMAA AAAAAAAAAAAAAADMAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAACwAAAAAAAA AAAAAAAArgAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAADMAAAAAAAAAAAAAAAAAAAAAAABBQAADwAA EYTQAiRkGAEAADEkAE7GCAAAAP8YAQAAYITQAgALAAAkZAYBAAAxJABOxggAAAD/BgEAAAMAADEk AAALAAAkZBgBAAAxJABOxggAAAD/GAEAAAAEAAADJANhJAMGAAADJAMxJABhJAMADgAAAyQDJGQY AQABMSQATsYIAAAA/xgBAQBhJAMACRMAD4TQAhGE0AJehNACYITQAgAU+gYAAPwGAAAmBwAAKAcA ACoHAAA4BwAAOgcAAFoHAAC0BwAAtgcAALgHAADEBwAAxgcAANIHAADUBwAA3AcAAN4HAAAYCAAA GggAAGoIAABsCAAAzAgAAM4IAAAgCQAAKgkAAFgJAABcCQAAXgkAAGAJAABkCQAA8gkAAPwJAAD+ CQAAMAoAAGgLAABqCwAAbAsAAG4LAADs2cPs2ezZuK+ouKihqKGak5qTmpOak46KjpOGfHKhaqFq oWpiAAAAAAAAAA8+KgFDShAAT0oDAFFKAwAPNQiBQ0oQAE9KAgBRSgIAEjUIgT4qAUNKEABPSgIA UUoCAAASNQiBPioBQ0oQAE9KAwBRSgMAAAc1CIFDShAABz4qAUNKGAAIT0oCAFFKAgAADENKDABP SgIAUUoCAAAMQ0ocAE9KAgBRSgIAAAxDShAAT0oCAFFKAgAADENKEABPSgMAUUoDAAAQT0oCAFFK AgBtSAwEc0gMBAAUQ0oQAE9KAgBRSgIAbUgMBHNIDAQAKwIIgQNq5wAAAAYIATBKEgA+KgBCKgBD ShAAT0oCAFFKAgBVCAFwaAAAAP8kMEoSAD4qAEIqAENKEABPSgIAUUoCAG1IDARwaAAAAP9zSAwE ACUDagAAAAAwShIAPioAQioAQ0oQAE9KAgBRSgIAVQgBcGgAAAD/ACViCQAAMAoAAE4KAACOCgAA 2goAAPIKAAAqCwAAaAsAAGwLAAAIDAAAJgwAAEIMAABEDAAAzgwAAOwMAABCDQAARA0AAEYNAACc DQAAng0AAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAA AADcAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAACRk GAEAADEkAE7GCAAAAP8YAQAAAA8AAAomAAtGBQANxgcBaAEB0AIGD4TQAjEkAF6E0AIADwAACiYA C0YEAA3GBwFoAQHQAgYPhNACMSQAXoTQAgAPAAAKJgALRgMADcYHAWgBAdACBg+E0AIxJABehNAC AA8AAAomAAtGAQANxgcBaAEB0AIGD4TQAjEkAF6E0AIDAAAxJAAAE24LAABwCwAAyAsAANgLAADa CwAACAwAAEQMAABGDAAASAwAAIoMAACeDAAAoAwAAM4MAACaDQAAsA0AAPYNAAAGDgAAHg4AACAO AAAsDgAALg4AAEoOAAB2DgAAeA4AAJQOAACWDgAAtg4AALgOAADiDgAAXg8AAGAPAAA0EAAANhAA AC0SAAAwEgAAQhIAAEMSAABEEgAARRIAAEkSAABKEgAA9+3m3ube1vft5t7m3ubQy8PLw97Qy77L vsu+y+a+5r7my+a7ALsA5gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABENKGAAACE9KAwBRSgMAAA41CIFPSgIAUUoCAFwIgQAIT0oCAFFKAgAA CzUIgU9KAgBRSgIADz4qAUNKEABPSgMAUUoDAA81CIFDShAAT0oCAFFKAgAMQ0oQAE9KAgBRSgIA ABI1CIE+KgFDShAAT0oCAFFKAgAADz4qAUNKEABPSgIAUUoCAAAong0AAPgNAABKDgAATA4AANwO AADeDgAA4A4AAOIOAABcDwAAXg8AADQQAAAtEgAALhIAAC8SAAAwEgAAQhIAAEMSAABEEgAARRIA AEYSAABHEgAASBIAAEkSAABKEgAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAN4A AAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAADYAAAAAAAA AAAAAAAA2AAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAA AM0AAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADNAAAA AAAAAAAAAAAAzQAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAgA AA3GCAAC4BDAIQECMSQABgAAAyQDMSQAYSQDAAsAACRkBgEAADEkAE7GCAAAAP8GAQAAAAcPAA3G BgLgEMAhADEkAAMAADEkAAoAAAMkAw+EgBYxJABehIAWYSQDABcuABIwABQwChxQAQAfsNAvILDg PSGwgAQisIAEI5CwASSQsAElsAAAF7AgARiwQAIAbh7wYj4AAPdUtAiLG063c1aBop/UYE3/iVBO Rw0KGgoAAAANSUhEUgAAALwAAABLCAIAAABFvHpdAAAABGdBTUEAANkFq7XqlAAAAAlwSFlz//// //////8Byk71FwAAIABJREFUeJzcW2uQHNV1/s65t3tmX9qVhNCD1WNXkiUkgcQjCgJjxCMCzCNK 2dhgR0kqVUkZxyGGhIArTiVFHBtXqMTgVAW7Ejt2KgmugGOCqdiJH2AQz0SqgFCJl3hIMnqAZMHu zkz3vefkR8/M9kx3z+4sihPn/Jjqud333NPnnvvd87hNojW0EKkqE6sS8ogov12VUrek0ajpXs2/ AIhM+skUcYazZp5J3c0XB4SWXtr4yzD5fFqE4UnZVFGXn9PyNF62XX7NyN+4ke7Vdqf9lqoSUYY5 AxDka4MKlFSkH0b2hqCDtlPiWe8nJ7gpt0CIqKB/pynMebqhkc5z3yApNpqseXUct/GOmXGny4eI QJIVu9HSnR6kaPK0aJ66fN/Cye6Kj7gC6zMpNiTi8gfQ+uRlQaKAmpOdL2XTbhoXbcYx5bvlr2Dt TimF1O1K/b/G/wRRzqLNkhV1nZdOGoGmpNYNiNIcprme0lg9PXDqjtqMLP127cORFL37zMCmUKQ8 MCNqW1eCjnPhyeczn/agAEBiCtagT8lCqr6lP0mCMYnPoaqNeZ0SSNqeR9tkJHaTsoasRU9yLpzI aVOhr3Pi7XB6lLx4ZhKz8hQgMbrdsBLqTg+N2e/Mh5yvTN6ozy6rarFRnwCtd+VnzMwRTvOcoeUV bHwzg5ks1nbG1Lb2qR27Ammzy6+jNqTI90rr2TInlkWtWuC6xaVEISRY0nmrahc9q6zWlTT91dOd T9MtonTvW7TvHZ2pe5+mW/2cqHGn5jMZPTVMW4DkIgbaQsS6y5xdImnLaFsibf7vVM5KTrSSHjSH uOB5tOzxk90L4BdIrZDUgmlD2ylBq1B+ptxncsVvhtzTx8jCcU2+Hoq3rXw+6VCfRFxDWYp07K42 N08Aci1tyiAhEGCbL5k2lIas7SmchFvTklo7SqPdpDIWk5Odha5k6OT5pLuACPWOTU+CQGh31aUh Vj3vQph0PghEremZKalD0JC7rii1hNNDKHFD/hQHKOUYfcfNvc4HCk2/WmueRlJXBXkg0KRO4riW bzRT7NkCJDNU75XoKr1xNlWTl7bqzLnN6WYAmhfL5PnpaFd058mmtqgkeTh9PW1W3VA3rKa1Q3WV p+ns1kw5VipPk/Wc2+A6aSNS+ARgoAzwDPZdIir2jdJGIJOjEGVDj0yv1BC5ESVR0UpqfZG0PzF1 3qKzJDOlmSj2f5oSrVrno/zbk3NKaPEPEmhJb1KkKlkMyLoyrZSTeEj9ZVWf5GQTk00mO88lSk9t ouhU3JTYd8t75QfzOUJ2vUYbY06Dpok0uSmMdmqAZe7N3GhIOwzf+tbNtdcScrdkhLM9c3ZQA4ob GANAQB6aLehw00EpkC5/BRNRYi4iwswNh6fdrW7lkztEWzun+WTz0URG1QNoOEb4KSz0aVdX0sSZ vO2JlDO7AWQx24rmGY0W2qKqQg3ItUAR1VRMWgWqyswi7QgEIIsxrR5iHWNUlYQSowGJppZMmqfU UTDtrgqxdoqSWgdtrpACROwymiseLpvt7MiwHT86BZ5d1lI6YH9b7an5rxnleWg6empj3Ag7m9pP HlMLigFKxaUKNbmKyBc3GV+5bZ3VwyiadNSboROB0kFQuktStW6iyDQc7QLB6MTkRf6fURZmlEDO V5Pr5mPJ32QKslwyiZl66KTqRcQYIyIAmG0CM5kVJkRErAlyNOPtJkOlupvMDO9jZlZVZut9Nm8E tFgJt28rrZnJeuYmF4HqoVkLw872120+qUMqq4CPz33ZXOEBTN/cEyaeuACfOiGNh6oqJRt5QdI2 T8JJ2/MAvGdjglrkwrDpQ1iCq9WUrRIRsxJCAgAnKkykjcCewIDo5HXiY/tJUdUS1VQtEVVrnogI jpmNMU1Hnerbk1F4ql8IoLVIVJVBhksmSLxjm+iECAqXjEawqlqLXKlkACiUk1QCkcITqCgLVqSi bnEu0X+2b9G5nGa6pfk3uSg+H0PTlkqQytOkMSaB/0kBYjfRSAELEUENSJpDtG0fAA4ffOfll/YD 5L0zxNVqzJacc8YYAMYYFRpZvmDB/DlCsTEmDAMAzFKrxWGpJB5HDh975eWDE5UIQjbQ2KkxxjB5 LwqUynbd+iUDAz1xrD/64TMBl2JXDUKqTMREzGSZLRt/+hlLB+f0iEcpsAomqIAJXmEAiKBanSCi B7/1+OGD44899LxIkniUhYtnr1i5dPMla0ZXzT10YPyW3/nbqz9w1gc/8j5iB4DZeO+Z2XvXKLBM TSckf5PZqd9tLnhG0d8UcJV0t8bYDGInXkIbhNaB5MnHnr7vG9t3P/PaT469EwRBVImUjPNVQI0J rbVRVA3DEB4XXrphy+XnfPhXNiXdbWAIxhp++Pu77rvnsT279429PW6MFfHM7JwjhAuGZy0bPfn3 P33tGWeNmkD/+os/2PHUnmq1ZrhUq4wzW6G4VOpds274jz67beO5p3Eg2ggqGazwDBACJv8PX/n+ F27/Zq3qo8gFhnp6gpHl8/cdOPzEoy9DH7nzs30rTl1UssHO/3x+ZGTehRdXFy0+mVSISCnZJesO 1s8gtYSNXdaeJC/j3P48xa6SupMuUuaPZk2wd++rL+w58IXb/2XPrjd9XEmcmA9tu2D+or4jh489 s+ONl1446Fxkib33S1YMf/2fbpq/cMCGhqnEDCa3f9+RnU+/+OW//Lc9zxwSrUF6bBj//HtPff/W 9eVeO2to4LT1o4NDs3zsH/rB09f/8ldFwMYRmfVnLtly5fq58/oHh3p/7py1ff3lcmgEqhBoIL7q nH9x9+Hf+8RXX95zgI16x6dtWHrh5avnLxi0oTlp3pz9rx978P7Hdjz5GpRrVTBj3Yb5f3rXdatW LU/ePR33qepUQVj72i0oheU8PNMzQ/knkDpXubM7hs81GpLEyHJNqsnEGsP1UKgeHDGRbc0EtDiY Cjcyunh0dOnxo+ZTN/6Vd97aAGo3X7Zy/YY1s4fmHvvJW1/70kN/c/e3OQjZ8mt791+5+Y///fHP LVg4j4wjGIJdvHjx8OJTmPtuuv5uyz0KpxJcfMV7Vp82smHDqkQwwMHq0SMSx57YBzBbrz1z47nL ly0bPuPstaWSBQwgCmYIwAIYKu3etfeaKz9fGasYY5yYD207e9N7Vw8vmbf+jNNLZQaYIB/Z9v4v 3vGNu+/6bimAq3kfYeyolOxg8x2JSLnDwbGfJZrxeZpmx6wZWZGkrC3QJNUrKtqh7GKtARhwS0YG 4zgGm6jmbGiDgJcumw9I/9DcT932SwcPHf7uAzu9j1xN36wd/fiv3/l39/1uuTckMgEzILW41jdg iIxIEu36crm8ctUpBK9QQhxFtPelfZ/5g78PQvWRfnDb5nPOHznz7NWLl81VxJH31ijBCmKCdV68 j/e9emTrZbdVxqsAh+XSFR84/bzNa9edvnT5ykWECsEoEEOsLX3y1isc3J23P2iMrcbVmhuv+WPN jGLzdwbRU4e8Ttu5gGZjNjeN1kLmtAToPlWT15yqXLaV91O1RcsUNDGmfp87F5UUYIDEQzxLLN6T yFhlwhECBRhci6u3fnrbA/fuDAxb7nFu/PFHdv3Xzhc2nbvRmCQuiFkJ3kaVahCyi1jV1ypVS2WF AVRBLz7/+tZLP/PWkaO9vb2fuPmKhUv616wdXbJkGCLMMAaoI2QJ4MA4S7233HBXZbxaq8Xlcjgw yJvOX7lqzcjylaOQJDlEAJMoWAj9N9/60Ue+99yOJ17xsfW1oGQGVRUBASBD2kzcdFl76nxmOV0r 7lhKe5c0s6oZUFQ3aJXUeolQP4GVjNSsXQN5oZooAovYIY7jOI7V+8gRQ7z3zldqsWPmSnVizknB gvkD+14/aEwQWht7+s4DO8/euFbZMjMDYxPvjFfGaq6mHIo33vvYu/HK20HYr/C7n91/3VV3VMZc X7nvtz55ycLhWRddctbg7PJ49ZjhEICxbK0YsEIIVIvi7T98/rGHn1WlcmjV+/edv8ayWbxkcKJy jCgILIy1DB2fGGcOw5CJ5bdvvvqjWz//6iuHIlerumMAWFnrnwdMkavsNk+Tyy37cKplWoHMJNsC Y/Xc3QlGI4q8ilUL0lgToBHNd6b6KWA4AIHVMAx7ekvVsagnJGUzMDBgjTWmB4D0mHIYrFwzfPDQ 8ep4VZWEhEneevP48PCwIgbM4NC8oaE3hgZmVWNXDjWONQjCgb45otiza991V90RV6OhQfOxG69a PDpry5Zf6Ok1qgRyyUEfIlU1IGVAIeWw/JUvf69/oFwZGzemFEXV9ZtG1p/1nv6+k0QT565+CGqw v99LzXBJEV148cZTlsw/8sb4xFilFMwGADCpAACZumOXyXR3LKg1v+eaLmWTePW5aMnZpHI5qTMx zb/tMtR7ARCoyfrC1L75pb9CKQrgTXNQ66X5NUJLDjRVbuR0uzF10PMSEykbQElUongCkCiu2oAM e6A09k4UhMZF7L1ntgJiZufH2RAh8qAoriokDEN1MSG0Jozi47t37r/u6j+ParVyOfzYTZctHpl1 0SXnlHursU+SyAxU6x/mUQS1HCghOHpkbPuPnrNUTuZs+epTenp5eMnsanyMYFQckSG2gDCJiIjW nPfq8au/ccGD39oRuTiK3wHQrGsm80Qw9TpJhk6cj9x2PK9oT+nmkFCaqB1pGjaU//VCMWmTg2Uu WBlqWxGvWZqpQzeTTbioOrBaGwJBGDAgQaCH3ji6e9deVk7qAEp06rpFzGxNT8LEwhoOmLkaTzBZ kAfJy3uOXXvVX4yPHQ/D8DdvuGB46dwtl27u6QkAWFYYaUkKaLlxaJC3P/wfDBatQUOBrFx18sKF w6VgyFiIMoSIPLEChsCeIwiVw8CL//gNH95y+cYf//hAGPQBTDqp2aZTk6L//crUdPIuHcLmFM38 vI5tpErRVn7KOyMMoO6BAtz8YIqIQFBJHKPYSWS59Cd/+DURgThjDFt79qaFRDRvfr/CUz10n/De u5gIhqkkqD756Cu33fLPE+PHe8oD19940bLl8963+axSj1fUIqecFI+UQY7IiAdICCYMWEEvvXCA meHBpuZUBHTygn6Ht51TgqUkOS4gw6rCYAW5qOZlQomWjM5dOrowdhON7Y8b6EKNXzT002wpPAVQ RMUF3clkf2tjpwJqNnRqeiGs9V5JS7oc0VI3nNFHhs3oyYLz+mupTeI6rDUaDQdEBupVVUnGxytA kOwfd/3Zv37znkd7ggEvTgilUvCL15y3YsUIUy/gAQMwg0ulHtVYVEQmAg7/8evbDYt4u3rdyaMr 5l90yabZcwaSo8ehBQGpGJjBALkEZgh47tnXjeEoiomU1JyyeJBgLQ/U652k9aI6QMSAUzVkvEiv iFPLzCAIlFvPVPw0z85N/3xM0QdorARA2mtGhciU/3bTQTIr6tJbdsqE887ZQIyxyZWXOHmYmQX4 0p3feeqR12bP6f/2/U8c2HeMhERElRYND137a+cNDIZr148IalSvtzGA2FUkqY+pjb0H1dTZsGSf 2XHw/nuf2nrNZucia+MkLRQ7TTvCCk8IQbXABl6892pMqFpltuKcKg3ODpyvkJAiNgi992wEABtl KjkHUAQgdsJGSVmFiCgp4wJIzm80S985SnwXPs2U9W0A0zXZjoAhlJOhbj8LMD1Kn7OxiWuSEiIj 1eR5XklH44aDZN2LiLJa03PvPduDwExMjIdBH/di7ekLl43OO/eCU4dmD5x/4fqenj4GGkgTA8aa XlUvCkuO2DCsqnf+v4t783A7iqJ/vKq6e+Ysd8m+bxjCkrAmAZKwyyoCCmEJqyAqiAiK4CvKq6iI irLIIiLKDqIgyCabgUBIAJVFBFlfICQkAbLee885M9NdVb8/5tx7z91C8PX9/vqZ5z7nztLTM1Nd XV31+VRnqjr/wVc/P+9nN93x351hcLGmgKgKrCqETlUBGTRGMJZSZs4nBERWITVorG21pkxEAIIg zrr6KwMBYOcCQKsCO9uF1MntJEXI0WTYn8fl/wov9/++fFw+VA/ek6jPd3ZfVkcz1R3qnUc7ZaXz xYkGVQbMpVlPOm33ocNa16xu92lGRNVKFhejcROGjhg1bMrmE1RANFVQQkLIACwAB64gomoqagy6 uUfu9vvrF5IlBIsUHn3otS8c99Nrbjojn1VmoSN3cqsqYtYJ5hJrIw6o6gG0i0ZT6Ug9rw9MkIN7 wCAqcyByAhxZF1gBqyo2siWBjhBUNCAKgKlbLUoKoevB+0y5BywbwNM0Hu3pZekH5LuByFSPndg1 ZNfNmkbVIgiK/QCxobfQNESmBtasXZVYwrjP80EXDaA/GHYedgDnnAgQUQgZmYKI7LHnbGuBFQgQ MDeMDeTTVyKifLbFCg6AWAURyUVRUEORIM/eY9wmmx52yU/uBAhxHIuEh+974dhDLrrmlrMBoFgq AhAAI7h86FQgAAZAZ2nmjtOeXvhaCD5NGG30wfvrSUqxGwQg+TkAYA0BeAFAMC53OZFjYUOl2JIo AXaNCwHBAUgjz+jjA2X6sXz7Biw7X2mfy3v8xl7umYaruvzW/QtrzufqD4LTP3+j7iTqD7LTVSxL 0u/NBrL2u2ZPIQQiCGJQCzmYSzRjgSCM4gDAWABE4aTu6ZEEADqjxhyChsCqasgCALOQga+ceYAo X/Hz+xAcsADxow+/fNIxP//VDadEXDYmdEp0AmoRGQAZMoKW0eOaES1gEhdcFsLSd1euXb981Niy IhM4z6lBaylS8AQAEBQMCyNVAY2XAMDCphEqr6oASKQDuT3/bZvmI4M+A13ybwZQsXvE6BxDFBo8 xb3GqYGi9PnIkxdrTdyLwdp5Vg+uU/fu+myQ87FfNAXKhyq1pkBEgIGsqhgiUAAyxcZ6utqNgNZE ACwqhEBEEpw1xf86d16xUPrJ92+JrbPWMWcLHn5pn1nf/ctTF7W0FgFIgREKiABQBAgGigCw9747 nSO/tVQOnBDA229U1q4CUIdSBOLYFAAgJ/h1MibZkgGIAcGgFRXnMgCTm8OIqqAqDiCA+c9gav5z wab///lQOe+p8WGw4d9e70uh7hH2ABCkIgKGnIIHKCAaH2pEqIBBPKJxFCmkzKYzsNXteFBFZp/5 GjNYJBFRJCTJQg2Qvvy1fVnaLvnxA0ZcbNFTumL5qn12/vo9878/aHAREYkcoAeoItmcuzpsRLTP /jPmP/QiVG0cY5r4u25fuN3M0c7FqBFLm3MuH5VDlokSorEmBkosmV9fMX/UmOb9D5pZxzhrQEQR RojISBfXvVdB+b/WNAPRkPtBQG+g9IubUVWj/V/emIdmgAaANeT6vXhgQ6xuLUa2mdAyp4hOUVTB msgYEYiULRlAcADOGs4pRQqMiF0KzFChEJcRFcAgiiqDGmOccwUE+Po3jy3GQ37xs7tqtWDRAsC7 b6/51O7fvf/RHw8f0WTIIEZ5tBzAADCAfPErcx+6/zkkTdOUjL3/zueOOHrPGTtsgUSRLYvW4Zs2 zh/BKjCIO/vL1912y0Nzj9xj+oxp4ycO69avJjf9zIDd+t8JIW+4oo3UHx/v/A37hXs5dTay5FHu HvXkNfTZUy/GMEAMEHxIRVNjVVjJCKJ4z6JBQSSoBSUKmvfYeulhuDH7Wq1GRKiqaokEAISz/EEQ 4OQz9p4wufX0k64BMOIzFr/83XWf2uPse+d/d8TIoWSCNUWBjIDyMWvH2aOPOmG3m3+zEICspY6O 6k9/eMv1vz/LOiGMgNRYdGRraXDOIVWV4ZZrF9x0/X2jRg/farvhH6xaOXx0IZ+MqCCgECHogGaE DtBTP7JshF0yADZvA2UjtE6vSgSll/lS9yBvELOXF5sjDbrv/hEpqPIJiweIiZDIhFAlIg6uWk2i yBJFAqgYiHIPLJHRrrkYAHSaCwbUVSqpigHKcmevAsdRU+7IUQAA2v+AnW++a+hh+/9IFUkpSZMV S/mze5//0MKfDBsxGIAIXB1rB04Bvn3e8U8+9spbb6xSBZ/B0wvfPPyAi3553akTJg5xDgERgGNb JAQE/ckPb7/yortbyi2Hzps+ZHjrtGnTokgJSBTR1mcc2h8Wqu6d6tcQ/PfLx9U3G1s24I/pdag+ b9qIUdeK+gbnQeOhOke181A9CmNt/njpvXc+C0AIMZEyy0vPr+qotJWbLItVFhSy1gCiCHcav41U SAlMCx/7p0KGEAEwIj8x/9XDjtzTWAt1fkmchmTmTptsPnX0yy8uZeZi7ARg+bL22dt87Zzzjjzu C3ugZQMGIKfFSKHEf7j/v46fe8lrr7xnCULQf77wxr67fOvgQ3c6+LAZ206f2DpoyAvPvbF44Uu3 XPfk8nfbm1uiE0/efcKU4TNnTQGqeI+i3lBBNEOETl7w/zbGtGGEjUjoyxEG6KM8GimLfXHLKANJ mzTgYBpL31lSp6bp6cDphdqp302zepuw7s/ArtBg96nUdf3iRS//64Ul8x95/pnFr6kXYzD1SgQM 2acP3mXb6RMP/MyccZMGAViDAkAKwoAWkJmNMcL09FOvvfj86wse/cfCh/7lrGSixVJcrSSO3Kc+ u+OMnaYc8JkZY8YPk6BPPv7SVZfct2jBPxAxeABD1loiYFZWGT226bAj9vj2D45REAUUySzFoMDC 3zrr6jtuWpzUMiQV7nJqE2BmwKggGNhi6vhDj9p+zPhhe+41q3VQKyJgNwkLoG69C32E8dKJqK13 XW0kSkkeM+nCdKJBkNzXjGCwc3Kgnc7ozvgRoIoiIWjntYj1fBeS5yPr7N/SwEjK55V5G0xnexjB CDMYQyxgAFUZjekWbm14il506fyjc6dm7RYay5wrgJwyJ4jUmSOi39gTVH1tXUfblKmjJmwyqGN9 AgQhsEEbJCNK3n172euvvz542NRyuZQxGsqInHLVA3ih2DiWkIX29evXb7nVmJGjitWKJ0IykKUa x9b7dMmS9/7njcFNzcVi2Qbt2Gb6uLGTSpUqawiqDEAIdZejIixbsfK5517YauspaICBU18ljAzq j35+/NzDt7/9lmdefXnlsiXL161JRFBVGHDTLUaNHd8yZYuJU7YcNmLkkBk7Ti63YMYfAhg0BkSI KAggYh1RocqNnEvVHEoMGz1/zj8DInIDJKWLV4rSzzDXywbPT9wQAqZTLfX15aBFZSY2XsEAhhAi QyKcn9XLiSwIKNrpdWhwEzeEjwCgSz12qkS1PbMr9HkehuUr31u3rkPFIqqoF7Eo6pwJISAaNDBh 4uimlmLeJxBIRJAgKKAyKBtTWP7eirVraz6rxsWC994gqTASMYuNCMROmDg8LhZUzKoPVq9dU0XK RJRVDDlQBlABIDBGQJ3fcuqmgDYH3YkAGQQAFclSWLJkycqVH67+sKO9vT1PqmKtGT169JChLaNG DR8zdhSSB3AAgHUvM4iCQQrCiIiiYOojFNXVMACidGrxfoG0vXD8+Z56kmk0iCySAzyiOtSr0RXb +ZugH8D5x/VKd19IhAABlESRiIUNUn/t7OY99TJxemX3rDRkrxBVAtANtE9VnS1kPkGDWZIqaxAW 4TguAAGhASAyasARBSLjOSW0iiBBEZElVSAQBTJGEQgFcvAgKxgOPi5GqmotZQkbY0QzIjIGEZwI iAhgCF4QLSsrJFHcCpJFzoUQAjMZUGYCKwiEysyEEYtHFEQSAQARNdbVUXmWHIsgaUQ25KrFB++Z RRCRgQ1i/iqMIUQUBGscIIrPY3a9exeDGuhUS4hdcWYGFVAQtUgAdRSGQcqUqU+nb5za5Pqp69+6 5wKgMwyH9RnfQLM8BiFjrGrwRDYN3lrigGSkX+HOh7du+chrlh6O8a78NFTHHwF0Qh77woIAADyE CElUERyr5GZAFnwhNqJoyIVQJVMw+auBIAqEFkGYmYxhYUuO2YuIWnAQSWByliVVRYOWCHLxZQ0S ENEgIqOQ5KM7iwZjI1W0lMfYAUip7mQWVeWAQJwzt4lAVQ1aVQVSBJOlKRpQMS5CBEaw+e1CnnoA NH8iRVAWMkBoVeuqV0AR0SCBNgTGe78mJcDcQ9q3syoLEeUdGkECklHqc1od1Fw3MrD+efqIRQ/X cOfn6u0vFhFLJh8XAVFFOjWNzU2ifoRGFRrSSvajUzNfyX9gp/ZtgK71KHUtbQ0q5BhdDyoiDoKK CSAggCjGuJy8pkQAwMoOHYcsADo0gRmYwQoRkYkkpEgRqRUMkjE6UFLLDhEYPasBCaCeTIyaA2mC IcesakAlkCABKhAQMqiqJyUAQmJQytMTkZEc5ieoEhwJA3pAi2qRsty1iIipghVARJb6SycDyqKo AGiQRAQIlYCD5O6lHsN8Z1/vV9OoKmme4FPqCVWUBFgMmoBiUDv1DXSDYHog93rNYhrnaAyqwCan FvVJ5OtVYoIAhKJM7IQyVYsqA/gtOy223jfqkd2TJcXeC5N0SWuvFDJ5XQbAMxjDAYwyOFMPWSvW gTIOJY/LCgB4DtZYAF6x/P35d/1pr4P3HzVmPJiI8gwNKAp8y9W/mjp9xvQddszfTyfghhRcF5ui EzGoAIh5/gcICipqQDNAy6ARGhFQDJRr/zraK7/Q5jwKBNI6pqfxeXNkYGBmNAQAhvXpJxcG0EmT PzFm7HhFytUcGVBBNN1g+64fddXeqd5VNVcPSCQNnkBVtWSCMKIaJFXsNUx0pqTsdnZ0Wc1d0Zhe pgYDm/rD9gaJigCRoOB7y5fPv+tPe332oFGjx6MBgh73rbtFOnEUXTkousSlJ55GOEd651d1Zo3A XpqmS3ScNQpgQHbdfDPnpco+djh56lYHH3vcZ+fNA9QAVSCr4AlIFTNfIyorhPfefvmyH5632dab DRo+MgIhw4AmA++AfnvBhV8+79zpO8z4xvGfr4bkyptvYCIHgpoCGgZLEKT+nQUAGDyB3P6b31x5 /oVxR/GzAAAd50lEQVT3vvrPsjOiyYtPP3vq3KOmTN38kpuvbR09KoKuV5z/RQCWOofX5Gyp/BuJ oiDno5IYkBBuvfKamy+/urquTS2pyie2mvq9iy6cuMVkGznxjNYgmBASREMNQHRBUFUjwHX6rxoB BFBCD4KId1x5zWabb7ntXnOAySEEbvSESa5g8veez2J6CU3OAOjOCKaaw8SUcsxh6Jqcq2o+m0E0 WVKLm1s5S975n79f9qPvbTptXHmwkHOdxpOSQpeTQVXF5BLToCyFgbDRxrXWxAA5s0YRIlUF9F1k ma7JOkBd6Sk4APCcied9Djtiz4M+7YUf/uNd3zvl9LbVa+d96WSDkXE29WCdBSRnRNEYiBRL5ags TKVCUYFYxSBFUASAWpalKatGu+13QAAmKkkQtVbqrANARAOkuaZnQRCvoZJgR7svRWWi+NWXXvjW 57+wxdbTL7vjj62tsQAAWA2MVgGsD17Vx6Y5SSuxKWLkCERFlMAAERIDsNSMcUb0mkt/fu3Fl3zj h+fvfejcoUMH//2JRdddetkLz740ZZsdnHU+SyKKAEBds4IKgAGDCnlsi+s9nQBAMZAjEUCiAngV c/2l15x0xhk77H0A2dgqxFa4DvoSFKsECMKsYBCYyTkBCEk1KhRyMwfrM8O8Q3sEA0BBUmEbWWQj AtbVdY8EDmQiAnBacxhzgVrjdyy4yA0d1DRZQDjLXFRQAaRQS2pxoZxbV5lPyFn0LEjOOsjlr6ep ZFk8gKqQqiIloKT5KGmkDwccAEQkc2gMACKO3WTi9J1nIdKMWXMM6PVXXnHYFz/3+iuvx64wZtJE 44oK/NdHH5uw2eRR4yb4SjXLkswnix+b/9Yrb5Kjo794ogKGLCQ+9Zxkvn3adlu0Jx1pVrXW1tLq Wy/885lnnkLBadO33nG33QOwcBoyD2jQuhASQG9Ilrz5whmHHTl8zLir7rspMuoh5TR948V/PvX4 whBk571323zraZX22j9eeWXI2FFjxo43nqyLl73z1soVKyZPnTp4UFMWMmVhj0uXvnfT5b885dyz D/viUVWfVpPVW82ZevHsX7328ksfrv6f5a8tGT5h7LBRw596bNGwIa3VJNlu1o6oCoQC+OzTT48Y OqzcOnjpG69uutVWr738r7dfecPY6OCTjjCpLn50AYf07XdeXXD/3ba5sPPuc9S41//10nMLnhaQ T2w+ebsdZ0alMieZOErXd9x3+51GZcsZ07MsGzpqyKQJm7z9ztJVK97bds70yrrqay+8vM2uM199 5rnn/v6PEiCVynP223XE+FEAsHrZByuWvDN15vaP3/OXtWvXTpgyafa+u/mU1yarOcvaK+8/Mf/u d19+hSNz/CmfX1tb99ZLb2dZssOuc7LQEaxrX7fu9ef/OXLimJETx0YQiRe06Ih8fbZYV4tBNMu3 fJogmokE1r5bxpp5zlQ1Sf2um0z6/bW/DupVPUt646U/nz5sRJp1nHbkEWcee3yapqos6meOGnnb r68W5UVPLpgzfvTcnWcfNGP66Uccsf3Q4T875xxRlcCzx4y69vJfqPLXjz3mrGOPVfWq/rbfXrPd 0OHzdtv18F13njlixO+v+62qFxHvvfdp4OSGyy6ZPmxIW/uaebvtuucWm7775puqKsqiev2Vl+8y YdyJ++/9uU/uvdPYMffedquo32vK5J9885sikiRVVf/Tb//XXpttETTL16GpeB/E33zZpbNGj6y2 rwmqQTXJaqKsyqL89IJHdx4/8bpLL9pv2223Hzr8gjO/vsuYUcuWL2XNAicrVrw3e8zIm351xeLH Hpo1ZswJe+138I4zzzzu6BnDR15y7rdU/fbDh+wwdsw2TaWZw4fMGTNWNHvg9ttnjxt1yE6zjtp9 j+0Gt/zwjNODsiovffutfbbcbJ8tNj3t6HmzRo2eNW70bVdeFZRv+fUVO48bfeM1V+651bSZI4eq +pkjx35h/31OO/KIz87cbpcxo154epGo/u7XV+w0dtQRc2bP23vX4/bZa8bQYQ/88U5VffqJJ3Yc M+LwPWd9Zsb0o/bcfbuhzX/4zTVZSL972ql7b7uNqBcRUX/3TddvPXjQKy8+n/pMlYOkoizKXWIQ xOdsBAXIQ7u1zh+hmxbaMxghAAbEWiaVWkcNVFLvQWnRk09uvtXWCoYUNFRFUwUMIFKrtlXXKGSc VVRg2rbTv3fZz9nA9RdffNMVVx992hdKgwcjEYS0mq4L4tur6fq2dS8++9eLvn3uaeeeddzXTjGs y1eueOvl1wWyICEJWWwdpxJChgCnHnHk+tWrLrv15pETRnjoYAnPP7H4F+d+79uXXXDAvKM08Plf O/Oq8y/Y97BPf/pz8xbcddeqNV+Oi4W21cmjd/3pkGOOCKGaGTTM4jmgWfTkY5tN28oUnUo7awi1 rJpJoVCygDXfBppce9nFJ5115qZbTBk5Ydz9v799/t23zz3xKER85M7bDNi9P7vvy6++AqTb7bLd F875GgD87pfX/vbCKz5z/BELl7xywGbTTzr/O4efeLy1dtWqpRedd+4nDz7ge1f+QkLtzht+/4v/ Pn+Pg/fabtaOF5xzJhi6beEjxSazZtW6I2fu315bk9Q+7Ghb11GpPnDjzaee+ZURE8e1h9W/W3T3 kNHDLOr6pHbKbvNu+NXlP9hufFu13ak57usnf/LQgxWy0w+Yd9WF39/1wJnVdDlKPHXa1mde8t3I FL8x9/jbb7p6n2P22Wn3HR68444nHr132znbxzZ65P67ttl+2vgpQ2u83Iurso8dAYA04IfyhGSG 0BrjjLHGGGsjZ2NLrr5h1Lg5cCw2SzWEsGLJkr8veuqJBx7+9slffP4vj51w1letjUzkPGIhLgI4 BzFY2xwPUii02GYgs9+Rc9EULBT2P2weep1/z4PNcdE6U7ItBoqoUiqUi6Xy4gf+Mnz4yJO+dpaB FjKt48dutvu+BxIUHJZKUas15SguORcj86vPPr9+3Vpji8aWHRRiGvTCoue32na7w449ObYtpULr 4cecsGbV2mcef3r/T81d+ubyxfcvcqZp0d2Prl7TduTnT4pscxFbIju4ELcaLRPYwaNHkCkjlWPT 5AqtrcXhEbZaKjcVBikWfn7jLcec/NU5ex60yaRtdv30/vfdeFspHlWMRt53yx8OOu7oYUM3GewG W3Jzdt+vEI8oxyMOOvwYE7unH32qXBxWU42g1Noyrrk06okHFvpK7Rvn/chBbO3QeSed8onNNl/4 wMJ1H3Y8t/Cvp579rSGDxhXt2LEjp6hqedCIcnF4S3lobKJbn3j80BNOmvPJ/cs0fPLkbdct7Xhp wZuP3fSIiwlTW47GNMfNauiAuUcVqbVMQ/c98nPrVnS898ba5sLoQpH2P+LoJjPO4dDZe+//zpsr W6Lx+x127KBBwxbe+2izG1tdTYv/sujQE79UcKOa4wlFO2JIcWKzHd9sx7dEY7u2rqwRuYsv1y4M vZmFDYUQ0URFayN7+w3X3379dYIwY6dZP//9Dbvue0CSVoUCZp4lC+AFGRhqIWFNqlwB9BgygBRA Ro4Z7ZnZ15JaOxlbkzQNlRDAgK9U2956581NtpgE4AkAQbievAiFxXOGhhg40zQgXnfHLRef/6Oz jzvmN3+5u3Xw0Ni4F55/5h8vPDdn3LgsrbnYAVJUtE0lO3n61B123fmBe+/Y/eC9Hrn3nu1mbd88 blDQdmZG44RrIUhIs2JUDNlqimJmzbgjZePiokWbSZWMSNou0u4JIYRZ++7y5AN/fuqJB1B0+dKl X9prVg3W1rjdWlrLazmsTyWURxeBfeYrASoUhLEKsBohXrlySS1o8/BSEtqspaA0dtKkpUteffXl vwcNpRElD20AgRGQNK2uXRc+SHl9IlnNr49cASH7cM3qn3zjvKf+/GBmafacXVZ/uGrklPZ1tRUh q4jR1K81kVGQ4aNLWbL+3RVvAaWGKM3WZ/i+KmbazpKmYUXC/OnjDvr91Tef8K0vzb/rz00tpdkH 7ZTKBz6o92kpLqQSClGUNtg01hiTMzYwX/Qgn3UPXJCFkdhL8Hra97537ClfVIbAzJoHbazjOEUC KsUKoiEARyaKsEDqfCaZFwFnQMgEVgEsqlgEFuHYFa1zoFqIyyVTFhHPaMkoos+8i2IFMJYBLQLE ChEXCMx2u+x79o8HfemQI777xa9ddccfCVxTXNxt709efMtNYAjVpmktjuMAaFn2/OxnfvrNb//j 6b899ejC/77yEidlJOssCCi6csrJTnvsfs3Fl4bgmqIiGEAbAxkiJYCISj5TkRixxQQF5E8fPO/6 Cy574u6HwFDriJG773WQqsbQktQ64pqNbCuyOBDPAbBkJE7ZYygbaGWAZtfiyFtoYhTgIEghTTSL mprGWKbYtlhoEQVlbq+kRVtotcNsNFgyidwwUgUs/e6Xly9++NELb7hhxz33UoavzDusgMXBpTGs VioZaYvR2ABFcasYHFIc1J4EL2ozZ2WIJbS+oFkoRmOl0j7vpDN++aNLFj34t3tu+tM+Bx40tDzJ IhQseMLYRkUMAlRwDcNTCCF4YckCp8FLCIHFs/igWePmJc23RDI1wpRZA9aSsdYYJItKErKaig+Q sK8AVxjTamjLfM1n1SCplyxPvMmaMfArz/4djU7e/BNZSIKwFx+SDvS+mrRX29snbDl58YJHV69d lmE7QtWHNoKaQMVLrcaVBKspVL0mYESxMnmbTb96zhnPL37q4u9/p5J+OHbq5k8//vjatvfRMEA1 o5pCEK5UpH33g/YWTc//5tml1uJBRx+8rmMFy3rm9dXkQy/rU1637W47hSy956brUsgyTiq4ulL5 ECB77V/PpVrlkHlTa29bWqt9kITVlWzNjgfsOf++++fffe+BR8+tVlfVkg8yvzYRqUBbW/phlq76 8wN/JK+Tt5hUw7ZCFPuwqpatriRrmkaVOOHnn30i6BovHUl1xYsvvjBpq0ljpgwGkWcf/wvzai8f pv5DJ2G972ivLK8k7ydppa3jnbXVZbV05csv/m3G7B1m7DtDC+0+/jCptIW0uqZ9ScYdiQlpWJ35 Dyuy/LnFCzPVTadvkiXvE5g2XVNJllWgbX11rTWmo7J0VceSQcNws803v/UXF69csmT/ow+spe+t zZZ3+A/W1t5uT9/1uroKK9vCe+v9svV+2bpsKVkTW2sNRYYia601sTWRNVFvU4bifItMJEGKUbmt vWqRRIhsAdWWXMlGRUt24mbT/rbgr6+/8vq6VWsu+cb3DRUMxaBqsdBRyZa89pqEsHzpB+edfs6E cRNm7fPJUnFwdW2lGMUuGhQMGI6aW1uPOvELIdNrfnhZbS2rlu+/9d6br7rRQdFAsWiabYidLVlX NFBkNSU75MiTzzjm1C//4eobnnpo8WeOPJqD/uxr5y1ftka1uPq15Wcf/6WCa3LaPGLohEOOOWb9 sjVzj/98lrnW5tEEzWRam+IRIKWW0sjtt599wmmnX3buz277xTXr11SaZPiTf378zMNP+uuDi63E ErBkW0rlEc3NIyI7yGnLsV88bc2adZVK7YQvn97SNNKawVlClPilry6PtXnt6toNP71qxISxu+z1 qQhKpabys0+86GDI2qXth8w7cdio0Ree8d3KGvEV94vvXPjB0veOPvG0MUO3mLHrnD9cd/Mdv73z gd898JXDTkyAIym2lCe0RiObmluaCiNayuMiM2yTCVNeffFf69+rmaz5j5ff8Y+nnkHrWspjnGk1 gV588p8Whzz3+It3/PKWecd+rhyPGlQas27N2iEtY8qFcWUYNGzoaPVYKI+bOHRLDi1HnHra0rfe 22SzzafvtE9zeeLg4oSmaMyIlk3LhbEWhzXBqGY3vjWa2BpNHBRP6o0R7kLoDchhBi+sqVVrLQT2 kBGjQuoDWls0jg77/NH3XH/D5/b+lGT+uDO/UiwWjSM0ipajgrv7hpsv//FPCyYePGLIj267VpLU RBasExHPHWQMRR4dDhs/4vyrfvaz75z3x9tuKoJDlG9ecmHQaqLegVUQrxggUUjTWpVLECGecs7X /77wyQvPPOui2647/5rLf/bN78ydMV2YXaE4c/fZQolxrODGTBrHhg888RDW9SEUVFgdGooQRdCA 6knnnBo3mRsvv/SKCy4QAQ61XT+1/7Q9Z4SOCpAHSYJUDGAW2owxQ8e0DB3SutuB+6mp1tIk9SlE wRabf3fl1ddcdGEpKg8Z1PKDGy5PfJsh+Op3vv6dr5612ycmCuCipf/672sv+sEp3/jUdttgpk0t 5W9f8qNB48vBdZx/7WXfPvn0i3/wg0EtTUeffNLLz/wNoqzdL6uGtYGxAm1FSBDlqDNOWvT4gsN3 mJMq77THzlNnTrcOM2wHqJFx537ltEp1nfHRtF22+fw5X17PK71b5yKsZR2V6vKoXKwmq7GA1coS MQgAm2851hbiA48/tCNbTtqbVtC1Ykp9j0job5N+dmommqW+6jlj9sqSCYcQVLWWdnjvPWccMpGQ cO3JBx98639e8z4NSSrsk7SjVqvU0o5qUvnHs39d9MjDSVLN3UIdHR01nwXhLEklsPdpkqUiUks7 atW2BQ8/vOiRh9OsQyQE8cyc5oWDiKgE730IGbP3HESEJa3VKiKaJtWFjzy46JGH3nrrzSzLQsh8 ltRq6eG77PTVuYdmacWnmSonnAZVUVYJnvPTqgnXEt/x5IMPLv7L/PffX6HC3qdJUg2cpL4afMoh S30SfPrw3XfMHDb8mScXBGVVrdUq8/9859TmeOFDD770/N8XP/6IqubNq9VqWUjffueNJx9+cNnb b4r6LK21VSt/XfDoYw//uW3VmiRJamk1hBAyL5ymlWpHtbJ61cqtWgf/4fprQ+ZFNa0lqU8C11iS akjUZwsfeuCfz/3Np1mSVJWlVm278fJLt2kdXqkmjz300EvP/y3JahI4KGdZkkomEkLIsuBVNagP IYiENFQu+K+zPvmJyetXfxDEB/GN372vx66Ly90gR/1k5GpkOoioZ2JQS4IMQdkiqLE5MAoSTi3R NjvvAIRpUqFC7MhGkWHWIKIiU6ZOISLEkGkCWTBFIE2TlB2aDNlgsEQJhMhiBrLjLjMz0kqoDHaW 2ROgICsLiakxi4iNLZFBEWEOAMIMAOvTCqayzeztDeURsCoDosOXn3/6ndeXHXTiCZnUDNVCgmKJ sMaqiGCIGFCMcpZJ4Gk7b82KDrWj9gE6B8KKLgexgMFQC0J8z623jthk7Iw526fZGjJcVbbWDi6P FKmO22JsZCatrS4zhciBJScpwNBh5WHDt9XIVCurKTIG0s122hxFM66iZZUsgH3kj/etWv3h5tOm Vlavv/WyawYPadr7kE+KWZ95TkK1HLWGfKFR5UrIpu26hQZdU1sWxRahFOKkArVSE3l5b8bOmwVj kvR9X7BaQzHoAlckRBgJYVrzgQgCk6PKmvb5f7pr94P3Mq1c4ZWq3UDhLphEIzCjZyasDWdaRgEA UYiMYcmIIlQFMIBOIdS8L5AVNA7AoCk1RQYABFOfiAhZi4CxBXR5sBBSFhIxcVkkAHCxUCZFRUlT tsZZVTUU2wJGVOxsvTExaCBl6wgQY0u5DIuSIQrgBaHgjIo48a5Q5HqgMiiQD4xB77/5nnKT+/Qh n4ldWY1zgAxCQILkk4StidGoQRupqXM0RASAjCqjQ1RgYTLgBQoRrly2dOFjC875wY8JmksRA1gX +diWUpMUSoNaC6NUNXJoIIBaJXFBpQiMEqPJgJ2xan0RIwaxORDHICukHXLnL29cteZDDNlenz34 u7+9qrlpnEVDTiInPvOWjCVSkLgQlQEAhEGEhZXLMLSMJTKmpTQREAUg+GAATMGoiBKWWNUaABEL BkhjQaCHHrz+g1Vr95t7tNPWoo1A+iz72PCfan1thN7S0aBdetOgmNlENqSpjYvKYg2kPhgkY4wi GCBRYR+CMFnDzLE1CmSMFRANPvMcFWIVMABJyIpxzMGLiBctFArsM7JGES1QkAAsOYJOEWIXMbOI BGQUzXFijODICFJMToRTnwiCAURhr1xvlaqxEaIhJABhDgEYglIUc5bmmbRYvLV5TgBkZc04x1uF fE0ihSiKgrIRSCWU4pIqi6igShpKxVJ7WjHGMHtrIxSNXSHJKpFzLCJIPsmsNSYyPvHWWmVxziUh OEM1X7FIiga9CoqJnLVWA1trAUCA2jvaW8qlSlIj69B748Bay6AGjKrWfABRY1HSHPGIYAiDqIWs UiuWBnmtiQ8AZCIXxBMY8cHGFhjYZ2jQi0TGiGhkY2upltYEsV+iQp/VcrvLRvCEEQFEWdE4UTFA ogHztSfqK3rV1y80DbImnZVTXRIp78RIOQeApPNoVxqeTuHuBpfUQQIgCJ38krpEK+SI+M57Uect uDM3igDnfAsVbzFWUEBVwDzZQq6Cud6AbrhNBiGCiNkb4wKohS7sfk60CD5wZHOYQD2XlgIDIgAJ CIIqGIKAAAy2y1FJQCxsKCdtdWLCIc+DkYN7hMUbjEVFCai+PgoRUP5+6+YoiAFgIAMEEBisqddv 80oUAICUPRnDKgZtEDbUBb/K34wQcM5y9yqmawWcnpDfnutyd8+eGoeuATHCZAyAZMEXDLB4Ms77 WhQVESAAK+SjHapyTpVgAFU2mH8YzCGFDEwAHjMHRgAJOM9slr8ND15EYqpjNljVog2SeeHIWEUk sB68ESQiBeXAQDYfT1JhRyaXm1S8JVvxacEVMk4c2gDKmQ+mhtYIC/s0jmOLNoAoKAgHVSU06IKy RbKADJkQE5g0JGgLaVazUcwqhOITr6oBXWwMgyZpVoxiZm9sIfiacy4JvmBLAJhCqooG0KINPrUu TiUpUEE1Mxh7CApgAZOQoCAYckYFJFPSwC6KRYVBkcXYOIAPSYaRtSLGRpU0RWsKBjNQFPZkENAA +ZAY67KQxbaQSI3AqmrZxjWuOjUBlZkLrqTACuizxEWuvVYpxQUO3AgLbOROdAuQaFqXmAYG5AaM m65O32+9/Ylad8rTRvrmADTpj82Qls4E4F17+lt3uk+TetyuB1+4q4YcC4WN+/vPLtPZkPq1PR6h 10n9wb+72Cc9HPEbooP0u7tT0/bKLNwrQToCDlRDZ4v7uRwA8hX88vZ3ZffsXOUcO4lb6PtkC6tT 5vql7varmTZAhRl4HOxfbgR8v/v7ldRGLObADWgo3Zjo3jZcY50bVdUGywaEptdpG8nR7C4DZSzv +W5UlfIVHj921gvtaknnGpZKXbhDAFDFj08q7s4Y1VMPDSTXAymVj3ffntl+P/rafrnKPZkXG5kA pjcadwP197nF/7vSi2nQVT7e6iw9S27TSJ9P2BsjPFDp6gT9aqAN6ICBKxxI/Q50xUd84I/upr3W E+m5XxoMw8aDnVSz/jkbvZuIYKAf9Txw6QFE76e1/d2i34LSW2nlTKB+89BsoHSBz6FR03S3qUci 3XqTev7bp8aepNFGmP5/RKvDhnrGfzbfwn84e0NfQtrAd+wq/VJBeh39GA3oNwnXRq922F1PV7GB s27GE0DD0N7rR38V9bFpNmx4N6qigTTKBpid/Tei/54n0nPBT+1K29a3/n9nrUfYSE38cartoV16 Tho2ou8NnKLmfy95AMANl2COkO11b6wv4AN9Ru6Bx/ueje6W7p5q/9/WPf2tVACNbeu9PMlG3GRj TJkNrun4H9RtG1/Vv5Nzb+NWS+g+s6t0f6wGzqX1IYUePTJvUNgYqnnPz99Ny+tJ0av3+J6krw0Y yAPca4AkQtqQvbJHq/p87G4t2CXfDXzEhmfpFYD7Dw2vH6Or9GZVNlaC/azutFFWnfZKXjFArzLS +759x5PO/DSdJ3Qd7f3Su1NZDSRN/eT/aZQVgF4Tq15L1vQvZA2N7i0cfR+pZ22m8ZAioPZfQ2c9 jfu7bbiNX+p4w+3pZbs0aNyP53roM2v5CInJEx429hNFQDAf4a3p86J6BCyZQ85AwO5lNfKz+89P M1DJNceGvQs9x6YNDTc5aqKHG7vh2o/0DwFAQG6MoXRlb8AB3vJAqlsGEJqPO8iSduuzRstvIEP4 Y9Rfn+UNdLDxXnloQ7uo/xsuA3bIfm2anGsPAH1G0A0MqP0LQWO2m34N5D5KZUM9sl+/4gZLV7aV rq+/4bnm/95J/Z+Zdv3flJz6KfDxZ0+N5f8DidzSawVA53cAAAAASUVORK5CYIIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA5wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAGQAAAGMAZQBjAGkAbABl AC4AbwBzAHQAYQBAAG4AbwB2AGEAbQBlAGQAaQBhAC4AZgByAAAA4Mnqefm6zhGMggCqAEupC0AA AABtAGEAaQBsAHQAbwA6AGMAZQBjAGkAbABlAC4AbwBzAHQAYQBAAG4AbwB2AGEAbQBlAGQAaQBh AC4AZgByAAAAlwAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAACAAAAGgAdAB0AHAA OgAvAC8AAADgyep5+brOEYyCAKoAS6kLEgAAAGgAdAB0AHAAOgAvAC8ALwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQA FQAKAAEAaQAPAAMAAAAAAAAAAAAwAABA8f8CADAADAAGAE4AbwByAG0AYQBsAAAAAgAAABAAX0gB BG1ICQRzSAkEdEgMBEIAAUABAAIAQgAMAAcAVABpAHQAcgBlACAAMQAAABEAAQADJAMGJAExJABA JgBhJAMADwA1CIFDShwAT0oCAFFKAgAAPAACQAEAAgA8AAwABwBUAGkAdAByAGUAIAAyAAAADgAC AAMkAgYkAUAmAWEkAg4ANQiBNgiBT0oEAFFKBAA8AANAAQACADwADAAHAFQAaQB0AHIAZQAgADMA AAALAAMABiQBMSQAQCYCAA8ANQiBQ0oQAE9KAgBRSgIAAD4ABEABAAIAPgAMAAcAVABpAHQAcgBl ACAANAAAABEABAADJAEGJAExJABAJgNhJAEACwA2CIFPSgIAUUoCAABYAAVgAQACAFgADAAHAFQA aQB0AHIAZQAgADUAAAAqAAUAAyQBBiQBEYTQAiRkGAEAADEkAEAmBE7GCAAAAP8YAQAAYITQAmEk AQ4ANQiBT0oCAFFKAgBcCIEAAAAAAAAAADIAQUDy/6EAMgAMABEAUABvAGwAaQBjAGUAIABwAGEA cgAgAGQA6QBmAGEAdQB0AAAAAAAAAAAAAAAAAC4AH0ABAPIALgAMAAcARQBuAC0AdADqAHQAZQAA AA0ADwANxggAAuAQwCEBAgAAADgAIEABAAIBOAAMAAwAUABpAGUAZAAgAGQAZQAgAHAAYQBnAGUA AAANABAADcYIAALgEMAhAQIAAAA8AEJAAQASATwADAAOAEMAbwByAHAAcwAgAGQAZQAgAHQAZQB4 AHQAZQAAAAIAEQAMAENKEABPSgIAUUoCADQAVUCiACEBNAAMAA8ATABpAGUAbgAgAGgAeQBwAGUA cgB0AGUAeAB0AGUAAAAGAD4qAUIqAjAAWkABADIBMAAMAAoAVABlAHgAdABlACAAYgByAHUAdAAA AAIAEwAIAE9KBQBRSgUARgBWQKIAQQFGAAwAFQBMAGkAZQBuACAAaAB5AHAAZQByAHQAZQB4AHQA ZQAgAHMAdQBpAHYAaQAAAAwAPioBQioMcGiAAIAAAAAAAAEAAABKCAAA/////wAAAAABAP////8A AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAQAAAAAAAAAAAj//wAAAAAAAAAA SggAAB8AACQAAAAA/////wAAAAABAAAALgAAAC8AAAA5AAAATQAAAHoAAACXAAAAsgAAALMAAAC0 AAAA9gAAAEgBAACnAQAA8wEAACoCAACuAgAA2gIAANsCAADvAgAADAMAAA0DAAA1AwAANgMAAGYD AABnAwAAkAMAAJEDAACVAwAArAMAALADAACxAwAAGAQAACcEAABHBAAAbQQAAHkEAACVBAAAtAQA ALYEAAAEBQAAEwUAACEFAAAiBQAAZwUAAHYFAAChBQAAogUAAKMFAADOBQAAzwUAAPwFAAAlBgAA JgYAAG4GAABvBgAAcAYAAHEGAACuBgAArwYAABoHAAAtCAAALggAAC8IAAAwCAAAQggAAEMIAABE CAAARQgAAEsIAAAIAAAAATAAAAAAAAAAgAAAAIAIAAAAATAAAAAAAAAAgAAAAIA4AAAABDAAAAAA AAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAABDAAAAAAAAAAgAAAAICpAAAADzAAAAAAAAAA gAAAAICpAAAADzAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAAEzAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AIBIAAAABTAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAEgADAAAAAAAAAAgAAAAICYAAEg ADAAAAAAAAAAgAAAAICYAAMgADAAAAAAAAAAgAAAAICYAAQgADAAAAAAAAAAgAAAAICYAAUgADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAUgADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAUgADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAA AICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICY AAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAADzAAAAAAAAAAgAAAAICYAAAAADAA AAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAA AAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAA gAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaQAAAADAAAAAAAAAAgAAA AICaQAAAADAAAAAAAAAAgAAAAICYQAAAADAAAAAAAAAAgAAAAIAKAAAAADAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAABAAAAAQAAAAEAAAABwAAAAAE AAD6BgAAbgsAAEoSAAAKAAAADgAAABAAAAAABAAA9gQAAGIJAACeDQAAShIAAAsAAAANAAAADwAA ABEAAAAABAAASRIAAAwAAAAzAgAAYAIAAHkCAAB9AgAAlAIAAJwCAABKCAAAE1gU/xWAE1gU/xWE DwAA8JgAAAAAAAbwGAAAAAIIAAACAAAADQAAAAEAAAABAAAADgAAAC8AAfBYAAAAYgAH8CQAAAAG Bq9PhKZ4MV0V13f2w7h+c7X/APhJAQAAAAAA/////wAAcABiAAfwJAAAAAYG91S0CIsbTrdzVoGi n9RgTf8Aaj4AAAEAAAAwJAAAAABwAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALw5AAAABAA CPAIAAAAAgAAAA0EAAAPAAPwggAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK 8AgAAAAABAAABQAAAA8ABPBKAAAAsgQK8AgAAAAMBAAAAAoAACMAC/AMAAAABEECAAAA/wEAAAgA EwAi8QYAAAC/AwAAAIAAABDwBAAAAAAAAAAAABHwBAAAAAAAAA0PAATwQgAAABIACvAIAAAAAQQA AAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAAEA AABKCAAADAQAAPj///88AwAAGAoAAGgHAAA0AAAAAAD//wQAAAANAF8ASABsAHQANQAyADkANwAy ADcANwAyADQADQBfAEgAbAB0ADUAMgA5ADcAMgA3ADcAMgA3AA0AXwBIAGwAdAA1ADAAOAA2ADEA OQA3ADQAMgANAF8ASABsAHQANQAwADgANgAxADkANwA0ADMAlgIAAJsCAACpAgAAqQIAAEsIAAAA AAAAAQAAAAIAAEADAABAlwIAAJwCAACqAgAAqgIAAEsIAAAAAAAAVAAAAGMAAACXAAAAsQAAALUA AAAlAQAAJgEAAGcBAABqAQAApgEAAKcBAADyAQAA5AIAAOkCAADrAgAA7gIAAPICAAAMAwAADQMA ADUDAAA2AwAAZgMAAGcDAACQAwAAlQMAAKcDAACoAwAAqwMAALMDAAD5AwAA+gMAAP0DAAD+AwAA /wMAAAAEAAAJBAAAGAQAALQEAAC4BAAA5AQAAOgEAADrBAAA7AQAAPYEAAAEBQAAFwUAABgFAAAh BQAAJAUAAEUFAABLBQAATgUAAE8FAABYBQAAZwUAAKEFAAClBQAAzQUAANgFAADqBQAAAwYAAA8G AAARBgAAFAYAABUGAAAWBgAAJgYAADsGAAA9BgAASgYAAEwGAABbBgAAXQYAAG4GAABxBgAArgYA ALEGAAAaBwAAHAcAAC0IAAAwCAAAQQgAAEIIAABGCAAARwgAAEsIAAAHABwABwAFAAcABQAHAAUA BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABwACAAcAAAAAAHoAAACXAAAAKgIA ALwCAADbAgAA4gIAAJUDAACrAwAArAMAALEDAABtBAAAeAQAAPwFAAAmBgAAMAgAAEEIAABCCAAA RggAAEcIAABLCAAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAcAAgAHAP//FAAA ABIAQQBuAGQAcgBlACAAVwBlAGkAbQBlAHIAcwBrAGkAcgBjAGgAaQBFADoAXABEAG8AYwB1AG0A ZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAQQBkAG0AaQBuAGkAcwB0AHIAYQB0 AG8AcgBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYA dABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABy AGUAZwBfAGYAbwByAG0ALgBhAHMAZAASAEEAbgBkAHIAZQAgAFcAZQBpAG0AZQByAHMAawBpAHIA YwBoAGkARQA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBc AEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEA dABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQBy AHkAIABzAGEAdgBlACAAbwBmACAAcgBlAGcAXwBmAG8AcgBtAC4AYQBzAGQADQBDAGgAcgBpAHMA dABvAGYAIABQAGEAYQByACwARAA6AFwAYwBoAHIAaQBzAHQAbwBmAFwAbwB0AGgAZQByAFwAYwBo AGUAcwBcAGMAaABlAHMAMgAwADAAMQBcAHIAZQBnAF8AZgBvAHIAbQAuAGQAbwBjAAYAVQBTAEUA UgAxADYAMABcAFwAUwBFAFIAVgBFAFUAUgBfAE4AVABcAFUAUwBFAFIAUwBcAFUAcwBlAHIAMgAy AFwAQwBIAEUAUwAgADIAMAAwADEAXAByAGUAZwBfAGYAbwByAG0ALgBkAG8AYwAGAEgARQBSAEEA VQBEADwAVQBTAEUAUgBTADoAQwBvAG0AbQB1AG4AOgBMAGEAZQB0AGkAdABpAGEAOgBDAE8ATgBG AEUAUgBFAE4AQwBFAFMAOgBQAEsAQwA6AGIAdQBsAGwAZQB0AGkAbgAgAGQAJwBpAG4AcwBjAHIA aQBwAHQAaQBvAG4ABQB1AHMAZQByADEAPQBcAFwAUwBFAFIAVgBFAFUAUgBfAE4AVABcAFUAUwBF AFIAUwBcAFUAcwBlAHIAMgAyAFwAUABLAEMAIAAyADAAMAAyAFwAYgB1AGwAbABlAHQAaQBuACAA ZAAnAGkAbgBzAGMAcgBpAHAAdABpAG8AbgAuAGQAbwBjAAUAdQBzAGUAcgAxAEEAXABcAFMARQBS AFYARQBVAFIAXwBOAFQAXABVAFMARQBSAFMAXABVAHMAZQByADIAMgBcAFAASwBDACAAMgAwADAA MgBcAGIAdQBsAGwAZQB0AGkAbgAgAGQAJwBpAG4AcwBjAHIAaQBwAHQAaQBvAG4ALQAzADAAJQAu AGQAbwBjAAUAdQBzAGUAcgAxAGYAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEA dABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABFAG4AcgBl AGcAaQBzAHQAcgBlAG0AZQBuAHQAIABhAHUAdABvAG0AYQB0AGkAcQB1AGUAIABkAGUAYgB1AGwA bABlAHQAaQBuACAAZAAnAGkAbgBzAGMAcgBpAHAAdABpAG8AbgAtADMAMAAlAC4AYQBzAGQABQB1 AHMAZQByADEAZgBDADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAA RABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEUAbgByAGUAZwBpAHMAdABy AGUAbQBlAG4AdAAgAGEAdQB0AG8AbQBhAHQAaQBxAHUAZQAgAGQAZQBiAHUAbABsAGUAdABpAG4A IABkACcAaQBuAHMAYwByAGkAcAB0AGkAbwBuAC0AMwAwACUALgBhAHMAZAAFAHUAcwBlAHIAMQBC AFwAXABTAEUAUgBWAEUAVQBSAF8ATgBUAFwAVQBTAEUAUgBTAFwAVQBzAGUAcgAyADIAXABQAEsA QwAgADIAMAAwADIAXABiAHUAbABsAGUAdABpAG4AIABkACcAaQBuAHMAYwByAGkAcAB0AGkAbwBu AC0AMwAwACUAMQAuAGQAbwBjAAYAsioeBAEACQT/DwAAAAAAAAAAAAAAAAAAAAABALYKhBUBAAkE /w8AAAAAAAAAAAAAAAAAAAAAAQCdDnAsAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAAQ4QUQEACQT/ DwAAAAAAAAAAAAAAAAAAAAABAA02/l0BAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQA+Inx7AQAJBP8P AAAAAAAAAAAAAAAAAAAAAAEAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYF AAFoAQZehGgBYISY/k9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP hGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEA UUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6E aAFghJj+T0oBAFFKAQBvKAABALfwBgAAALYKhBUAAAAAAAAAAAAAAACdDnAsAAAAAAAAAAAAAAAA DTb+XQAAAAAAAAAAAAAAAAEOEFEAAAAAAAAAAAAAAAA+Inx7AAAAAAAAAAAAAAAAsioeBAAAAAAA AAAAAAAAAP//////////////////////////////////BgAAAAAAAAAAAAAAAAAAAP//BgAAAAAA AAAAAAAAAAAAAAAAAAAuAAAALwAAADkAAACyAAAAswAAAEIIAABGCAAASwgAAAAAAAABAAAACAAA AAIBAAACAQAAlgEAAAAAAAABAAAA/0BIUCBMYXNlckpldCA0MDAwIE4gUENMIDYAXFxTRVJWRVVS X05UXEhQNDAwMABIUCBMYXNlckpldCA0MDAwIFNlcmllcyBQQ0wgNgBIUCBMYXNlckpldCA0MDAw IFNlcmllcyBQQ0wgNgBIUCBMYXNlckpldCA0MDAwIE4gUENMIDYAAAAAAAAAAAAEZACUAN4AAx8A AAEAAQD2BPgCAAABAAcA/P8CAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAKgAAAIjv+/0B AAAABAAAAAAAAQAAAAAAAAAuAAAAAAAOAIQDAAAEAIcAegJ6ABIAcwQHAAAAsAQBAAAAsQQCAAAA tAQLAAEA1gQOAAEAsgQEAAAAcAQFAAEA1wQCAQAA2AQDAQAA2gQEAQAA2QQFAQAA2wQGAQAA3AQH AQAA3QQIAQAA3gQJAQAA3wQKAQAA4AQLAQAA4QQMAQAAAAAAAAAAAAAAAAAAAAAAAAkABwABAAcA AQBkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoASFAgTGFzZXJKZXQgNDAw MCBOIFBDTCA2AAAAAAAAAAAABGQAlADeAAMfAAABAAEA9gT4AgAAAQAHAPz/AgABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAAAAACoAAACI7/v9AQAAAAQAAAAAAAEAAAAAAAAALgAAAAAADgCEAwAA BACHAHoCegASAHMEBwAAALAEAQAAALEEAgAAALQECwABANYEDgABALIEBAAAAHAEBQABANcEAgEA ANgEAwEAANoEBAEAANkEBQEAANsEBgEAANwEBwEAAN0ECAEAAN4ECQEAAN8ECgEAAOAECwEAAOEE DAEAAAAAAAAAAAAAAAAAAAAAAAAJAAcAAQAHAAEAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAqAAGAAQCrAwAAqwMAABRq9QDTAdMBqwMAAAAAAACrAwAAAAAAAAJkAAAAAAAA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAABKCAAA8AEACABAAADwAQAGAAAAAPABAAgAAAAA 8AEACgAAAADwAQAMAAAAAPABAA4AAAAA8AEAEAAAAADwAQAkAEAAAP//AQAAAAcAVQBuAGsAbgBv AHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAGAAAA RxaQAQAAAgIGAwUEBQIDBId6AAAAAACACAAAAAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMA eQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6AAAAAACACAAAAAAAAAD/AAAAAAAAAEEAcgBp AGEAbAAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQA aQBuAGcAcwAAAD8mkAEAAAILCgQCAQICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBh AGwAIABCAGwAYQBjAGsAAAA/NZABAAACBwMJAgIFAgQEh3oAAAAAAIAIAAAAAAAAAP8AAAAAAAAA QwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAIgAEAEEAiBgA8NACAABoAQAAAAAvJGImLyRiJhskYiYC AAEAAAAxAQAAzwYAAAEAAwAAAAQAgwAOAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAPAQhAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAAyMAAAEAAZAGQAAAAZAAAAXAgAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAACAAAAAAAAAAAAATKDUQDwEITfAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// EgAAAAAAAAABACAAAAAAAAAAAQBzAAUAdQBzAGUAcgAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAB4AQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA rAAAAAQAAAC4AAAABQAAAMQAAAAGAAAA0AAAAAcAAADcAAAACAAAAPAAAAAJAAAAAAEAABIAAAAM AQAACgAAACgBAAALAAAANAEAAAwAAABAAQAADQAAAEwBAAAOAAAAWAEAAA8AAABgAQAAEAAAAGgB AAATAAAAcAEAAAIAAADkBAAAHgAAAAIAAAAgAHMAHgAAAAEAAAAAAHMAHgAAAAIAAABzAHMAHgAA AAEAAAAAAHMAHgAAAAEAAAAAAHMAHgAAAAsAAABOb3JtYWwuZG90AAAeAAAABgAAAHVzZXIxAC5k HgAAAAIAAAAyAGVyHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAAEAAAAAARsMjAAAAAEAAAAAA eopjkK3BAUAAAAAA8ssuk63BAUAAAAAA8ssuk63BAQMAAAABAAAAAwAAADEBAAADAAAAzwYAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAA AALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rjwBAAD4AAAADQAAAAEAAABwAAAA DwAAAHgAAAAEAAAAhAAAAAUAAACMAAAABgAAAJQAAAARAAAAnAAAABcAAACkAAAACwAAAKwAAAAQ AAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAAAAwAAADaAAAAAgAAAOQEAAAeAAAABAAAAFdQ SQADAAAAAJoBAAMAAAAOAAAAAwAAAAMAAAADAAAAXAgAAAMAAADtDgkACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAIAAAAgAAwQAAACAAAAHgAAAAYAAABUaXRyZQADAAAA AQAAAAgBAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElO S1MAAgAAAOQEAABBAAAAwAAAAAwAAAADAAAACQAEAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8A AAAJAAAAaAB0AHQAcAA6AC8ALwAvAAAAAAAfAAAAAQAAAAAAAAADAAAAVAAkAAMAAAAAAAAAAwAA AAAAAAADAAAABQAAAB8AAAAgAAAAbQBhAGkAbAB0AG8AOgBjAGUAYwBpAGwAZQAuAG8AcwB0AGEA QABuAG8AdgBhAG0AZQBkAGkAYQAuAGYAcgAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAA AAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAA GAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAm AAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAD+////MwAAADQA AAA1AAAANgAAADcAAAA4AAAAOQAAAP7///87AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAA AEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAA/v///0wAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAAD+////VAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAP7////9////XQAAAP7////+ /////v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAA AABGAAAAAAAAAAAAAAAAoIwLMpOtwQFfAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADIAAAAAEAAAAAAAADEAVABhAGIA bABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO AAIAAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOgAAAPMg AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAmmIAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBu AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEsAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUwAAAAAQAAAAAAAAAQBDAG8AbQBw AE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA AgECAAAABwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAA AAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAoIwLMpOtwQGg jAsyk63BAQAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABEb2N1bWVu dCBNaWNyb3NvZnQgV29yZAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_00AC_01C1AE3F.33AE05E0-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 13:53:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13551 for ; Tue, 5 Feb 2002 13:53:56 -0500 (EST) Received: (qmail 28104 invoked by uid 605); 5 Feb 2002 18:53:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28097 invoked from network); 5 Feb 2002 18:53:53 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 5 Feb 2002 18:53:53 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26943 for ; Tue, 5 Feb 2002 11:53:52 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17003 for ; Tue, 5 Feb 2002 13:53:52 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g15IrpKx006386 for ; Tue, 5 Feb 2002 13:53:51 -0500 (EST) Message-Id: <200202051853.g15IrpKx006386@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: consensus probe. Reply-to: sommerfeld@east.sun.com Date: Tue, 05 Feb 2002 13:53:51 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Okay, I see significant volume of comments saying that we need to re-spin the core drafts once again to address the following two issues: - Split the ambiguous x.509 text into a new document. (this seems non-controversial at the moment) - Clarify the password change text (exactly how is still under discussion; let's try to nail this down today). *sigh*. i was hoping we were done. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 13:55:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13696 for ; Tue, 5 Feb 2002 13:55:54 -0500 (EST) Received: (qmail 29342 invoked by uid 605); 5 Feb 2002 18:55:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29335 invoked from network); 5 Feb 2002 18:55:52 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 5 Feb 2002 18:55:52 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28484 for ; Tue, 5 Feb 2002 11:55:51 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.105]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA24713 for ; Tue, 5 Feb 2002 10:57:28 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g15Ith3g108225; Tue, 5 Feb 2002 10:55:47 -0800 (PST) Message-Id: <200202051855.g15Ith3g108225@jurassic.eng.sun.com> Date: Tue, 5 Feb 2002 10:54:28 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: consensus probe. To: ietf-ssh@netbsd.org, sommerfeld@east.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Vvsq8nVfvgJbLyPzcObtxQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >Okay, I see significant volume of comments saying that we need to >re-spin the core drafts once again to address the following two issues: > > - Split the ambiguous x.509 text into a new document. (this seems > non-controversial at the moment) In doing this the quickest and eaisest way is to remove ALL references to X.509 from the core drafts - is this what people want me to do ? > - Clarify the password change text (exactly how is still under > discussion; let's try to nail this down today). > >*sigh*. i was hoping we were done. > > - Bill -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 14:21:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14814 for ; Tue, 5 Feb 2002 14:21:55 -0500 (EST) Received: (qmail 4858 invoked by uid 605); 5 Feb 2002 19:21:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4851 invoked from network); 5 Feb 2002 19:21:53 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 5 Feb 2002 19:21:53 -0000 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 08A6B67107; Tue, 5 Feb 2002 14:38:08 -0500 (EST) Date: Tue, 5 Feb 2002 14:21:28 -0500 Subject: Re: consensus probe. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-ssh@netbsd.org To: sommerfeld@east.sun.com From: RJ Atkinson In-Reply-To: <200202051853.g15IrpKx006386@thunk.east.sun.com> Message-Id: <8D71654E-1A6D-11D6-98E5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, February 5, 2002, at 01:53 , Bill Sommerfeld wrote: > Okay, I see significant volume of comments saying that we need to > re-spin the core drafts once again to address the following two issues: > > - Split the ambiguous x.509 text into a new document. (this seems > non-controversial at the moment) > > - Clarify the password change text (exactly how is still under > discussion; let's try to nail this down today). > > *sigh*. i was hoping we were done. It seems like every time we get close, then some new issue doesn't arise until "last call" actually happens. This is both frustrating all around and a good way not to reach closure. Could EVERYONE please put ALL their critical unresolved issues on the list RIGHT NOW, so they can ALL be resolved in the next editorial sweep ?? Thanks, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 14:23:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14955 for ; Tue, 5 Feb 2002 14:23:35 -0500 (EST) Received: (qmail 5312 invoked by uid 605); 5 Feb 2002 19:23:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5304 invoked from network); 5 Feb 2002 19:23:33 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Feb 2002 19:23:33 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 471624 for ietf-ssh@netbsd.org; Tue, 05 Feb 2002 12:29:59 -0700 Message-ID: <017601c1ae7a$448e3ca0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Subject: Fw: consensus probe. Date: Tue, 5 Feb 2002 12:21:10 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Whoops -- forgot to cc the list on this. - Joseph ----- Original Message ----- From: "Joseph Galbraith" To: "Darren Moffat" Sent: Tuesday, February 05, 2002 12:20 Subject: Re: consensus probe. > > >Okay, I see significant volume of comments saying that we need to > > >re-spin the core drafts once again to address the following two issues: > > > > > > - Split the ambiguous x.509 text into a new document. (this seems > > > non-controversial at the moment) > > > > In doing this the quickest and eaisest way is to remove ALL references > > to X.509 from the core drafts - is this what people want me to do ? > > That seems best to me. Are there other > places besides the public key section in the > transport draft? > > I also think that, like Mats pointed out, > this paragraph needs fixing: > > Certificates and public keys are encoded as follows: > > string certificate or public key format identifier > byte[n] key/certificate data > > The certificate part may have be a zero length string, but a public > key is required. This is the public key that will be used for > authentication; the certificate sequence contained in the certificate > blob can be used to provide authorization. > > > I'm really not sure what idea this is supposed > to be expressing. I would suggest something > like: > > Certificates are treated as public keys. Public keys > are encoded as follows: > > string public key format identifier > byte[n] key/certificate data > > The public key format identifier specifies the > format of the key/certificate data field. Each > type of public key must explicitly specify a > format for the data. > > - Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 14:29:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15365 for ; Tue, 5 Feb 2002 14:29:32 -0500 (EST) Received: (qmail 6311 invoked by uid 605); 5 Feb 2002 19:29:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6303 invoked from network); 5 Feb 2002 19:29:30 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Feb 2002 19:29:30 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 471631; Tue, 05 Feb 2002 12:35:58 -0700 Message-ID: <018501c1ae7b$1a73c650$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , References: <200202051853.g15IrpKx006386@thunk.east.sun.com> Subject: Re: public key (was Re: consensus probe.) Date: Tue, 5 Feb 2002 12:27:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > - Split the ambiguous x.509 text into a new document. (this seems > non-controversial at the moment) We had at least one suggest that we include Signatures are encoded as follows: string signature format identifier (same as public key/cert format) byte[n] signature blob in format specific encoding following the similar text about public keys. This seems a good idea to me (though I think I would omit the "(same as public key/cert format)" as at least one proposal for x.509 doesn't follow this rule. Perhaps "(as specified by public key/cert format)" would be more appropriate? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 14:40:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15856 for ; Tue, 5 Feb 2002 14:40:02 -0500 (EST) Received: (qmail 10632 invoked by uid 605); 5 Feb 2002 19:40:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10586 invoked from network); 5 Feb 2002 19:40:00 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 5 Feb 2002 19:40:00 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13501; Tue, 5 Feb 2002 11:39:58 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27316; Tue, 5 Feb 2002 14:39:56 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g15JduKx006934; Tue, 5 Feb 2002 14:39:56 -0500 (EST) Message-Id: <200202051939.g15JduKx006934@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Galbraith" cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: public key (was Re: consensus probe.) In-Reply-To: Your message of "Tue, 05 Feb 2002 12:27:08 MST." <018501c1ae7b$1a73c650$2800a8c0@test.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 05 Feb 2002 14:39:56 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Perhaps "(as specified by > public key/cert format)" would be more > appropriate? *if we do that*, we may also need a statement that unless otherwise specified the sig format id == pk/cert format id. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 14:40:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15907 for ; Tue, 5 Feb 2002 14:40:47 -0500 (EST) Received: (qmail 11246 invoked by uid 605); 5 Feb 2002 19:40:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11233 invoked from network); 5 Feb 2002 19:40:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Feb 2002 19:40:34 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 471670; Tue, 05 Feb 2002 12:47:02 -0700 Message-ID: <018f01c1ae7c$a63edd40$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Cc: , References: <200202051939.g15JduKx006934@thunk.east.sun.com> Subject: Re: public key (was Re: consensus probe.) Date: Tue, 5 Feb 2002 12:38:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > Perhaps "(as specified by > > public key/cert format)" would be more > > appropriate? > > *if we do that*, we may also need a statement that unless otherwise > specified the sig format id == pk/cert format id. That sounds reasonable. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 14:49:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16231 for ; Tue, 5 Feb 2002 14:49:05 -0500 (EST) Received: (qmail 14588 invoked by uid 605); 5 Feb 2002 19:49:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14581 invoked from network); 5 Feb 2002 19:49:02 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Feb 2002 19:49:02 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 471690; Tue, 05 Feb 2002 12:55:31 -0700 Message-ID: <019d01c1ae7d$d574c830$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Frank Cusack" Cc: , References: <200202042259.g14MxVKx027837@thunk.east.sun.com> <010a01c1add6$de8be040$2800a8c0@test.vandyke.com> <20020204182927.K9212@google.com> Subject: Re: Password change (was Re: WG Last Call (third time's the charm?) for SSH core drafts) Date: Tue, 5 Feb 2002 12:46:41 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > If we really wanted to clean this up, > > we should (and I really don't think we > > want to do all this now): > > > > 1. Allow authentication messages at any time -- > > requests after success are immediately failed > > without further checking if they use a different > > username. > > [...] > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > which included how much time was left before > > expiration. The server would send this and > > the usual success or partial failure message. > > The client would display a "You password will > > expire in n days. Would you like to change > > it now?" > > This seems superior. The problem is, #2 depends on #1 -- so we have to make both changes in order for it to work -- with-out #1, the password change request will be ignored by the server. Do we really want to make that kind of change now? In my implementation it wouldn't really be that hard (actually, I think we currently get this wrong), but -- What worrys me is that there would be other implications to this change that we haven't thought of -- we are trying to hurry to last call, so we might not have enough time to flush these out. I think we should go with this proposal, which doesn't address the "soft expiration policy" issue, but resolves the basic ambiguity of how a client is obligated to respond to a CHANGEREQ message: Normally, the server responds to this message with success or failure. However, if the password has expired the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ instead. In any case the server MUST NOT allow an expired password to be used for authentication. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 15:17:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17623 for ; Tue, 5 Feb 2002 15:17:33 -0500 (EST) Received: (qmail 21901 invoked by uid 605); 5 Feb 2002 20:17:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21894 invoked from network); 5 Feb 2002 20:17:30 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 5 Feb 2002 20:17:30 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id MAA18034; Tue, 5 Feb 2002 12:17:28 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id MAA05436; Tue, 5 Feb 2002 12:17:28 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g15KHSK12314; Tue, 5 Feb 2002 12:17:28 -0800 Date: Tue, 5 Feb 2002 12:17:28 -0800 From: Frank Cusack To: Joseph Galbraith Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: Password change (was Re: WG Last Call (third time's the charm?) for SSH core drafts) Message-ID: <20020205121728.E12274@google.com> References: <200202042259.g14MxVKx027837@thunk.east.sun.com> <010a01c1add6$de8be040$2800a8c0@test.vandyke.com> <20020204182927.K9212@google.com> <019d01c1ae7d$d574c830$2800a8c0@test.vandyke.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: <019d01c1ae7d$d574c830$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Tue, Feb 05, 2002 at 12:46:41PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Feb 05, 2002 at 12:46:41PM -0700, Joseph Galbraith wrote: > > > If we really wanted to clean this up, > > > we should (and I really don't think we > > > want to do all this now): > > > > > > 1. Allow authentication messages at any time -- > > > requests after success are immediately failed > > > without further checking if they use a different > > > username. > > > > [...] > > > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > > which included how much time was left before > > > expiration. The server would send this and > > > the usual success or partial failure message. > > > The client would display a "You password will > > > expire in n days. Would you like to change > > > it now?" > > > > This seems superior. > > The problem is, #2 depends on #1 -- so > we have to make both changes in order for > it to work -- with-out #1, the password > change request will be ignored by the > server. > > Do we really want to make that kind of > change now? In my implementation it > wouldn't really be that hard (actually, > I think we currently get this wrong), but -- You could have an ack message from the client (either USERAUTH_PASSWD_CHANGEREQ, or a "null" message.) *Then* the server responds success/failure. You could just have the message be "ignored" by the client, ie the user cannot change their password this way. S: SSH_MSG_USERAUTH_PASSWD_EXPIRING S: SSH_MSG_USERAUTH_SUCCESS > What worrys me is that there would be > other implications to this change > that we haven't thought of -- we are > trying to hurry to last call, so we might > not have enough time to flush these out. > > I think we should go with this proposal, > which doesn't address the "soft expiration > policy" issue, but resolves the basic > ambiguity of how a client is obligated > to respond to a CHANGEREQ message: > > Normally, the server responds to this message with success or > failure. However, if the password has expired the server SHOULD > indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > instead. In any case the server MUST NOT allow an expired password > to be used for authentication. > > byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > string prompt (ISO-10646 UTF-8) > string language tag (as defined in [RFC1766]) > > In this case, the client MAY continue with a different > authentication method, or request a new password from > the user and retry password authentication using the > following message. The client MAY also send this message > instead of the normal password authentication request > without the server asking for it. I like it. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 5 15:20:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17701 for ; Tue, 5 Feb 2002 15:20:21 -0500 (EST) Received: (qmail 23528 invoked by uid 605); 5 Feb 2002 20:20:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23521 invoked from network); 5 Feb 2002 20:20:19 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 5 Feb 2002 20:20:19 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01725; Tue, 5 Feb 2002 13:20:09 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA07593; Tue, 5 Feb 2002 10:21:45 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g15IK23g999603; Tue, 5 Feb 2002 10:20:05 -0800 (PST) Message-Id: <200202051820.g15IK23g999603@jurassic.eng.sun.com> Date: Tue, 5 Feb 2002 10:18:46 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts To: galb-list@vandyke.com, djm@mindrot.org Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BpHy2IFNHe7i3THVMsHrCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >On Mon, 4 Feb 2002, Joseph Galbraith wrote: > >> I would say create a new working group >> document for x.509 and remove it >> from the transport draft. > >I support this approach. The current spec is too vague to implement. I'm also in favour of removing it from core. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 6 02:08:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13407 for ; Wed, 6 Feb 2002 02:08:12 -0500 (EST) Received: (qmail 13412 invoked by uid 605); 6 Feb 2002 07:08:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13405 invoked from network); 6 Feb 2002 07:08:08 -0000 Received: from iron.ibs.com.au (202.14.182.249) by mail.netbsd.org with SMTP; 6 Feb 2002 07:08:08 -0000 Received: from xenon.mel.ibs.com.au (xenon.mel.ibs.com.au [10.3.0.3]) by iron.ibs.com.au (Postfix) with ESMTP id 24BE916CB6; Wed, 6 Feb 2002 17:26:05 +1100 (EST) Date: Wed, 6 Feb 2002 17:31:46 +1100 (EST) From: Damien Miller X-X-Sender: To: Darren Moffat Cc: "ietf-ssh@netbsd.org" , "sommerfeld@east.sun.com" Subject: Re: consensus probe. In-Reply-To: <200202051855.g15Ith3g108225@jurassic.eng.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, 5 Feb 2002, Darren Moffat wrote: > >Okay, I see significant volume of comments saying that we need to > >re-spin the core drafts once again to address the following two issues: > > > > - Split the ambiguous x.509 text into a new document. (this seems > > non-controversial at the moment) > > In doing this the quickest and eaisest way is to remove ALL references > to X.509 from the core drafts - is this what people want me to do ? Yes - we can thrash out the details in a seperate document. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 6 03:52:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14519 for ; Wed, 6 Feb 2002 03:52:19 -0500 (EST) Received: (qmail 608 invoked by uid 605); 6 Feb 2002 08:52:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 601 invoked from network); 6 Feb 2002 08:52:15 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 6 Feb 2002 08:52:15 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 1E7B93BD2A; Wed, 6 Feb 2002 09:52:12 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 1C0336C007; Wed, 6 Feb 2002 09:52:13 +0100 (MET) Date: Wed, 6 Feb 2002 09:50:55 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Joseph Galbraith Cc: Frank Cusack , , Subject: Re: Password change (was Re: WG Last Call (third time's the charm?) for SSH core drafts) In-Reply-To: <019d01c1ae7d$d574c830$2800a8c0@test.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 5 Feb 2002, Joseph Galbraith wrote: > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > > > This seems superior. I don't see the reason to start doing this change NOW? The SSH_MSG_USERAUTH_PASSWD_CHANGEREQ as it stands in the draft might not be perfect but it describes an easy way to handle password change requests (and it's what is deployed). If one wants to refine this process, one can either use keyboard-interactive authentication (which is superior in most ways anyway!) OR one can add this new request at a later stage (it's not something that has been implemented so why should it come into this set of drafts?). About the x509 "problem"; it is really solved with some small clarifications (see my earlier mails on this). It can easily be moved to a separate draft which at this stage might be better since there are no "compliant" implementations anyway). However, personally I'm happy with just the small clarifications on signature formats, after all the "x509v3-sign-rsa" and "x509v3-sign-dss" do REFER to rfc2459 (which in its turn refers PKCS#1), are those documents underspecified or what are we suggesting here?!? Also, if the x509 stuff isn't enough specified in the draft, mustn't we remove ALL other public key formats (i.e. spki and pgp) too? (or are there something which is clearer with those in the draft, in which case I must be missing something?). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 6 04:08:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14794 for ; Wed, 6 Feb 2002 04:08:22 -0500 (EST) Received: (qmail 1665 invoked by uid 605); 6 Feb 2002 09:08:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1658 invoked from network); 6 Feb 2002 09:08:20 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 6 Feb 2002 09:08:20 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA13501; Wed, 6 Feb 2002 10:08:10 +0100 (MET) Date: Wed, 6 Feb 2002 10:08:10 +0100 From: Markus Friedl To: Joseph Galbraith , Frank Cusack , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Cc: "Andersson, Mats" Subject: Re: Password change (was Re: WG Last Call (third time's the charm?) for SSH core drafts) Message-ID: <20020206090810.GB13389@faui02> References: <019d01c1ae7d$d574c830$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Feb 06, 2002 at 09:50:55AM +0100, Andersson, Mats wrote: > > On Tue, 5 Feb 2002, Joseph Galbraith wrote: > > > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING > > > > > > This seems superior. > > I don't see the reason to start doing this change NOW? Nor do I. If you want to do fancy things, you can use kbd-interactive. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 6 16:41:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03246 for ; Wed, 6 Feb 2002 16:41:42 -0500 (EST) Received: (qmail 26749 invoked by uid 605); 6 Feb 2002 21:41:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26742 invoked from network); 6 Feb 2002 21:41:30 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 6 Feb 2002 21:41:30 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id NAA28639 for ; Wed, 6 Feb 2002 13:41:22 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id NAA13344 for ietf-ssh@netbsd.org; Wed, 6 Feb 2002 13:41:18 -0800 (PST) Date: Wed, 6 Feb 2002 13:41:17 -0800 From: Wei Dai To: ietf-ssh@netbsd.org Subject: an attack against SSH2 protocol Message-ID: <20020206134116.A24813@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: ietf-ssh-owner@netbsd.org Precedence: list [Posted to sci.crypt and the IETF SSH working group mailing list.] Phil Rogaway observed that CBC mode is not secure against chosen- plaintext attack if the IV is known or can be predicted by the attacker before he choses his plaintext [1]. Similarly, CBC mode is not secure if the attacker can observe the last ciphertext block before choosing the next block of plaintext, because the last block of ciphertext essentially serves as the IV for the rest of the message. The attack itself is very simple. Remember that in CBC mode, each plaintext block is XOR'ed with the last ciphertext block and then encrypted to produce the next ciphertext block. Suppose the attacker suspects that plaintext block P_i might be x, and wants to test whether that's the case, he would choose the next plaintext block P_j to be x XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his guess by looking at whether C_j = C_i. The SSH2 protocol, when used with a block cipher in CBC mode, does allow the attacker to observe the last ciphertext block of a packet, which is then used as the (implicit) IV of the next packet. SSH2 also multiplexes multiple channels into one transport stream encrypted with a single key. This gives the attacker who can input data into one channel a chance to attack other channels. (Another possible attack scenario is a multi-user chat session.) Fortunately, the attacker may not have complete freedom to choose the first block of the plaintext of the next packet. For example, the first 4 bytes of the plaintext of any packet consist of the packet length. Assuming that the SSH2 application has a maximum packet size of 2^16, the attacker is constrained to choosing a plaintext block that begins with two zero octects. This implies that the attacker would have to wait at least 2^16 packets on average before he has a chance to perform this attack. However even with this and other potential constraints it seems very possible for the attacker to succeed in some situations. So I suggest that the SSH2 protocol be fixed. The simplest way to do this would be to deprecate the CBC mode block ciphers, and instead specify ciphers in CFB, CTR or OFB mode. Currently, the only cipher defined in the SSH2 transport protocol draft that is not a block cipher in CBC mode is ARC4. Until this fix is implemented, users of SSH2 applications may want to consider switching to ARC4 for encryption. [1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec- comments-00.txt -- http://cryptopp.com - free C++ cryptography and compression library From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 7 07:51:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25732 for ; Thu, 7 Feb 2002 07:51:55 -0500 (EST) Received: (qmail 13134 invoked by uid 605); 7 Feb 2002 12:51:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13127 invoked from network); 7 Feb 2002 12:51:51 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 7 Feb 2002 12:51:51 -0000 Received: from folly.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id NAA07165; Thu, 7 Feb 2002 13:51:45 +0100 (MET) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 3C57145D4; Thu, 7 Feb 2002 13:51:32 +0100 (CET) Date: Thu, 7 Feb 2002 13:51:31 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: Joseph Galbraith , ietf-ssh@netbsd.org Subject: Re: public key (was Re: consensus probe.) Message-ID: <20020207135131.A3211@folly> References: <018501c1ae7b$1a73c650$2800a8c0@test.vandyke.com> <200202051939.g15JduKx006934@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200202051939.g15JduKx006934@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Feb 05, 2002 at 02:39:56PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Feb 05, 2002 at 02:39:56PM -0500, Bill Sommerfeld wrote: > > Perhaps "(as specified by > > public key/cert format)" would be more > > appropriate? > > *if we do that*, we may also need a statement that unless otherwise > specified the sig format id == pk/cert format id. i think this is the only way, since during the initial KEX both parties only agree on _one_ single format id for the hostkey. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 7 10:07:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29287 for ; Thu, 7 Feb 2002 10:07:20 -0500 (EST) Received: (qmail 12506 invoked by uid 605); 7 Feb 2002 15:07:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12499 invoked from network); 7 Feb 2002 15:07:17 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Feb 2002 15:07:17 -0000 Received: from [127.0.0.1] (HELO joseph) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 475270; Thu, 07 Feb 2002 08:13:46 -0700 Message-ID: <002e01c1afe9$253dea60$140210ac@joseph> From: "Joseph Galbraith" To: "Markus Friedl" , "Bill Sommerfeld" Cc: References: <018501c1ae7b$1a73c650$2800a8c0@test.vandyke.com> <200202051939.g15JduKx006934@thunk.east.sun.com> <20020207135131.A3211@folly> Subject: Re: public key (was Re: consensus probe.) Date: Thu, 7 Feb 2002 08:07:12 -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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Markus Friedl" > On Tue, Feb 05, 2002 at 02:39:56PM -0500, Bill Sommerfeld wrote: > > > Perhaps "(as specified by > > > public key/cert format)" would be more > > > appropriate? > > > > *if we do that*, we may also need a statement that unless otherwise > > specified the sig format id == pk/cert format id. > > i think this is the only way, since during the initial KEX > both parties only agree on _one_ single format id for > the hostkey. It is possible that the format id for the public key (x509v3) specifies a signature format that isn't necessarily of the same name be used. For example, we could specify (unambiguously) that x509v3-sign-rsa keys would use ssh-rsa signatures. There is no ambiguity here, hence my proposal that we spec this flexibly enough to handle this. On the other hand, I do agree that we also need language that says that unless otherwise specified sig format id is the same as key format id. Perhaps the following text would be more agreeable? Signatures are encoded as follows: string signature format identifier (as specified by the public key/cert format) byte[n] signature blob in format specific encoding Public key / certificate formats that do not explicitly specify a signature format identifier MUST be considered to use the public key / certificate format identifier as the signature identifier. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 7 10:24:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29628 for ; Thu, 7 Feb 2002 10:24:05 -0500 (EST) Received: (qmail 14833 invoked by uid 605); 7 Feb 2002 15:24:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14821 invoked from network); 7 Feb 2002 15:24:03 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 7 Feb 2002 15:24:03 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 59AA53BD0E; Thu, 7 Feb 2002 16:24:00 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 206506C007; Thu, 7 Feb 2002 16:24:03 +0100 (MET) Date: Thu, 7 Feb 2002 16:22:41 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Joseph Galbraith Cc: Markus Friedl , Bill Sommerfeld , Subject: Re: public key (was Re: consensus probe.) In-Reply-To: <002e01c1afe9$253dea60$140210ac@joseph> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 7 Feb 2002, Joseph Galbraith wrote: > For example, we could specify (unambiguously) that x509v3-sign-rsa > keys would use ssh-rsa signatures. There is no ambiguity here, hence Why would we want to do this (though these two signatures happens to be of the same format as defined in PKCS1), what is the flexibility to be able to use keys of a certain format for generating (potentially) differently formatted signatures? If it is not usable for something extraordinary why include it, it might just confuse some implementation that it sends a key of format X and receives a signature of format Y (I'm tired so there might be uses for this but I can't find one except for "lazy" code-reuse :-). > Signatures are encoded as follows: > string signature format identifier (as specified by the public > key/cert format) > byte[n] signature blob in format specific encoding > > Public key / certificate formats that do not > explicitly specify a signature format identifier > MUST be considered to use the public key / certificate > format identifier as the signature identifier. However, doesn't this sound like it can be interpreted as if the signature format identifier might be ommited alltogether?! (or is it just me beeing dizzy here?). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 7 14:39:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07178 for ; Thu, 7 Feb 2002 14:39:18 -0500 (EST) Received: (qmail 9262 invoked by uid 605); 7 Feb 2002 19:39:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9254 invoked from network); 7 Feb 2002 19:39:14 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 7 Feb 2002 19:39:14 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01307; Thu, 7 Feb 2002 12:39:09 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21507; Thu, 7 Feb 2002 14:39:08 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g17Jd8Kx012183; Thu, 7 Feb 2002 14:39:08 -0500 (EST) Message-Id: <200202071939.g17Jd8Kx012183@thunk.east.sun.com> From: Bill Sommerfeld To: "Andersson, Mats" cc: Joseph Galbraith , Markus Friedl , Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: public key (was Re: consensus probe.) In-Reply-To: Your message of "Thu, 07 Feb 2002 16:22:41 +0100." Reply-to: sommerfeld@east.sun.com Date: Thu, 07 Feb 2002 14:39:08 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [ wg chair hat off ] > > Public key / certificate formats that do not > > explicitly specify a signature format identifier > > MUST be considered to use the public key / certificate > > format identifier as the signature identifier. > > However, doesn't this sound like it can be interpreted as if the signature > format identifier might be ommited alltogether?! (or is it just me beeing > dizzy here?). I'd delete "be considered to", resulting in: > Public key / certificate formats that do not explicitly specify a > signature format identifier MUST use the public key / certificate > format identifier as the signature identifier. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 7 16:00:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09734 for ; Thu, 7 Feb 2002 16:00:44 -0500 (EST) Received: (qmail 3996 invoked by uid 605); 7 Feb 2002 21:00:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3989 invoked from network); 7 Feb 2002 21:00:42 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Feb 2002 21:00:42 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 476040; Thu, 07 Feb 2002 14:07:15 -0700 Message-ID: <030201c1b01a$2a3577f0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , "Andersson, Mats" Cc: "Markus Friedl" , "Bill Sommerfeld" , References: <200202071939.g17Jd8Kx012183@thunk.east.sun.com> Subject: Re: public key (was Re: consensus probe.) Date: Thu, 7 Feb 2002 13:57:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit From: "Bill Sommerfeld" > [ wg chair hat off ] > > > > Public key / certificate formats that do not > > > explicitly specify a signature format identifier > > > MUST be considered to use the public key / certificate > > > format identifier as the signature identifier. > > > > However, doesn't this sound like it can be interpreted as if the signature > > format identifier might be ommited alltogether?! (or is it just me beeing > > dizzy here?). > > I'd delete "be considered to", resulting in: > > > Public key / certificate formats that do not explicitly specify a > > signature format identifier MUST use the public key / certificate > > format identifier as the signature identifier. This sound good to me. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 8 06:47:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03856 for ; Fri, 8 Feb 2002 06:47:54 -0500 (EST) Received: (qmail 25414 invoked by uid 605); 8 Feb 2002 11:47:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25407 invoked from network); 8 Feb 2002 11:47:50 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 8 Feb 2002 11:47:50 -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.27) with SMTP id g18Blmf21892 for ; Fri, 8 Feb 2002 13:47:48 +0200 (EET) Received: (qmail 9678 invoked from network); 8 Feb 2002 11:47:47 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 8 Feb 2002 11:47:47 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.11.6/8.9.3) id g18Cnnr29200; Fri, 8 Feb 2002 14:49:49 +0200 X-Authentication-Warning: johto.hel.fi.ssh.com: sjl set sender to sjl@ssh.com using -f To: ietf-ssh@netbsd.org Subject: Re: Using PAM an the SSH Protocol References: <200201181710.g0IHAUqT974240@jurassic.eng.sun.com> From: sjl@ssh.com (Sami J. Lehtinen) Date: 08 Feb 2002 14:49:48 +0200 In-Reply-To: <200201181710.g0IHAUqT974240@jurassic.eng.sun.com> Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list Darren.Moffat@eng.sun.com (Darren Moffat) writes: > >keyboard-interactive is capable of fully interacting with PAM. It was, > >in fact, designed based on an sshd using PAM. Is "pam-1@ssh.com" still > >in use? That would be most unfortunate, it breaks one of the things > >kbdint was meant to solve: client knowledge of the authentication > >mechanism. > > I believe that pam-1@ssh.com is still in use. If some one from SSH > Communications is listening can you tells us if you plan to rectify this ? Yes, the next version will support PAM over keyboard-interactive. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 8 07:12:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04195 for ; Fri, 8 Feb 2002 07:12:15 -0500 (EST) Received: (qmail 29400 invoked by uid 605); 8 Feb 2002 12:12:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29393 invoked from network); 8 Feb 2002 12:12:12 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 8 Feb 2002 12:12:12 -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.27) with SMTP id g18CCAf22451 for ; Fri, 8 Feb 2002 14:12:10 +0200 (EET) Received: (qmail 13786 invoked from network); 8 Feb 2002 12:12:10 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 8 Feb 2002 12:12:10 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.11.6/8.9.3) id g18DECS29215; Fri, 8 Feb 2002 15:14:12 +0200 X-Authentication-Warning: johto.hel.fi.ssh.com: sjl set sender to sjl@ssh.com using -f To: ietf-ssh@netbsd.org Subject: Re: WG Last Call (third time's the charm?) for SSH core drafts References: From: sjl@ssh.com (Sami J. Lehtinen) Date: 08 Feb 2002 15:14:11 +0200 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list djm@mindrot.org (Damien Miller) writes: > On Mon, 4 Feb 2002, Joseph Galbraith wrote: > > > I would say create a new working group > > document for x.509 and remove it > > from the transport draft. > > I support this approach. The current spec is too vague to implement. I second this. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 8 14:51:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22229 for ; Fri, 8 Feb 2002 14:51:04 -0500 (EST) Received: (qmail 14835 invoked by uid 605); 8 Feb 2002 19:51:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14827 invoked from network); 8 Feb 2002 19:50:58 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 8 Feb 2002 19:50:58 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23440; Fri, 8 Feb 2002 11:50:31 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07289; Fri, 8 Feb 2002 14:50:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g18JoTKx007574; Fri, 8 Feb 2002 14:50:29 -0500 (EST) Message-Id: <200202081950.g18JoTKx007574@thunk.east.sun.com> From: Bill Sommerfeld To: Wei Dai cc: ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol In-Reply-To: Your message of "Wed, 06 Feb 2002 13:41:17 PST." <20020206134116.A24813@eskimo.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 08 Feb 2002 14:50:29 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, I'm surprised to see no technical comments on this so far, either here or on my local view of sci.crypt. The attack appears to be extremely narrow -- to restate it (please correct me if i'm wrong) - real-time adaptive chosen plaintext attack - attacker can verify a guess at one block of plaintext occurring immediately before the injected plaintext - the chosen plaintext is chosen based on the ciphertext of the guessed plaintext. I do have to question the arcfour/RC4 recommendation, though -- as currently specified, ssh is vulnerable to the RC4 "weak key" problem because, as specified, it doesn't discard the start of the keystream. (fixing this has been discussed, but there seemed to be very little interest in doing work on RC4/arcfour when this was last raised). Moreover, it appears to be fairly straightforward to make an implementation resist the attack while retaining interoperability: The basic ssh message framing is: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length As documented, the "mac" is transmitted in the clear; everything before that is encrypted. Padding Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes. With the 4-byte minimum, the random padding puts a floor on the difficulty of guessing the previous block (no better than one chance in 2**32). An implementation could render the attack entirely meaningless by always sending a full cipherblock of padding... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 8 15:11:29 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23215 for ; Fri, 8 Feb 2002 15:11:29 -0500 (EST) Received: (qmail 26668 invoked by uid 605); 8 Feb 2002 20:10:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26632 invoked from network); 8 Feb 2002 20:10:41 -0000 Received: from mx2.eskimo.com (204.122.16.49) by mail.netbsd.org with SMTP; 8 Feb 2002 20:10:41 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx2.eskimo.com (8.9.1a/8.8.8) with ESMTP id MAA13929; Fri, 8 Feb 2002 12:10:38 -0800 (PST) Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id MAA14090; Fri, 8 Feb 2002 12:10:37 -0800 (PST) Date: Fri, 8 Feb 2002 12:10:36 -0800 From: Wei Dai To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol Message-ID: <20020208121036.C27560@eskimo.com> References: <20020206134116.A24813@eskimo.com> <200202081950.g18JoTKx007574@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200202081950.g18JoTKx007574@thunk.east.sun.com>; from sommerfeld@east.sun.com on Fri, Feb 08, 2002 at 02:50:29PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Feb 08, 2002 at 02:50:29PM -0500, Bill Sommerfeld wrote: > So, I'm surprised to see no technical comments on this so far, either > here or on my local view of sci.crypt. I have received some comments through private email. Apparently the exact same weakness was known for IPSec and may also exist in TLS (I haven't read enough of its RFC to be sure) so this seems to be a common problem. (We really should drop the rule of thumb "use CBC mode unless there's a reason not to" and replace it with "use CTR mode unless there's a reason not to".) > The attack appears to be extremely narrow -- to restate it > (please correct me if i'm wrong) > - real-time adaptive chosen plaintext attack > - attacker can verify a guess at one block of plaintext occurring > immediately before the injected plaintext No, the attacker can verify a guess of any previous block of plaintext, not just the block immediately before the injected plaintext. > - the chosen plaintext is chosen based on the ciphertext of the > guessed plaintext. > > I do have to question the arcfour/RC4 recommendation, though -- as > currently specified, ssh is vulnerable to the RC4 "weak key" problem > because, as specified, it doesn't discard the start of the keystream. > (fixing this has been discussed, but there seemed to be very little > interest in doing work on RC4/arcfour when this was last raised). That's why I didn't recommend ARC4, only suggested that it be considered as an alternative while a better fix is implemented. > Moreover, it appears to be fairly straightforward to make an > implementation resist the attack while retaining interoperability: This suggested fix is based on the above misunderstanding, and so doesn't work. I still think the easiest fix is to deprecate the existing CBC mode ciphers and define new ciphers in OFB, CFB, or CTR modes. I suggest CTR mode unless there's a reason not to use that, but we may also want to define ciphers in other modes as a backup (in case some problem with CTR mode is discovered down the road). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 8 20:37:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28980 for ; Fri, 8 Feb 2002 20:37:41 -0500 (EST) Received: (qmail 631 invoked by uid 605); 9 Feb 2002 01:37:39 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 9 Feb 2002 01:37:39 -0000 Message-ID: <20020209013739.630.qmail@mail.netbsd.org> Received: (qmail 624 invoked from network); 9 Feb 2002 01:37:38 -0000 Received: from cdc-info.cdc.informatik.tu-darmstadt.de (130.83.23.100) by mail.netbsd.org with SMTP; 9 Feb 2002 01:37:38 -0000 Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 3FAB32C88; Sat, 9 Feb 2002 02:37:36 +0100 (MET) Received: id ; Sat, 9 Feb 2002 02:16:20 +0100 (CET) To: ietf-ssh@netbsd.org, ietf-tls@lists.certicom.com Cc: Wei Dai , openssl-dev@openssl.org From: moeller@cdc.informatik.tu-darmstadt.de (Bodo Moeller) Subject: Re: an attack against SSH2 protocol In-Reply-To: <20020208121036.C27560@eskimo.com> References: <200202081950.g18JoTKx007574@thunk.east.sun.com> <20020208121036.C27560@eskimo.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list Wei Dai : >> [Posted to sci.crypt and the IETF SSH working group mailing list.] >> >> Phil Rogaway observed that CBC mode is not secure against chosen- >> plaintext attack if the IV is known or can be predicted by the attacker >> before he choses his plaintext [1]. Similarly, CBC mode is not secure if >> the attacker can observe the last ciphertext block before choosing the >> next block of plaintext, because the last block of ciphertext >> essentially serves as the IV for the rest of the message. >> >> The attack itself is very simple. Remember that in CBC mode, each >> plaintext block is XOR'ed with the last ciphertext block and then >> encrypted to produce the next ciphertext block. Suppose the attacker >> suspects that plaintext block P_i might be x, and wants to test whether >> that's the case, he would choose the next plaintext block P_j to be x >> XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j >> XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his >> guess by looking at whether C_j = C_i. >> >> The SSH2 protocol, when used with a block cipher in CBC mode, does allow >> the attacker to observe the last ciphertext block of a packet, which is >> then used as the (implicit) IV of the next packet. [...] >> [1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt > I have received some comments through private email. Apparently the exact > same weakness was known for IPSec and may also exist in TLS (I haven't > read enough of its RFC to be sure) [...] In TLS, the "IV for subsequent records is the last ciphertext block from the previous record" [RFC 2246], and plaintext blocks usually consist of raw application data followed by a MAC, so the attack applies. (Having the MAC at the *beginning* of each packet would avoid the attack.) In his CRYPTO 2001 paper "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Hugo Krawczyk supposedly shows that SSL/TLS with CBC encryption is secure -- but he assumes a random IV for each encrypted block, which is not how the actual SSL protocol works. Another problem with CBC as used in SSL/TLS was pointed out by Serge Vaudenay, see . That one can easily be avoided by implementations. To avoid the new attack without changing the protocol definition, implementations would have to send an empty fragment before application data to ensure IV randomization. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Feb 9 19:05:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20894 for ; Sat, 9 Feb 2002 19:05:35 -0500 (EST) Received: (qmail 12002 invoked by uid 605); 10 Feb 2002 00:05:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11995 invoked from network); 10 Feb 2002 00:05:27 -0000 Received: from as2-1-8.va.g.bonet.se (HELO ringstrom.mine.nu) (194.236.117.122) by mail.netbsd.org with SMTP; 10 Feb 2002 00:05:27 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=localhost) by ringstrom.mine.nu with esmtp (Exim 3.34 #1) id 16ZhUj-00022d-00 for ; Sun, 10 Feb 2002 01:05:25 +0100 Date: Sun, 10 Feb 2002 01:05:25 +0100 (CET) From: Tobias Ringstrom X-X-Sender: tori@boris.prodako.se To: ietf-ssh@netbsd.org Subject: SSH FTP - 6.1 Request Synchronization and Reordering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hello! I'm reading the SFTP-draft dated October 2001, and I think that section 6.1 is somewhat easy to misinterpret: 6.1 Request Synchronization and Reordering The protocol and implementations MUST process requests relating to the same file in the order in which they are received. In other words, if an application submits multiple requests to the server, the results in the responses will be the same as if it had sent the requests one at a time and waited for the response in each case. For example, the server may process non-overlapping read/write requests to the same file in parallel, but overlapping reads and writes cannot be reordered or parallelized. However, there are no ordering restrictions on the server for processing requests from two different file transfer connections. The server may interleave and parallelize them at will. There are no restrictions on the order in which responses to outstanding requests are delivered to the client, except that the server must ensure fairness in the sense that processing of no request will be indefinitely delayed even if the client is sending other requests so that there are multiple outstanding requests all the time. Reading the first paragraph, it is easy to get the impression that read/write requests to the same file cannot be reordered, not the responses. Perhaps it would be best to rewrite the first paragraph to just say something like this: The protocol and implementations MUST process non-orthogonal requests in the order in which they are received. Any two requests are non-orthogonal if and only if the reordering of the two requests does not change the final state on either the server or client side. Comments? /Tobias [Please CC me any comments, since I'm not on the list!] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Feb 10 06:26:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05410 for ; Sun, 10 Feb 2002 06:26:57 -0500 (EST) Received: (qmail 16248 invoked by uid 605); 10 Feb 2002 11:26:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16240 invoked from network); 10 Feb 2002 11:26:54 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 10 Feb 2002 11:26:54 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16Zs7y-0006Q6-00; Sun, 10 Feb 2002 11:26:38 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: SSH FTP - 6.1 Request Synchronization and Reordering Message-Id: Date: Sun, 10 Feb 2002 11:26:38 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Tobias Ringstrom wrote: > Reading the first paragraph, it is easy to get the impression that > read/write requests to the same file cannot be reordered, not the > responses. But both are true, though, surely? If I submit a read request covering bytes 0-100, then a write request covering bytes 20-120, and then a read request covering bytes 40-140, then _both_ the following restrictions apply: (a) The requests may not be processed in a (perceptibly) different order. That is, the first read must be performed before the write (so that it returns the unmodified pre-write data) and the second read must be performed after the write (so that it returns the modified post-write data). (b) The responses to the requests _also_ may not be reordered. Even if the three requests have different serial numbers and an alert client could plausibly be able to deal with the responses arriving out of order, it is not permitted to send them that way. Of course, if I submit a read request covering bytes 0-100, then another covering bytes 50-150, there's nothing in theory to stop the server from actually performing the reads in the opposite order, or even doing a single read covering bytes 0-150 and returning two substrings of it. I don't see what's unclear about the wording as it is. -- 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 Feb 11 09:53:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04287 for ; Mon, 11 Feb 2002 09:53:09 -0500 (EST) Received: (qmail 27244 invoked by uid 605); 11 Feb 2002 14:53:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27237 invoked from network); 11 Feb 2002 14:53:06 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 11 Feb 2002 14:53:06 -0000 Received: from localhost (dsl-213-023-060-184.arcor-ip.net [213.23.60.184]) by mx04.nexgo.de (Postfix) with ESMTP id E303437F53; Mon, 11 Feb 2002 15:53:03 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 8E81F44B1; Mon, 11 Feb 2002 13:36:45 +0100 (CET) Date: Mon, 11 Feb 2002 13:36:45 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: Wei Dai , ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol Message-ID: <20020211133645.C17632@folly> References: <20020206134116.A24813@eskimo.com> <200202081950.g18JoTKx007574@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200202081950.g18JoTKx007574@thunk.east.sun.com>; from sommerfeld@east.sun.com on Fri, Feb 08, 2002 at 02:50:29PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Feb 08, 2002 at 02:50:29PM -0500, Bill Sommerfeld wrote: > With the 4-byte minimum, the random padding puts a floor on the > difficulty of guessing the previous block (no better than one chance > in 2**32). An implementation could render the attack entirely > meaningless by always sending a full cipherblock of padding... i think this would only work if we restrict the actual payload to the blocksize of the cipher. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 11 11:02:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07231 for ; Mon, 11 Feb 2002 11:02:44 -0500 (EST) Received: (qmail 9077 invoked by uid 605); 11 Feb 2002 16:02:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9069 invoked from network); 11 Feb 2002 16:02:41 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Feb 2002 16:02:41 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 27059835DD1; Mon, 11 Feb 2002 17:02:40 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id RAA08641; Mon, 11 Feb 2002 17:02:39 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Wei Dai Cc: ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol References: <20020206134116.A24813@eskimo.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 11 Feb 2002 17:02:36 +0100 In-Reply-To: <20020206134116.A24813@eskimo.com> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Wei Dai writes: > The simplest way to do this would be to > deprecate the CBC mode block ciphers, and instead specify ciphers in > CFB, CTR or OFB mode. Another simple "fix" for CBC might be to add one more encryption operation between packets. If one packet consists of the ciphertext blocks b_1, b_2, ..., b_n, ssh uses b_n as the iv for the next packet. Would it help to instead use C_k(b_n) as the iv? This would be equivalent to inserting one (plain text) block of zeroes between packets, and keeping the corresponding ciphertext block secret. (The same trick could be used in other contexts that needs to send an iv in the clear: Encrypt the cleartext iv once before using it). To me, this attack doesn't look like a reason for general panic, but in any case it would be a good thing to specify how to use counter mode in ssh (but I think we should stay with a small number of modes, and not add *every* reasonable mode). A problem with counter mode is that the FIPS document doesn't define it fully; it doesn't say how you should increment the counter, you can do it in little endian order or big endian order or using any permutation of your choice. Is there any IETF wg that has tried to define a single standard way of doing counter mode? /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 11 11:19:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07810 for ; Mon, 11 Feb 2002 11:19:47 -0500 (EST) Received: (qmail 10117 invoked by uid 605); 11 Feb 2002 16:19:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10110 invoked from network); 11 Feb 2002 16:19:45 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Feb 2002 16:19:45 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 67159834E34; Mon, 11 Feb 2002 17:19:43 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id RAA09098; Mon, 11 Feb 2002 17:19:42 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "Andersson, Mats" Cc: Joseph Galbraith , Markus Friedl , Bill Sommerfeld , Subject: Re: public key (was Re: consensus probe.) References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 11 Feb 2002 17:19:41 +0100 In-Reply-To: Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Andersson, Mats" writes: > On Thu, 7 Feb 2002, Joseph Galbraith wrote: > > For example, we could specify (unambiguously) that x509v3-sign-rsa > > keys would use ssh-rsa signatures. There is no ambiguity here, hence > > Why would we want to do this (though these two signatures happens to be of > the same format as defined in PKCS1), what is the flexibility to be able > to use keys of a certain format for generating (potentially) differently > formatted signatures? I don't have a strong opinion about this, but I think using several names for things that are actually the same is a kind of bloat. I currently use a single symbol table (generated using gperf) that recognizes all symbol names used in the various specs, and the size of this table is linear with the total number of symbols. If lots and lots of symbols are added I'll have to consider splitting it into several tables for different "namespaces". BTW, when talking about signatures. ssh-rsa is specified as using PKCS1 signatures. What is really meant is PKCS1 v1.5. PKCS1 v2 (currently only at draft stage, I think) defines a new improved and incompatible padding mechanism. That's what happens when referenced documents change and references don't include version information... Regars, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Feb 11 13:53:29 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13961 for ; Mon, 11 Feb 2002 13:53:26 -0500 (EST) Received: (qmail 21474 invoked by uid 605); 11 Feb 2002 18:53:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21466 invoked from network); 11 Feb 2002 18:53:19 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 11 Feb 2002 18:53:19 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id KAA08351; Mon, 11 Feb 2002 10:52:54 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id KAA11688; Mon, 11 Feb 2002 10:52:54 -0800 (PST) Date: Mon, 11 Feb 2002 10:52:54 -0800 From: Wei Dai To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol Message-ID: <20020211105253.B8164@eskimo.com> References: <20020206134116.A24813@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: ; from nisse@lysator.liu.se on Mon, Feb 11, 2002 at 05:02:36PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Mon, Feb 11, 2002 at 05:02:36PM +0100, Niels Möller wrote: > Another simple "fix" for CBC might be to add one more encryption > operation between packets. If one packet consists of the ciphertext > blocks I think your fix would be ok, but since it's not backwards compatible it doesn't seem to have any advantage over defining new ciphers in CTR mode. > A problem with counter mode is that the FIPS document doesn't define > it fully; it doesn't say how you should increment the counter, you can > do it in little endian order or big endian order or using any > permutation of your choice. Is there any IETF wg that has tried to > define a single standard way of doing counter mode? Google search for "ctr mode rfc" turned up a couple of drafts: http://www.ietf.org/internet-drafts/draft-mcgrew-saag-icm-00.txt http://www.vpnc.org/draft-moskowitz-aes128-ctr I haven't read them yet. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Feb 12 15:26:09 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25112 for ; Tue, 12 Feb 2002 15:26:07 -0500 (EST) Received: (qmail 2585 invoked by uid 605); 12 Feb 2002 20:25:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2578 invoked from network); 12 Feb 2002 20:25:53 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 12 Feb 2002 20:25:53 -0000 Received: from localhost (dsl-213-023-060-046.arcor-ip.net [213.23.60.46]) by mx04.nexgo.de (Postfix) with ESMTP id 2943637B2D; Tue, 12 Feb 2002 21:25:47 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id F1D3344AE; Tue, 12 Feb 2002 21:25:27 +0100 (CET) Date: Tue, 12 Feb 2002 21:25:27 +0100 From: Markus Friedl To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: "Andersson, Mats" , Joseph Galbraith , Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: public key (was Re: consensus probe.) Message-ID: <20020212212527.A30972@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nisse@lysator.liu.se on Mon, Feb 11, 2002 at 05:19:41PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Mon, Feb 11, 2002 at 05:19:41PM +0100, Niels Möller wrote: > I don't have a strong opinion about this, but I think using several > names for things that are actually the same is a kind of bloat. I don't think this would be a problem, since you already have the "format id" for the public-key. Specifying that the "format id" for the signature must be equal to the "format id" from the public-key would simplify things. > I'll have to consider splitting it into > several tables for different "namespaces". well, the 'public-key' and the 'signature' namespace would be the same. > BTW, when talking about signatures. ssh-rsa is specified as using > PKCS1 signatures. What is really meant is PKCS1 v1.5. PKCS1 v2 > (currently only at draft stage, I think) defines a new improved and I did include this information in my "ssh-rsa" draft, but there was no interest in having explicit information in the transport draft. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Feb 13 09:27:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03477 for ; Wed, 13 Feb 2002 09:27:45 -0500 (EST) Received: (qmail 17134 invoked by uid 605); 13 Feb 2002 14:27:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17127 invoked from network); 13 Feb 2002 14:27:39 -0000 Received: from cdc-info.cdc.informatik.tu-darmstadt.de (130.83.23.100) by mail.netbsd.org with SMTP; 13 Feb 2002 14:27:39 -0000 Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 289FD2C91; Wed, 13 Feb 2002 15:27:37 +0100 (MET) Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g1DERYq07882; Wed, 13 Feb 2002 15:27:34 +0100 (MET) Date: Wed, 13 Feb 2002 15:27:34 +0100 From: Bodo Moeller To: Hugo Krawczyk Cc: IETF Transport Layer Security WG , Wei Dai , openssl-dev@openssl.org, ietf-ssh@netbsd.org Subject: Re: [ietf-tls] Re: an attack against SSH2 protocol Message-ID: <20020213152733.A7814@cdc.informatik.tu-darmstadt.de> Mail-Followup-To: Bodo Moeller , Hugo Krawczyk , IETF Transport Layer Security WG , Wei Dai , openssl-dev@openssl.org, ietf-ssh@netbsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from hugo@ee.technion.ac.il on Wed, Feb 13, 2002 at 03:57:59PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Wed, Feb 13, 2002 at 03:57:59PM +0200, Hugo Krawczyk wrote: [...] > Thus, future revisions of TLS should also take this into account. > That is, either transmit a fresh (unpredictable) IV with each msg, > or implcitly compute this IV in an *unpredictable* way, for example by > applying a prf to the msg counter. What about using the MAC as a prefix instead of postfix to the plaintext? If the MAC is secure, it certainly will be unpredictable, so the encrypted MAC (which is the effective IV for the actual data) will be unpredictable as well. >> Another problem with CBC as used in SSL/TLS was pointed out by Serge >> Vaudenay, see . That >> one can easily be avoided by implementations. To avoid the new attack >> without changing the protocol definition, implementations would have >> to send an empty fragment before application data to ensure IV >> randomization. > This is a nice attack (do you know of a publicly available paper on this > that I can cite?), and indeed easier to fix than the others. It's now a technical report: Serge Vaudenay CBC Padding: Security Flaws in SSL, IPSEC, WTLS, ... DSC Technical Report 200150, EPFL, 2001. > The analytical model in my paper (for the case of > authenticate-then-encrypt with CBC) makes the assumption that decryption > and mac verification are performed as an atomic operation with a single > "ciphertext invalidity" bit learned by the attacker regardless of the > reason for failure. This points out to yet another advantage of the > encrypt-then-mac approach, namely, there you first check the MAC and if > not valid you do NOT decrypt (in particular, you provide no info to the > other side or the atacker about the result of decryption). No need for > assumptions on the atomicity of combined operations. I agree, this is a nice property. > I wonder if any one cares in ssl/tls community about all these > basic crypto-security design issues; I certainly do -- > any plans for future protocol > versions? so I was going to ask this myself. > PS: since Wei Dai mentioned the case of SSH in this context, the bad news > there is that even using CBC and fixing the problem of predictable IV > leaves the protocol open to the attacks on authenticate-and-mac > showed in my paper (e.g. the attack in appendix C) Previously I had only mentioned the CRYPTO 2001 version of the paper (which does not have an Appendix C). Here's a pointer to the full paper: Hugo Krawczyk The order of encryption and authentication for protecting communications (Or: how secure is SSL?) Cryptology ePrint Archive: Report 2001/045 -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 14 14:11:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06749 for ; Thu, 14 Feb 2002 14:11:26 -0500 (EST) Received: (qmail 5873 invoked by uid 605); 14 Feb 2002 19:11:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5866 invoked from network); 14 Feb 2002 19:11:22 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 Feb 2002 19:11:22 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id LAA16023; Thu, 14 Feb 2002 11:11:19 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id LAA13193; Thu, 14 Feb 2002 11:11:18 -0800 (PST) Date: Thu, 14 Feb 2002 11:11:17 -0800 From: Wei Dai To: Hugo Krawczyk Cc: IETF Transport Layer Security WG , openssl-dev@openssl.org, ietf-ssh@netbsd.org Subject: Re: [ietf-tls] Re: an attack against SSH2 protocol Message-ID: <20020214111117.A11816@eskimo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from hugo@ee.technion.ac.il on Wed, Feb 13, 2002 at 03:57:59PM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Feb 13, 2002 at 03:57:59PM +0200, Hugo Krawczyk wrote: > Thus, future revisions of TLS should also take this into account. > That is, either transmit a fresh (unpredictable) IV with each msg, > or implcitly compute this IV in an *unpredictable* way, for example by > applying a prf to the msg counter. I'll note that using CTR mode is more efficient than either of these suggestions. It doesn't require unpredictable IVs. > PS: since Wei Dai mentioned the case of SSH in this context, the bad news > there is that even using CBC and fixing the problem of predictable IV > leaves the protocol open to the attacks on authenticate-and-mac > showed in my paper (e.g. the attack in appendix C) Good point. If we want to fix SSH by using a per-packet unpredictable IV, the IV would have to be added to the list of MAC inputs. I think that would prevent the attack in appendix C. I'm not very familiar with how IETF working groups work, so what's the next step here? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 14 17:09:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11291 for ; Thu, 14 Feb 2002 17:09:01 -0500 (EST) Received: (qmail 10083 invoked by uid 605); 14 Feb 2002 22:09:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10073 invoked from network); 14 Feb 2002 22:08:59 -0000 Received: from defiant.dfw.nostrum.com (207.136.36.6) by mail.netbsd.org with SMTP; 14 Feb 2002 22:08:59 -0000 Received: (from sprunk@localhost) by defiant.dfw.nostrum.com (8.11.3/8.11.3) id g1EM8d304306; Thu, 14 Feb 2002 16:08:39 -0600 Date: Thu, 14 Feb 2002 16:08:39 -0600 From: Stephen Sprunk To: openssl-dev@openssl.org Cc: Hugo Krawczyk , IETF Transport Layer Security WG , ietf-ssh@netbsd.org Subject: Re: [ietf-tls] Re: an attack against SSH2 protocol Message-ID: <20020214160839.O3213@defiant.dfw.nostrum.com> Mail-Followup-To: openssl-dev@openssl.org, Hugo Krawczyk , IETF Transport Layer Security WG , ietf-ssh@netbsd.org References: <20020214111117.A11816@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20020214111117.A11816@eskimo.com>; from weidai@eskimo.com on Thu, Feb 14, 2002 at 11:11:17AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Thus spake Wei Dai: > I'll note that using CTR mode is more efficient than either of these > suggestions. It doesn't require unpredictable IVs. ... > Good point. If we want to fix SSH by using a per-packet unpredictable IV, > the IV would have to be added to the list of MAC inputs. I think that > would prevent the attack in appendix C. So is the correct approach to fix the CBC implementation, or to switch to a mode that is less prone to misuse? > I'm not very familiar with how IETF working groups work, so what's the > next step here? Someone writes an internet-draft (ie. RFC format) describing the change. S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 15 19:40:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23897 for ; Fri, 15 Feb 2002 19:40:04 -0500 (EST) Received: (qmail 23493 invoked by uid 605); 16 Feb 2002 00:39:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23486 invoked from network); 16 Feb 2002 00:39:57 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 16 Feb 2002 00:39:57 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id QAA29313 for ; Fri, 15 Feb 2002 16:39:56 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id QAA27210 for ; Fri, 15 Feb 2002 16:39:56 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g1G0duI25393 for ietf-ssh@netbsd.org; Fri, 15 Feb 2002 16:39:56 -0800 Date: Fri, 15 Feb 2002 16:39:56 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: kdbinteract-03 Message-ID: <20020215163956.A25348@google.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is an updated keyboard-interactive draft. I think the only contentious point might be the client truncation of name and prompt fields. Rather than list the changes side-by-side, I'll just give a summary of them. I apologize for the inconvenience. - [3.1] Language tag deprecated in SSH_MSG_USERAUTH_REQUEST. When originally written, ssh had no provision for language choice (and didn't need it -- all protocol exchanges were byte codes). However, the better place for this is in the transport, which is where it is now. So I want to deprecate use of it in kbdint. The doc says it may be removed in the future, but I don't think this is easily done if compatibility with existing implementations is desired. Can someone comment on that? - [3.2] Server no longer should limit name/prompt fields. Instead, the server should just consider that the client may truncate these fields, and choose its prompts appropriately, if possible. - [3.3] Client now MUST prompt the user "as follows". The end of 3.2 said the client MUST display the name and instruction as indicated in 3.3, but in 3.3 it only said SHOULD. This is a disconnect which I didn't like. So the 3.3 section is now MUST, but the description is a little more flexible. - [3.3] GUI instructions more flexible. - [3.3] More explicit description of echo field handling. - [4] Added a second example Should I remove "CRYPTOCard" and replace with "Challenge/Response"? CRYPTOCard might not like the reference without an attribution. - [6] Refs updated /fc --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pwplus.txt" Network Working Group F. Cusack INTERNET-DRAFT Google, Inc. Expires 20 August 2002 M. Forssen Appgate AB 20 February 2002 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 1 August, 2002. 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 20 August 2002 [Page 1] Internet Draft SSH Generic Authentication 20 February 2002 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. This document describes a general purpose authentication method for the SSH 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 still described here 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. This presents a significant advantage to other methods, such as the F. Cusack, M. Forssen Expires 20 August 2002 [Page 2] Internet Draft SSH Generic Authentication 20 February 2002 "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) 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 actual methods he wants to use. It is a a comma-separated list of F. Cusack, M. Forssen Expires 20 August 2002 [Page 3] Internet Draft SSH Generic Authentication 20 February 2002 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 20 August 2002 [Page 4] Internet Draft SSH Generic Authentication 20 February 2002 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 MUST still display the name and instruction fields (as described below). 3.3 User Interface Upon receiving a request message, the client MUST prompt the user as follows: A command line interface (CLI) client MUST print the name and instruction (if non-empty), adding newlines. Then for each prompt in turn, the client MUST 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 20 August 2002 [Page 5] Internet Draft SSH Generic Authentication 20 February 2002 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. The only requirement is that all fields must be presented to the user, for example an implementation MUST NOT discard the name field because its windows lack titles; it MUST 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 MUST 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 MUST 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. Clients MUST 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) Note that the responses are encoded in ISO-10646 UTF-8. It is up to F. Cusack, M. Forssen Expires 20 August 2002 [Page 6] Internet Draft SSH Generic Authentication 20 February 2002 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[1] must be the answer to prompt[1], and so on. 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 a challenge/response implementation. 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 20 August 2002 [Page 7] Internet Draft SSH Generic Authentication 20 February 2002 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 20 August 2002 [Page 8] Internet Draft SSH Generic Authentication 20 February 2002 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. Protocol constants The following method-specific constants are used with this authentication method: SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 6. References [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995 F. Cusack, M. Forssen Expires 20 August 2002 [Page 9] Internet Draft SSH Generic Authentication 20 February 2002 [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-11.txt, November, 2001. [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Connection Protocol", work in progress, draft-ietf-secsh-connect-14.txt, November, 2001. [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Transport Layer Protocol", work in progress, draft-ietf-secsh-transport-11.txt, November, 2001. [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Authentication Protocol", work in progress, draft-ietf-secsh-userauth-13.txt, November, 2001. F. Cusack, M. Forssen Expires 20 August 2002 [Page 10] Internet Draft SSH Generic Authentication 20 February 2002 7. 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 20 August 2002 [Page 11] --UugvWAfsgieZRqgk-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 15 20:01:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24089 for ; Fri, 15 Feb 2002 20:01:46 -0500 (EST) Received: (qmail 27860 invoked by uid 605); 16 Feb 2002 01:01:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27853 invoked from network); 16 Feb 2002 01:01:43 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 16 Feb 2002 01:01:43 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02554; Fri, 15 Feb 2002 17:01:42 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.105]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id RAA20880; Fri, 15 Feb 2002 17:03:28 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g1G11brV973369; Fri, 15 Feb 2002 17:01:41 -0800 (PST) Message-Id: <200202160101.g1G11brV973369@jurassic.eng.sun.com> Date: Fri, 15 Feb 2002 17:00:13 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: kdbinteract-03 To: ietf-ssh@netbsd.org, fcusack@fcusack.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WJv4JwSgdgJyUSTOaCtEOA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list > - [3.1] Language tag deprecated in SSH_MSG_USERAUTH_REQUEST. > > When originally written, ssh had no provision for language choice > (and didn't need it -- all protocol exchanges were byte codes). > However, the better place for this is in the transport, which > is where it is now. So I want to deprecate use of it in kbdint. > The doc says it may be removed in the future, but I don't think > this is easily done if compatibility with existing implementations > is desired. Can someone comment on that? The problem with taking it out is there is another field after it, I think at this stage since kbdint is widely deployed you would have to change the SSH_MSG_USERAUTH_INFO_REQUEST to a new number and leave the old one for backwards compat - similar to what was done for the group exchange draft. What you have in this revision is fine by me, since it is clear that it can still be sent and and makes it clear what the intent is when it is sent. I assume you are just saying to remove it from SSH_MSG_USERAUTH_REQUEST but not from SSH_MSG_USERAUTH_INFO_REQUEST the rest of the doc and the examples seem to indicate this is your intent. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 15 20:42:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24514 for ; Fri, 15 Feb 2002 20:42:24 -0500 (EST) Received: (qmail 7451 invoked by uid 605); 16 Feb 2002 01:42:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7444 invoked from network); 16 Feb 2002 01:42:17 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 16 Feb 2002 01:42:17 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id RAA01755; Fri, 15 Feb 2002 17:42:17 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id RAA22891; Fri, 15 Feb 2002 17:42:17 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g1G1gHY25503; Fri, 15 Feb 2002 17:42:17 -0800 Date: Fri, 15 Feb 2002 17:42:17 -0800 From: Frank Cusack To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: kdbinteract-03 Message-ID: <20020215174216.B25293@google.com> References: <200202160101.g1G11brV973369@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200202160101.g1G11brV973369@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Fri, Feb 15, 2002 at 05:00:13PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Feb 15, 2002 at 05:00:13PM -0800, Darren Moffat wrote: > > - [3.1] Language tag deprecated in SSH_MSG_USERAUTH_REQUEST. > > > > When originally written, ssh had no provision for language choice > > (and didn't need it -- all protocol exchanges were byte codes). > > However, the better place for this is in the transport, which > > is where it is now. So I want to deprecate use of it in kbdint. > > The doc says it may be removed in the future, but I don't think > > this is easily done if compatibility with existing implementations > > is desired. Can someone comment on that? > > The problem with taking it out is there is another field after it, > I think at this stage since kbdint is widely deployed you would have > to change the SSH_MSG_USERAUTH_INFO_REQUEST to a new number and leave > the old one for backwards compat - similar to what was done for the > group exchange draft. What you have in this revision is fine by me, > since it is clear that it can still be sent and and makes it clear > what the intent is when it is sent. mmm... I don't know that it's really worth it to do that. It's not as if it is some significant flaw in the protocol. Should I elide the text saying it may be removed? > I assume you are just saying to remove it from SSH_MSG_USERAUTH_REQUEST > but not from SSH_MSG_USERAUTH_INFO_REQUEST the rest of the doc and the > examples seem to indicate this is your intent. Correct. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Feb 17 16:41:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11847 for ; Sun, 17 Feb 2002 16:41:50 -0500 (EST) Received: (qmail 18416 invoked by uid 605); 17 Feb 2002 21:41:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18408 invoked from network); 17 Feb 2002 21:41:47 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 17 Feb 2002 21:41:47 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 05FFD3BD0B; Sun, 17 Feb 2002 22:41:46 +0100 (MET) Received: from appgate.com (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 980A46C007; Sun, 17 Feb 2002 22:41:47 +0100 (MET) Date: Sun, 17 Feb 2002 22:40:59 +0100 (CET) From: maf@appgate.com Subject: Re: kdbinteract-03 To: fcusack@fcusack.com Cc: ietf-ssh@netbsd.org In-Reply-To: <20020215163956.A25348@google.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20020217214147.980A46C007@shala.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list On 15 Feb, Frank Cusack wrote: > - [3.1] Language tag deprecated in SSH_MSG_USERAUTH_REQUEST. > > When originally written, ssh had no provision for language choice > (and didn't need it -- all protocol exchanges were byte codes). > However, the better place for this is in the transport, which > is where it is now. So I want to deprecate use of it in kbdint. > The doc says it may be removed in the future, but I don't think > this is easily done if compatibility with existing implementations > is desired. Can someone comment on that? I do not think it is worth changing this from the current draft since this is already widely deployed. > - [3.2] Server no longer should limit name/prompt fields. > > Instead, the server should just consider that the client may > truncate these fields, and choose its prompts appropriately, if > possible. This is a difference in degree only, but I can live with it. > - [3.3] Client now MUST prompt the user "as follows". > > The end of 3.2 said the client MUST display the name and > instruction as indicated in 3.3, but in 3.3 it only said SHOULD. > This is a disconnect which I didn't like. So the 3.3 section is > now MUST, but the description is a little more flexible. I would prefer to have SHOULD at both places as to not limit the client more than absolutely needed. Somebody might want to build a client which recognizes some prompts from the server and which knows how to answer, the MUST forbids that. /MaF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Feb 22 12:47:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13401 for ; Fri, 22 Feb 2002 12:47:33 -0500 (EST) Received: (qmail 10365 invoked by uid 605); 22 Feb 2002 17:47:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10356 invoked from network); 22 Feb 2002 17:47:28 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 22 Feb 2002 17:47:28 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12457; Fri, 22 Feb 2002 09:47:25 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA06581; Fri, 22 Feb 2002 09:49:18 -0800 (PST) Received: from jurassic (jurassic [129.146.81.36]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MHlNsv251323; Fri, 22 Feb 2002 09:47:23 -0800 (PST) Date: Fri, 22 Feb 2002 09:47:23 -0800 (PST) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@netbsd.org, Subject: draft-ietf-secsh-agent-00.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1014400043=:250896" 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. ---559023410-851401618-1014400043=:250896 Content-Type: TEXT/PLAIN; charset=US-ASCII -- Darren J Moffat ---559023410-851401618-1014400043=:250896 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-secsh-agent-00.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-ietf-secsh-agent-00.txt" Content-Transfer-Encoding: BASE64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEQuIE1vZmZhdA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT dW4gTWljcm9zeXN0ZW1zDQpFeHBpcmVzOiBKdW5lIDEwLCAyMDAyICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMTAsIDIwMDEN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNTSCBBZ2VudCBGb3J3 YXJkaW5nDQogICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNlY3No LWFnZW50LTAwLnR4dA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1 bGwgY29uZm9ybWFuY2Ugd2l0aA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2Vj dGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJl IHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu Zw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3 b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1 cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0K DQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0 b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEp1bmUgMTAsIDIwMDIuDQoNCkNvcHlyaWdodCBOb3Rp Y2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAo MjAwMSkuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0cmFjdA0KDQog ICBTU0ggaXMgYSBwcm90b2NvbCBmb3Igc2VjdXJlIHJlbW90ZSBsb2dpbiBh bmQgb3RoZXIgc2VjdXJlIG5ldHdvcmsNCiAgIHNlcnZpY2VzIG92ZXIgYW4g aW5zZWN1cmUgbmV0d29yay4gIE9uZSBvZiB0aGUgY29tbW9uIGF1dGhlbnRp Y2F0aW9uDQogICBtZWNoYW5pc21zIHVzZWQgd2l0aCBTU0ggaXMgcHVibGlj IGtleS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZQ0KICAgYXV0aGVu dGljYXRpb24gYWdlbnQgZm9yd2FyZGluZyBwcm90b2NvbCwgd2hpY2ggcnVu cyBhcyBhIGNoYW5uZWwNCiAgIG92ZXIgW1NTSC1UUkFOU10gaXQgaXMgZGVz aWduZWQgdG8gZW5zdXJlIHRoYXQgdGhlIHNlbnNpdGl2ZSBwcml2YXRlDQog ICBrZXlzIG5ldmVyIGxlYXZlIHRoZSB1c2VycyBjb250cm9sIGV2ZW4gd2hl biB1c2luZyBTU0ggdG8gbG9naW4gb3Zlcg0KICAgbXVsdGlwbGUgaG9wcy4N Cg0KDQoNCg0KDQoNCg0KDQpNb2ZmYXQgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgSnVuZSAxMCwgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgU1NIIEFnZW50IEZvcndh cmRpbmcgICAgICAgICAgICAgRGVjZW1iZXIgMjAwMQ0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAg MS4xIEFnZW50IE9wZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDMNCiAgIDMuICBBZGRpdGlvbmFsIEluZm9ybWF0aW9uIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgICAg IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgICAgQXV0aG9yJ3MgQWRkcmVz cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDQNCiAgICAgICBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTW9mZmF0ICAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMDIgICAgICAgICAgICAg ICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgIFNT SCBBZ2VudCBGb3J3YXJkaW5nICAgICAgICAgICAgIERlY2VtYmVyIDIwMDEN Cg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KICAgVGhpcyBwcm90b2NvbCBpcyBk ZXNpZ25lZCB0byBmYWNpbGl0YXRlIGFuIGFkIGhvYyBzZWN1cmUgc2luZ2xl IHNpZ24NCiAgIG9uIG1lY2hhbmlzbSB1c2luZyB0aGUgU1NIIHByb3RvY29s LiAgQSB0eXBpY2FsIHNjZW5hcmlvIGlzIHRoYXQgYQ0KICAgdXNlciBoYXMg dGhlaXIgcHJpdmF0ZSBrZXlzIHN0b3JlZCBvbiB0aGVpciBsYXB0b3AgKGhv c3QgQSkgYW5kIHVzZXMNCiAgIHRoZSBTU0ggcHJvdG9jb2wgdG8gcmVtb3Rl bHkgY29ubmVjdCB0byB0aGVpciBjb3Jwb3JhdGUgVlBOIChob3N0IEIpDQog ICBhY2Nlc3MgcG9pbnQuICBUaGVuIHVzZXMgZnVydGhlciBTU0ggY29ubmVj dGlvbnMgdG8gcmVhY2ggYSBzcGVjaWZpYw0KICAgaG9zdCAoaG9zdCBDKSB3 aXRoaW4gdGhlIGVudGVycHJpc2UgbmV0d29yay4NCg0KICAgV2l0aG91dCBh Z2VudCBmb3J3YXJkaW5nIHRoZSB1c2VyIGlzIHJlcXVpcmVkIHRvIGhhdmUg YSBjb3B5IG9mIHRoZWlyDQogICBwcml2YXRlIGtleSBvbiBob3N0IEEgYW5k IGhvc3QgQiBzbyB0aGF0IHRoZSBjb25uZWN0aW9uIHRvIGhvc3QgQyBjYW4N CiAgIGJlIG1hZGUgdXNpbmcgcHVibGljIGtleSBhdXRoZW50aWNhdGlvbi4g IFRoZSBrZXkgcGFpcnMgdXNlZCBmb3IgdGhlDQogICBob3N0IEEgdG8gQiBh bmQgdGhlIGhvc3QgQiB0byBDIGNvbm5lY3Rpb24gbWF5YmUgdGhlIHNhbWUg YnV0IHRoaXMgaXMNCiAgIG5vdCBhbHdheXMgdGhlIGNhc2UuDQoNCiAgIFRo aXMgcHJlc2VudHMgYSBzZWN1cml0eSByaXNrIHNpbmNlIHRoZSB1c2VycyBw cml2YXRlIGtleShzKSBtdXN0IGJlDQogICBzdG9yZWQgb24gaG9zdCBCIHdo aWNoIGlzIGxpa2VseSB0byBiZSBhIGhvc3QgdGhlIGVuZCB1c2VyIGlzIG5v dCBpbg0KICAgY29udHJvbCBvZiBldmVuIHRob3VnaCB0aGV5IGRvIHRydXN0 IGl0LiAgSXQgaXMgbGlrZWx5IHRoYXQgdGhlDQogICBwcml2YXRlIGtleXMg b24gaG9zdCBBIGFuZCBob3N0IEIgYXJlIHN0b3JlZCBpbiBhbiBlbmNyeXB0 ZWQgZm9ybWF0LA0KICAgdGhpcyBtZWFucyB0aGUgdXNlciBoYXMgYXQgbGVh c3QgdHdvIHBhc3N3b3JkcyB0byBlbnRlciB0byBtYWtlIHRoZQ0KICAgY29u bmVjdGlvbiBmcm9tIEEgdG8gQy4NCg0KICAgSWRlYWxseSB0aGUgcHJpdmF0 ZSBrZXlzIHNob3VsZCByZW1haW4gb24gYSBkZXZpY2UgaW4gdGhlIGRpcmVj dA0KICAgY29udHJvbCBvZiB0aGUgZW5kIHVzZXIgKGhvc3QgQSBpbiB0aGlz IGV4YW1wbGUpIGFuZCBhbGwgZW5jcnlwdGlvbg0KICAgYW5kIHNpZ25pbmcg b3BlcmF0aW9ucyBpbnZvbHZpbmcgdGhlIHByaXZhdGUga2V5IHNob3VsZCBi ZSBwZXJmb3JtZWQNCiAgIG9uIHRoaXMgZGV2aWNlLCByZWdhcmRsZXNzIG9m IHRoZSBsb2NhdGlvbiBvZiB0aGUgZW50aXR5IHJlcXVlc3RpbmcNCiAgIHRo ZSBvcGVyYXRpb24uDQoNCjEuMSBBZ2VudCBPcGVyYXRpb25zDQoNCiAgIFRo ZSBmb2xsb3dpbmcgaW50ZXJhY3Rpb25zIHdpdGggdGhlIGFnZW50IGFyZSBy ZXF1cmllZDogQURELCBERUxFVEUsDQogICBMSVNULCBTSUdOLg0KDQogICBB biBhZ2VudCBpbXBsZW1lbnRhdGlvbiBNVVNUIHN1cHBvcnQgcmVxdWVzdHMg dG8gZm9yd2FyZCBvcGVyYXRpb25zDQogICB1c2luZyBhbGwgcHVibGljIGtl eSB0eXBlcywgZGVmaW5lZCBpbiBbU1NILVVTRVJBVVRIXSBldmVuIHRob3Nl IHRoYXQNCiAgIHRoZSBpbXBsZW1lbnRhdGlvbiBkb2Vzbid0IHN1cHBvcnQg bmF0aXZlbHkuDQoNCjIuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAg IFRoaXMgcHJvdG9jb2wgaXMgZGVzaWduZWQgb25seSB0byBydW4gYXMgYSBj aGFubmVsIG9mIHRoZSBTU0gNCiAgIHByb3RvY29sLg0KDQogICBUaGUgZ29h bCBvZiB0aGlzIGV4dGVuc2lvbiBpcyB0byBlbnN1cmUgdGhhdCB0aGUgdXNl cnMgcHJpdmF0ZSBrZXlzDQogICBuZXZlciBsZWF2ZSB0aGUgbWFjaGluZSB0 aGV5IGFyZSBwaHlzaWNhbGx5IGF0LiAgSWRlYWxseSB0aGUgcHJpdmF0ZQ0K ICAga2V5cyBzaG91bGQgYmUgc3RvcmVkIG9uIGEgcGFzc3dvcmQgcHJvdGVj dGVkIHJlbW92YWJsZSBtZWRpYSBzdWNoIGFzDQogICBhIHNtYXJ0Y2FyZC4N Cg0KDQoNCg0KDQpNb2ZmYXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMg SnVuZSAxMCwgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgU1NIIEFnZW50IEZvcndhcmRpbmcg ICAgICAgICAgICAgRGVjZW1iZXIgMjAwMQ0KDQoNCjMuIEFkZGl0aW9uYWwg SW5mb3JtYXRpb24NCg0KICAgVGhlIGN1cnJlbnQgZG9jdW1lbnQgZWRpdG9y IGlzOiBEYXJyZW4uTW9mZmF0QFN1bi5DT00uICBDb21tZW50cyBvbg0KICAg dGhpcyBpbnRlcm5ldCBkcmFmdCBzaG91bGQgYmUgc2VudCB0byB0aGUgSUVU RiBTRUNTSCB3b3JraW5nIGdyb3VwLA0KICAgZGV0YWlscyBhdDogaHR0cDov L2lldGYub3JnL2h0bWwuY2hhcnRlcnMvc2Vjc2gtY2hhcnRlci5odG1sDQoN ClJlZmVyZW5jZXMNCg0KICAgW0ZJUFMtMTg2XSAgICAgIEZlZGVyYWwgSW5m b3JtYXRpb24gUHJvY2Vzc2luZyBTdGFuZGFyZHMgUHVibGljYXRpb24sDQog ICAgICAgICAgICAgICAgICAgLiwgIkZJUFMgUFVCIDE4NiwgRGlnaXRhbCBT aWduYXR1cmUgU3RhbmRhcmQiLCBNYXkNCiAgICAgICAgICAgICAgICAgICAx OTk0Lg0KDQogICBbU1NILUFSQ0hdICAgICAgWWxvbmVuLCBULiwgIlNTSCBQ cm90b2NvbCBBcmNoaXRlY3R1cmUiLCBJLUQgZHJhZnQtDQogICAgICAgICAg ICAgICAgICAgaWV0Zi1hcmNoaXRlY3R1cmUtMTEudHh0LCBKdWx5IDIwMDEu DQoNCiAgIFtTU0gtVFJBTlNdICAgICBZbG9uZW4sIFQuLCAiU1NIIFRyYW5z cG9ydCBMYXllciBQcm90b2NvbCIsIEktRA0KICAgICAgICAgICAgICAgICAg IGRyYWZ0LWlldGYtdHJhbnNwb3J0LTExLnR4dCwgSnVseSAyMDAxLg0KDQog ICBbU1NILVVTRVJBVVRIXSAgWWxvbmVuLCBULiwgIlNTSCBBdXRoZW50aWNh dGlvbiBQcm90b2NvbCIsIEktRCBkcmFmdC0NCiAgICAgICAgICAgICAgICAg ICBpZXRmLXVzZXJhdXRoLTEzLnR4dCwgSnVseSAyMDAxLg0KDQogICBbU1NI LUNPTk5FQ1RdICAgWWxvbmVuLCBULiwgIlNTSCBDb25uZWN0aW9uIFByb3Rv Y29sIiwgSS1EIGRyYWZ0LQ0KICAgICAgICAgICAgICAgICAgIGlldGYtY29u bmVjdC0xNC50eHQsIEp1bHkgMjAwMS4NCg0KDQpBdXRob3IncyBBZGRyZXNz DQoNCiAgIERhcnJlbiBKIE1vZmZhdA0KICAgU3VuIE1pY3Jvc3lzdGVtcw0K ICAgOTAxIFNhbiBBbnRvbmlvIFJvYWQNCiAgIFBhbG8gQWx0byAgOTQzMDMN CiAgIFVTQQ0KDQogICBFTWFpbDogRGFycmVuLk1vZmZhdEBTdW4uQ09NDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTW9mZmF0ICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgMTAsIDIwMDIgICAgICAgICAg ICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg IFNTSCBBZ2VudCBGb3J3YXJkaW5nICAgICAgICAgICAgIERlY2VtYmVyIDIw MDENCg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMSkuICBBbGwgUmln aHRzIFJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvDQog ICBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBv biBvciBvdGhlcndpc2UgZXhwbGFpbiBpdA0KICAgb3IgYXNzaXN0IGluIGl0 cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVi bGlzaGVkDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55DQogICBraW5kLCBwcm92 aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlz IHBhcmFncmFwaCBhcmUNCiAgIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGll cyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gIEhvd2V2ZXIsIHRoaXMNCiAgIGRv Y3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFueSB3YXks IHN1Y2ggYXMgYnkgcmVtb3ZpbmcNCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNl IG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3Ro ZXINCiAgIEludGVybmV0IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVk ZWQgZm9yIHRoZSBwdXJwb3NlIG9mDQogICBkZXZlbG9waW5nIEludGVybmV0 IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvcg0K ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFy ZHMgcHJvY2VzcyBtdXN0IGJlDQogICBmb2xsb3dlZCwgb3IgYXMgcmVxdWly ZWQgdG8gdHJhbnNsYXRlIGl0IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4N CiAgIEVuZ2xpc2guDQoNCiAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdy YW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUNCiAg IHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nl c3NvcnMgb3IgYXNzaWducy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24g YW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZ IEFORCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcNCiAgIFRBU0sgRk9SQ0Ug RElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQs IElOQ0xVRElORw0KICAgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9ODQogICBIRVJFSU4g V0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBX QVJSQU5USUVTIE9GDQogICBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBG T1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCkFja25vd2xlZGdlbWVudA0K DQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBj dXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBTb2NpZXR5 Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNb2Zm YXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSAxMCwgMjAwMiAg ICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCg== ---559023410-851401618-1014400043=:250896-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Feb 28 07:08:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18421 for ; Thu, 28 Feb 2002 07:08:42 -0500 (EST) Received: (qmail 20828 invoked by uid 605); 28 Feb 2002 12:08:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20820 invoked from network); 28 Feb 2002 12:08:39 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 28 Feb 2002 12:08:39 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18340; Thu, 28 Feb 2002 07:08:20 -0500 (EST) Message-Id: <200202281208.HAA18340@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-agent-00.txt Date: Thu, 28 Feb 2002 07:08:20 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Agent Forwarding Author(s) : D. Moffat Filename : draft-ietf-secsh-agent-00.txt Pages : 5 Date : 27-Feb-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. One of the common authentication mechanisms used with SSH is public key. This document describes the authentication agent forwarding protocol, which runs as a channel over [SSH-TRANS] it is designed to ensure that the sensitive private keys never leave the users control even when using SSH to login over multiple hops. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-agent-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-agent-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-agent-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: <20020227125403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-agent-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-agent-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227125403.I-D@ietf.org> --OtherAccess-- --NextPart--